OpenSSF Scorecard の姿勢
Apothem の OpenSSF Scorecard 目標と、スコアを改善し続けるために用いる証拠面。
Apothem は OpenSSF Scorecard の最高スコアを目標としつつ、新しい単独メンテナーのリポジトリから Scorecard が推論できることとできないことについて、公開ファサードを誠実に保ちます。このドキュメントは、各チェック、それを裏付ける証拠面、そして姿勢を最新に保つコントロールを列挙します。
現在のスコアは Scorecard ビューアで確認できます。バッジは README のヘッダーにあります。
チェックごとの証拠マトリクス
| チェック | 証拠面 | 備考 |
|---|---|---|
| Binary-Artifacts | binary-artifacts-sweep.md | ソースで追跡される実行可能バイナリはゼロです。生成された配布アーカイブは dist/ に留まります。 |
| Branch-Protection | branch-protection-ruleset.md | main は、公開リリースへの昇格の前に保護されます。新しいリリースコミットが着地した後は、強制プッシュと削除がブロックされます。 |
| CI-Tests | .github/workflows/ci.yml | Pytest マトリクス、ruff、mypy、Trivy、ドキュメントのビルド、パッケージングのスモークチェック。 |
| CII-Best-Practices | OpenSSF Best Practices への登録 | OpenSSF Best Practices サイトでのメンテナー側の登録が必要です。これはリポジトリのファイルだけでは完了できません。 |
| Code-Review | ブランチ保護 + CODEOWNERS | リポジトリ管理者を除くすべての人に対して、main にはプルリクエストが必要です。プロジェクトのメンテナーが 1 人である間、ブランチ保護は承認レビューを 0 件と要求します（branch-protection-ruleset.md を参照）。レビュー済みの PR が存在するまで、Scorecard の履歴は限定的なままです。 |
| Contributors | AUTHORS | 新しい単独メンテナーのプロジェクトは、複数組織にわたる貢献履歴を作り出すことはできません。これは、コントリビューターが参加するにつれて自然に改善します。 |
| Dangerous-Workflow | ワークフロー監査 | pull_request_target はありません。Actions は SHA で固定され、明示的な権限でスコープが限定されています。 |
| Dependency-Update-Tool | .github/dependabot.yml | Dependabot は、GitHub Actions のピン、Web サイト、vsce パッケージャーのロックファイル、ハッシュロックされた CI の pip、pre-commit フックに対してはグループ化された週次の更新を、channel-smoke のロックファイルに対しては月次の更新を提案します。Dependabot のセキュリティ更新は、検出されたすべてのマニフェストをカバーします。ただし、scripts/ci/ にある CI の依存関係とツールのロック済み一式は対象外です。これらは、アラートがロック済みのパッケージを挙げたときに scripts/dev/refresh_ci_locks.py が再生成します。.gitattributes は、この 1 つのファイルを GitHub のソースアーカイブに残します。このアーカイブは、アクションの既定のアーカイブモードで行うスキャンが読み取ります。Scorecard ワークフローは git モードで実行され、このファイルをクローンから読み取ります。 |
| Fuzzing | tests/property/ | Hypothesis のプロパティテストが、パーサーと frontmatter の不変条件を検証します。上流の Scorecard は、Hypothesis をファザーの統合として評価しない場合があります。 |
| License | LICENSE | リポジトリのルートにある MIT ライセンス。 |
| Maintained | Git 履歴 | 現在のリリースコミットとアクティブなワークフローの頻度が、メンテナンスが行われていることを示します。非常に新しいリポジトリは、経過期間に関する警告を受ける場合があります。 |
| Packaging | .github/workflows/ | sdist、wheel、SBOM、SLSA 来歴、Sigstore 署名を生成する、リリース、Pages、npmjs.com のワークフロー。 |
| Pinned-Dependencies | ワークフロー監査 + ハッシュロックされた要件 | Actions は SHA で固定されています。リリースツール、CI の pip アップグレード、CI のプロジェクト依存関係とテスト依存関係、CI ツール（ruff、bandit、pip-audit、pip-licenses、pre-commit）は、--require-hashes でインストールされます。プロジェクト、テスト、ツールのインストールは、scripts/ci/ にある 9 つのロックファイルを読み込みます。pip のアップグレードとリリースツールはそれぞれ専用のロックファイルを読み込み、パッケージ自体は --no-deps -e . でインストールされます。 |
| SAST | .github/workflows/codeql.yml | Python と Actions を対象とする CodeQL の security-extended クエリ。 |
| Security-Policy | SECURITY.md | 協調的開示ポリシー、サポート対象バージョンのマトリクス、対応のタイムライン。 |
| Signed-Releases | .github/workflows/release.yml | Sigstore のキーレス署名、SLSA 来歴、SBOM、チェックサム、リリース成果物。 |
| Token-Permissions | ワークフロー監査 | ワークフローは既定で読み取り専用の権限を持ちます。書き込みスコープはジョブローカルで、デプロイ／パッケージ操作に結び付けられています。 |
| Vulnerabilities | .github/workflows/pip-audit.yml + .github/workflows/dependency-review.yml | 毎週の脆弱性スキャンと、SARIF アップロードを伴う CI スキャン。dependency-review ゲートは、脆弱性のある依存関係や許可されていないライセンスの依存関係を導入するプルリクエストをブロックします。このチェック自体は、リポジトリのマニフェストで見つけた依存関係を OSV で照会します。そのため pip-audit.yml も OSV に問い合わせます（pip-audit -s osv）。そこでの検出結果は、チェックの検出結果と一致します。 |
スコアの解釈
Scorecard は各チェックを 0〜10 のスケールで採点し、総合スコアは加重平均です。リポジトリの履歴、サードパーティへの登録、コントリビューターの多様性に依存するコントロールは、過大に主張するのではなく明示的に追跡されます。ファイルで制御されるチェックのいずれかでドリフトが生じると、即座の是正がトリガーされます。
Scorecard ワークフローは file_mode: git を指定してアクションを実行するため、Scorecard はリポジトリのクローンを読み取ります。ソースアーカイブには .github/ が含まれません（export-ignore を .gitattributes で指定）。そのため、アクションの既定のアーカイブモードでは、Dangerous-Workflow、Token-Permissions、Pinned-Dependencies、Packaging からワークフローが見えなくなります。
Pinned-Dependencies は、2 つの理由により意図的に 10 未満に留まります。SLSA ジェネレーターはリリースタグで参照されます。これは SHA 固定の唯一の例外で、その来歴がそのタグに結び付けられているためです。evals ワークフローは、実行ごとに選ばれるバージョンの Claude Code CLI を npm install --global でインストールします。Scorecard がワークフロー内でスキャンする Python のインストールは、ハッシュロックされたもの、パッケージ自体のローカルインストール、同じ実行でビルドされた wheel のいずれかです。
更新の周期
- プッシュごと: Scorecard ワークフローは、
mainへのすべてのプッシュで再実行されます。 - 毎週: 月曜日 02:30 UTC — 上流の採点方法論の変更と、既存の固定済み依存関係に対して新たに開示された脆弱性を捕捉します。
- リリースごと: 公開への昇格の前に、メンテナーが現在の Scorecard ビューアの面を検証し、プラットフォームの状態による制約を記録します。
参考資料
- OpenSSF Scorecard — 上流プロジェクト
- Scorecard チェックリファレンス — チェックごとのセマンティクス
ossf/scorecard-action— GitHub Actions のラッパー- SLSA フレームワーク — サプライチェーンのレベル（apothem は SLSA-3 で出荷）