enterprise-readiness

エンタープライズ対応状況の評価

本番／エンタープライズ階層専用 — references/tier-framing.md を参照してください。

使用する場面

• 本番／エンタープライズ対応状況の評価
• サプライチェーンセキュリティ：SLSA プロベナンス、cosign 署名、SBOM
• CI/CD の強化、ワークフローの権限
• OpenSSF Best Practices（Passing／Silver／Gold）、OSPS Baseline（L1/2/3）
• Scorecard の最適化（Token-Permissions、Branch-Protection、Pinned-Deps）
• コードレビュー、ADR、変更履歴、SECURITY.md

評価ワークフロー

1. 調査：プラットフォーム、言語、既存の CI/CD、dependabot.yml を特定します。保守されている公開プロジェクトでは、必須のルート .bestpractices.json を確認します（適用範囲と検証については references/bestpractices-json.md、ER-74/ER-75 を参照）。
2. スコアリング：チェックリストを適用し、Scorecard、バッジの基準、カバレッジを確認します。
3. ギャップ分析：不足している制御項目を重大度別に列挙します。
4. 実装：修正を適用します（アクションの SHA ピン留め、権限の強化、ワークフローの追加）。
5. 検証：再スコアリングして比較します。

必須のワークフローとバッジ

必須のカバレッジ：CI、CodeQL、Scorecard、依存関係レビュー、composer audit、SBOM — 専用のワークフロー、または netresearch の再利用可能なワークフローを呼び出すジョブとして用意します。バッジ：CI、Codecov、Scorecard、Best Practices、Baseline。references/badges-and-workflows.md を参照してください。

保守されている公開プロジェクトでは、バッジ登録の前であっても、リポジトリのルートに証拠に基づく .bestpractices.json を必ず含めてください。プロジェクト独自の証拠に基づいて作成または更新し、不明な項目は省略します。このファイルは回答案を提示するものであり、プロジェクトの登録、アンケートの保存、バッジの授与を行うものではありません。references/bestpractices-json.md を参照してください。

主な強化パターン

• 権限：ワークフローレベルで permissions: contents: read を宣言し、書き込み権限はジョブごとにのみ付与します。
• SHA ピン留め：サードパーティ製アクションは、バージョンコメント（# v4.2.0）を付けて SHA にピン留めします。組織内の再利用可能なワークフローでは @main を使用します。
• Harden-Runner：すべてのジョブで、step-security/harden-runner を最初のステップとして使用します。許可されたエンドポイントを指定した egress-policy: block を優先します。
• Dependabot：すべてのエコシステム（composer、npm、github-actions、docker）を含む dependabot.yml を設定します。pull_request_target を使用して、依存関係の PR 用の自動マージワークフローを設定します。
• カバレッジ：codecov-action でアップロードし、パッチカバレッジのしきい値を codecov.yml で設定します。
• CI の重複防止：pull_request: も存在する場合は、push: トリガーの対象を branches: [main] に限定します。
• SLSA プロベナンス：id-token: write および attestations: write の権限を付与して actions/attest-build-provenance を使用し、gh attestation verify で検証します。これはプロジェクト独自のワークフローにおけるレベル 2 です。レベル 3 には、チェックアウト、ビルド、アテステーションのすべてを、プロジェクト側で編集できない組織の再利用可能なワークフロー内で実行する必要があります — references/slsa-provenance.md を参照してください。
• セキュリティポリシー：脆弱性の開示手順と対応 SLA（Critical：7 日、High：30 日）を記載した SECURITY.md を作成します。

重要なルール

• 絶対に ${{ github.event.* }} または ${{ inputs.* }} を run: ブロック内で展開しないでください（スクリプトインジェクション）。
• 絶対にアクションのバージョンを推測しないでください。GitHub API から取得し、タグと照合して SHA を検証してください。
• 必ずバッジの根拠説明に https:// URL を含めてください。
• 必ずDependabot／Renovate を使用するリポジトリで自動マージを設定してください。

参考資料

参考資料	用途
references/general.md	常に使用
references/scorecard-playbook.md	スコアカードの最適化
references/badges-and-workflows.md	バッジの URL、ワークフロー
references/mandatory-requirements.md	チェックリスト
references/ci-patterns.md	CI/CD、フック
references/code-review.md	PR の品質と検証に関する主張
references/slsa-provenance.md	SLSA レベル 3
references/signed-releases.md	Cosign/GPG
references/openssf-badge-silver.md	シルバー
references/openssf-badge-gold.md	ゴールド
references/openssf-badge-baseline.md	OSPS ベースライン
references/bestpractices-json.md	.bestpractices.json：リポジトリからバッジの回答を事前入力
references/harden-runner-guide.md	Harden-Runner
references/solo-maintainer-guide.md	単独メンテナーの基準
references/npm-pnpm-supply-chain.md	pnpm、npm ci、npx、ロックファイル、CI ジョブ内の Node ツール（Sonar S8543/S6505、CodeQL のパスインジェクション）
references/python-pip-supply-chain.md	pip

関連スキル：go-development、github-project、security-audit、git-workflow。