リリースに含まれるものを検証する

依存関係が必要かを確認する

エージェントは、問題を解決できそうなパッケージを提案します。それは提案であり、パッケージが存在する証拠や、適している証拠ではありません。インストール前に、正確なレジストリ、公開者、パッケージ名、バージョンを確認します。

架空のCSVエクスポートでは、ランタイムが必要な動作をすでに提供しているかもしれません。新しいパッケージが適切な場合もありますが、保守と実行の経路が増えます。実装の工数と、依存関係を継続して管理する責任を比較します。

ライセンスと対応ランタイムをレビューします。保守活動と関連するセキュリティ情報を調べてください。見慣れた名前でも、別のレジストリでは異なるパッケージを指す場合があります。インストールの成功が示すのは、インストールが完了したことだけです。

インストールとビルドの動作を調べる

依存関係は、インストールやビルドの途中でコードを実行することがあります。これらの環境では、認証情報とネットワークアクセスを制限します。信頼できないpull requestを処理するジョブに、本番のシークレットを開示してはいけません。

エコシステムが対応している場合は、commit済みのlockfileを使います。ビルドがそのファイルに従うようにしてください。想定外の間接的な依存パッケージも含め、lockfileの変更をソースの変更と一緒にレビューします。バージョンの固定は再現性を高めますが、脆弱なバージョンを安全にはしません。

NISTのSSDFは、ライフサイクル全体でソフトウェアと開発活動を保護する実践を扱います。ビルド環境を設計するときは、その広い視点を使ってください。フレームワークを確認してください。

構成要素の一覧と来歴を区別する

ソフトウェア部品表（SBOM）は、ソフトウェアに含まれるコンポーネントを記録します。あるコンポーネントに問題が生じた際、影響するリリースを特定する助けになります。それ自体で、コンポーネントが安全だと確認できるわけではありません。

来歴（provenance）は、成果物がどのように作られたかを扱います。SLSAは、ビルドとその入力に関する情報の来歴形式を定義しています。検証では、この情報を信頼できる生成元と、使用予定の成果物に結び付ける必要があります。「provenance」という名前のファイルがあるだけでは不十分です。SLSAの来歴形式を参照してください。

エクスポートサービスでは、確認可能なつながりを記録します。

1. レビュー済みcommitが、受け入れたソースを特定します。
2. ビルドが、その入力と実行環境を特定します。
3. 成果物に安定したダイジェスト値があります。
4. 各確認が、調べた成果物またはソースを特定します。
5. デプロイ記録が、対象環境へ配置した成果物を示します。

定めた検証プロセスなしに、承認後に異なる方法で再ビルドしないでください。latestのような変更可能なタグは、後で別のイメージを指すことがあります。

検出結果の意味を判断する

脆弱性の検出結果には、背景情報が必要です。影響するバージョン、到達可能な動作、曝露、利用できる修正、影響を確認します。一時的な例外には、根拠となる証拠を記録します。責任者、有効期限、見直し条件を設定してください。

一つの検出結果が該当しないからといって、スキャナー全体を無効にしてはいけません。スキャンが完了しなかったのに、問題なしと報告してはいけません。タイムアウト、未対応のパッケージ、利用できない脆弱性情報フィードは、証拠の不足です。

最後に、リリース後の更新を計画します。昨日受け入れた成果物にも、新しい脆弱性情報が影響する可能性があります。サービス責任者には、構成要素の一覧、対応プロセス、修正版をリリースするための対応能力が必要です。

次の継続的な脆弱性管理で、繰り返すスキャンと本番で検証した修正を結び付けます。