Security Slam 2026 秋季活动：用 30 天推进开源项目安全治理

预计阅读时间：8 分钟

Security Slam 2026 秋季活动是一场为期 30 天的线上活动，时间为 2026 年 10 月 5 日至 11 月 6 日。活动由 Open Source Security Foundation（OpenSSF）与 Cloud Native Computing Foundation（CNCF）合作开展。它值得关注的地方，不只是集中发现安全问题，更在于推动维护者和贡献者把安全检查、依赖更新与响应流程真正纳入项目日常维护。

目前给出的信息没有说明报名方式、项目范围或具体任务，因此参与细节应以活动后续发布的规则为准。不过，团队现在就可以建立安全基线，把活动窗口变成一次可衡量、可复查的安全冲刺。

不要把 Security Slam 理解成一次集中扫描

开源项目的安全工作经常卡在三个环节：不知道当前风险、发现问题后无人负责、修复完成却没有持续检查。一次有明确期限的线上活动，正适合把这些环节串起来。

可以把目标拆成四类：

项目基线：检查分支保护、代码审查、发布流程和安全策略文件。
供应链风险：识别过期依赖、未固定版本的自动化任务和来源不明的构建产物。
漏洞响应：明确私人报告渠道、负责人和修复后的披露流程。
持续验证：把扫描放进 CI，而不是只在活动期间手工执行一次。

真正有效的成果不是“生成了多少告警”，而是高风险问题是否得到负责人、截止时间和可验证的修复。

先用 OpenSSF Scorecard 建立可比较的基线

OpenSSF Scorecard 可以从多个维度检查开源仓库的安全实践。下面是一种可直接改造的本地执行方式，不代表活动指定流程。

运行前将 OWNER/REPO 替换为目标 GitHub 仓库。公开仓库通常可以直接检查；如果遇到 API 速率限制，可在当前终端设置具有最小只读权限的 GITHUB_TOKEN。

export REPO="https://github.com/OWNER/REPO"
export GITHUB_TOKEN="your-read-only-token"

docker run --rm \
  -e GITHUB_AUTH_TOKEN="$GITHUB_TOKEN" \
  gcr.io/openssf/scorecard:stable \
  --repo="$REPO" \
  --format=json > scorecard.json

jq -r '.checks[] | [.name, .score, .reason] | @tsv' scorecard.json \
  | sort -k2,2n

这段命令会把结果保存为 scorecard.json，再按分数排列检查项。评审结果时，不要简单追求总分，应优先查看这些问题：

是否存在未经审查即可合并或发布代码的路径。
CI 工作流是否使用过宽的令牌权限。
第三方依赖与自动化 Action 是否固定到可信版本。
仓库是否提供清晰的漏洞报告方式。
二进制发布是否能追溯到源代码和构建过程。

扫描工具只能提供信号。例如，一个低分项目未必正在遭受攻击，一个高分项目也不代表没有漏洞。团队仍需结合项目语言、发布方式和威胁模型判断优先级。

把依赖更新变成持续工作

如果项目使用 GitHub Actions 和 npm，可以添加下面的 .github/dependabot.yml。这是一个可修改的示例，并非已公布的活动要求；不使用 npm 的项目应将生态类型替换为 Maven、pip、Go Modules、Cargo 等实际环境。

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    groups:
      development-dependencies:
        dependency-type: "development"

自动更新并不等于自动合并。更稳妥的流程是：机器人创建 PR，CI 执行测试和构建，维护者检查破坏性变更，再由具备权限的人合并。对于发布工具、签名工具和 CI Action，还应单独评估其维护状态与来源。

仓库也可以增加 SECURITY.md，至少说明支持版本、私人报告渠道、预计确认时间，以及何时适合公开讨论。不要要求报告者在公开 Issue 中粘贴利用代码、访问令牌或尚未修复的漏洞细节。

一套适合 30 天窗口的执行节奏

团队可以根据活动日期安排自己的工作节奏：

第 1 周：盘点。 运行基线检查，整理依赖、CI 权限、发布凭据和现有安全告警。
第 2 周：处理高风险项。 优先修复可直接导致代码执行、凭据泄漏或未经授权发布的问题。
第 3 周：固化流程。 增加依赖更新、分支保护、最小权限和漏洞报告文档。
第 4 周：复测与记录。 重新运行检查，为未完成的问题指定负责人，并记录风险接受理由。

如果要向其他项目提交安全改进，先阅读贡献指南并与维护者沟通。批量生成 PR、未经验证地升级依赖，或者公开披露可利用漏洞，都可能增加维护成本甚至制造新的风险。

参与前的检查清单

在 2026 年 10 月 5 日之前，可以先确认：

仓库有明确的维护者和安全联系人。
默认分支启用了审查与必要状态检查。
CI 令牌遵循最小权限原则，长期密钥没有写入代码。
依赖更新能够触发自动测试，而不是直接进入生产环境。
高风险发现有负责人、期限和复测步骤。
团队会核对活动的正式规则、参与范围与提交要求。

Security Slam 最有价值的结果，不是活动结束时的一张评分截图，而是项目在 11 月 6 日之后仍能持续发现、分派和修复安全问题。