Skip to main content

概要

セキュリティ証拠は、お客様が評価しているソフトウェアそのものまで追跡できる場合に最も有用です。CaseBender はビルドを Git コミットで識別し、コンテナ成果物を不変ダイジェストで識別します。 保証レビューを行う際は、以下のいずれかから開始してください。
  • CaseBender のリリースバージョン
  • リリースに表示される Git コミット SHA
  • デプロイされた各コンテナイメージのダイジェスト
  • 成果物を生成したワークフロー実行
latest などのタグは便利な参照ですが、安定した証拠識別子ではありません。

証拠カタログ

トレーサビリティ手順

1. デプロイ済みダイジェストを記録する

レジストリまたはコンテナランタイムを使用して、不変ダイジェストを取得します。
想定される出力は次のような形式です。

2. 署名を検証する

CaseBender のリリースワークフローでは、GitHub Actions OIDC を基盤とするキーレス Cosign 署名を使用します。
検証は、タグだけでなくダイジェストに対して実施してください。レジストリチャネルおよび証明書 ID は、成果物とともに提供されるリリースドキュメントと一致している必要があります。

3. プロベナンスメタデータを検証する

プロベナンス文書で以下を確認します。
  • リポジトリおよびソースリビジョン
  • ワークフロー ID およびトリガー
  • ビルドタイムスタンプおよび実行者
  • subject フィールド、およびレビュー対象の成果物を識別しているか
  • 添付された署名および署名証明書
現在の単独の CaseBender プロベナンス文書では、subject が空です。署名済みのワークフローメタデータとして検証できますが、特定のコンテナダイジェストがその呼び出しによって生成されたことを現時点では証明できません。成果物レベルのトレーサビリティには、レジストリダイジェスト、イメージ署名、およびイメージ SBOM attestation を使用してください。
内容を信頼する前に、署名済み blob を検証してください。

4. SBOM を確認する

SBOM を使用して、デプロイメントに関連する直接および推移的コンポーネントを特定します。お客様は、CycloneDX JSON を自社の脆弱性管理ツールまたはソフトウェア資産管理ツールにインポートできます。 SBOM は、レビュー対象と同じコミットまたはイメージダイジェストに対応させる必要があります。リポジトリレベルの SBOM とイメージレベルの SBOM は異なる問いに答えるものであり、相互に置き換え可能なものとして扱わないでください。

5. セキュリティの検出結果と例外を確認する

以下を確認してください。
  • スキャンがスキップされず完了したこと
  • レポートが対象のリビジョンまたはダイジェストに対応していること
  • ワークフローで使用された severity ポリシー
  • 修正が提供されていない検出結果がスキャナー構成によって除外されていたか
  • 例外が正確な検出結果およびパスに適用されるか
  • 例外が引き続きレビュー期間内にあるか

成果物の保持

現在のワークフローの保持設定には、以下が含まれます。
  • スキャナーおよび監査の成果物:通常 30 日
  • リポジトリの CycloneDX SBOM 成果物および署名関連データ:1,095 日
  • レジストリの署名および attestation:レジストリのライフサイクルポリシーに従い、該当するレジストリ成果物とともに保持
お客様自身の環境における保持は、そのお客様が管理します。より長期の監査要件があるお客様は、デプロイするリリースごとに受領した証拠パッケージをアーカイブしてください。

推奨されるお客様向け証拠パッケージ

リリース保証レビューに関連するパッケージには、以下が含まれる場合があります。
  1. リリース識別子およびコミット SHA
  2. デプロイされたサービスイメージの不変ダイジェスト
  3. Security Gate workflow result
  4. それらのダイジェストに対するコンテナスキャン結果
  5. CycloneDX SBOM
  6. 署名検証の出力
  7. 署名済みプロベナンスおよび検証の出力
  8. 該当する有効な例外記録
  9. 脆弱性修正の概要
  10. 現在のペネトレーションテスト状況に関する声明
利用可否は、リポジトリ権限、レジストリチャネル、成果物の保持期間、および契約上の開示条件に依存する場合があります。未加工のレポートには、リポジトリのパス、依存関係の詳細、またはインフラストラクチャ情報が含まれる可能性があり、安全な転送または墨消しが必要になる場合があります。

成功結果の解釈

green のワークフローは、構成されたジョブが、そのリビジョンに組み込まれたポリシーに従って完了したことを意味します。以下を意味するものではありません。
  • 脆弱性が存在しない
  • すべてのアプリケーションパスがテストされた
  • デプロイされたすべてのインフラストラクチャがスキャン済みテンプレートと一致する
  • すべての依存関係に今後アドバイザリが発生しない
  • 第三者が結果を独立して検証した
  • リリースがコンプライアンスフレームワークに対して認証されている
より高い保証が求められるデプロイメントでは、自動化された証拠に加えて、アーキテクチャレビュー、お客様環境のハードニング、脅威モデリング、および独立した手動テストを組み合わせてください。

ペネトレーションテストの証拠

CaseBender は現在、完了済みの第三者ペネトレーションテストレポートまたは修正後の再テスト書簡があるとは表明していません。自動 ZAP テストおよび製品内のペネトレーションテスト管理機能は、そのような証拠の代替ではありません。 計画中の評価、テスターに求められる資格、実施規則、および想定成果物については、Independent Penetration Test Scope(英語) に記載されています。

セキュリティ上の懸念事項の報告

CaseBender の脆弱性が疑われる場合は、security@casebender.com まで報告してください。以下を含めてください。
  • 影響を受けるバージョンまたはイメージダイジェスト
  • デプロイモード
  • 再現手順
  • 期待される動作と実際に観察された動作
  • 潜在的な影響
  • 安全に取り扱うことができる概念実証資料
暗号化されていない最初のメッセージには、有効な認証情報、お客様のデータ、または破壊的なエクスプロイト資料を含めないでください。

関連ドキュメント