Back to Details

security-maintenance

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Security Maintenance

安全维护

security updateは単純なCVSS順ではなく、projectへの実到達可能性とrelease riskまで含めて優先順位を付ける。
未知のsource vulnerability探索は 
security-audit
が所有する。そこで 
confirmed
になったfindingは本Skillへhandoffし、advisoryと同じproject-aware priority / remediation / release workflowへ統合する。
needs_validation
をconfirmed vulnerabilityとしてpriority化しない。
security update 的优先级不能只按 CVSS 排序，还必须考虑 project 的实际可达性和 release risk。
未知 source vulnerability 探索由 
security-audit
负责。其中状态为 
confirmed
的 finding 会 handoff 给本 Skill，并纳入与 advisory 相同的 project-aware priority / remediation / release workflow。不得将 
needs_validation
作为 confirmed vulnerability 进行 priority 排序。

1. Source priority

1. 来源优先级

初期化時および継続maintenance時に、実際に使用しているversionを基準に次を確認する。
  1. framework/runtime/SDK official security advisories
  2. official release notes / security announcements
  3. language/package ecosystem official advisory source
  4. GitHub Security Advisories / dependency alerts
  5. maintainer issue / patch release information
  6. trusted secondary source
一般ニュースやSNSだけをsecurity SoTにしない。
在初始化和持续 maintenance 时，以实际使用的 version 为基准，检查以下来源：
  1. framework/runtime/SDK 官方 security advisories
  2. 官方 release notes / security announcements
  3. language/package ecosystem 官方 advisory 来源
  4. GitHub Security Advisories / dependency alerts
  5. maintainer issue / patch release 信息
  6. 可信的 secondary source
不能仅将一般新闻或 SNS 作为 security SoT。

2. Inventory

2. Inventory

最低限把握する:
  • direct dependencies
  • security-sensitive transitive dependencies
  • framework/runtime/SDK versions
  • container/base image
  • OS/runtime packages when relevant
  • build/deploy toolchain
  • externally exposed services/endpoints
  • auth/session/crypto/storage/network boundaries
lockfileやgenerated SBOM等、再現可能なinventoryを優先する。
至少需要掌握：
  • 直接依赖（direct dependencies）
  • 安全敏感的传递依赖（security-sensitive transitive dependencies）
  • framework/runtime/SDK 版本
  • container/base image
  • 相关场景下的 OS/runtime packages
  • build/deploy toolchain
  • 对外暴露的 services/endpoints
  • auth/session/crypto/storage/network 边界
应优先使用 lockfile、generated SBOM 等可复现的 inventory。

3. Prioritization

3. 优先级评估

severityだけで決めない。最低限次を評価する。
  • advisory severity / CVSS等
  • exploitability / exploit maturity
  • projectでvulnerable pathがreachableか
  • internet/external exposure
  • auth前に到達可能か
  • confidentiality / integrity / availability impact
  • privilege required
  • affected data / tenant scope
  • fix/patch availability
  • workaround quality
  • regression/migration risk
  • current target releaseとの距離
project固有priorityへ変換する。
推奨概念:
  • P0 / Critical: active exploitationまたは高確率で直接exposed、即時対応。必要なら現在sprintを中断しpatch release。
  • P1 / High: reachableで重大impact、fix available。current releaseのblocking候補。
  • P2 / Medium: 条件付きreachableまたはimpact限定。計画ticketとして近いreleaseへ。
  • P3 / Low: non-reachable/defense-in-depth。dependency hygieneとして処理。
CVSSが高いだけでP0にしない。逆にCVSSが中程度でもproject exposureが高ければ優先度を上げる。
不能仅根据 severity 作出决定，至少需要评估以下因素：
  • advisory severity / CVSS 等
  • exploitability / exploit maturity
  • project 中 vulnerable path 是否 reachable
  • internet/external exposure
  • 是否能够在 auth 前到达
  • confidentiality / integrity / availability 影响
  • 所需权限（privilege required）
  • 受影响的 data / tenant 范围
  • fix/patch 可用性
  • workaround 质量
  • regression/migration risk
  • 与当前 target release 的距离
最终转换为 project 特有的 priority。
推荐的概念：
  • P0 / Critical：存在 active exploitation 或高概率直接 exposed，需要立即响应；必要时中断当前 sprint 并发布 patch release。
  • P1 / High：reachable 且影响重大，已有 fix，可作为阻断 current release 的候选项。
  • P2 / Medium：条件性 reachable 或影响有限，作为计划 ticket 纳入近期 release。
  • P3 / Low：non-reachable / defense-in-depth，作为 dependency hygiene 处理。
不能仅因 CVSS 较高就判定为 P0。反之，即使 CVSS 处于中等水平，只要 project exposure 较高，也应提高优先级。

4. Response workflow

4. 响应流程

meaningful advisoryを検出したら:
  1. affected versionを確認
  2. project reachabilityを確認
  3. exploit/fix情報を確認
  4. priority決定
  5. GitHub Issueを日本語で作成/更新
  6. target releaseを決定
  7. isolated ticket branchで修正
  8. focused + integration security verification 9.必要ならrelease gateへ追加
  9. advisory sourceと判断根拠をIssue/ADRへ残す
緊急patchでは 
release-x-y-z
のpatch versionを切ることを許可する。
发现 meaningful advisory 后：
  1. 确认受影响的 version
  2. 确认 project reachability
  3. 确认 exploit/fix 信息
  4. 决定 priority
  5. 使用日语创建或更新 GitHub Issue
  6. 确定 target release
  7. 在隔离的 ticket branch 中修复
  8. 执行 focused + integration security verification
  9. 必要时添加到 release gate
  10. 在 Issue/ADR 中记录 advisory 来源和判断依据
紧急 patch 场景下，允许发布 
release-x-y-z
形式的 patch version。

5. Automated security checks

5. 自动化安全检查

projectに適切なら初期化時に導入・修復する。
候補:
  • dependency vulnerability scan
  • dependency review on PR
  • code scanning / SAST
  • secret scanning
  • container/image scanning
  • SBOM generation
  • license/security policy checks
ただし大量のfalse positiveをblockingにしてsignalを破壊しない。blocking/non-blockingはproject riskに合わせて明示する。
如果适合 project，可在初始化时引入，并在修复时同步处理。
候选项：
  • 依赖漏洞扫描（dependency vulnerability scan）
  • PR 中的 dependency review
  • 代码扫描 / SAST（code scanning / SAST）
  • secret scanning
  • container/image scanning
  • SBOM generation
  • license/security policy checks
但是，不应将大量 false positive 设为 blocking，否则会破坏 signal。必须根据 project risk 明确区分 blocking 和 non-blocking。

6. Security gate

6. Security Gate

security-related ticketは通常quality gateに加えて:
  • exploit/reproduction条件の確認
  • vulnerable pathが修正後に閉じていること
  • regression test
  • dependency/version resolution確認
  • production artifactにfixed versionが入ること
  • workaroundを入れた場合の撤去条件
を検証する。
security-related ticket 除了常规 quality gate 外，还需要验证：
  • exploit/reproduction 条件
  • 修复后 vulnerable path 是否已关闭
  • regression test
  • dependency/version resolution
  • production artifact 中是否包含 fixed version
  • 如果采用 workaround，其移除条件

7. Re-evaluation

7. 重新评估

framework/runtime major/minor update、security policy変更、exposure変更、新しいexternal service追加時はsecurity profileを再評価する。
在 framework/runtime major/minor update、security policy 变更、exposure 变更或新增 external service 时，重新评估 security profile。