SBOMは「インストールしたもの」を証明する。しかし、「インストールすべきだったか」は証明できない。

SBOMはレシートのようなものです。何がインストールされたかを教えてくれますが、それをインストールすることが正しかったかどうかまでは教えてくれません。

ほとんどのチームは、CI/CDパイプラインでSBOMとCVEスキャンを利用しています。これらのツールは、既存のパッケージに含まれる既知の脆弱性を見つけるには非常に優れています。しかし、AIコーディングエージェントを使用する場合、そこには巨大な盲点が存在します。

AIエージェントはパッケージ名を提案します。その名前が実在するものか、ハルシネーション（幻覚）か、あるいはタイポスクワッティング（打ち間違いを狙った悪意ある名前）かに関わらず、エージェントは全く同じ自信を持って提案してきます。

もし攻撃者が昨日、悪意のあるパッケージ名を登録したとしたら、それにはまだCVEが付与されていません。インストール後のスキャンはそれを検出し、「クリーン」と判定します。スキャン自体は正直ですが、間違った問いに答えてしまっているのです。それは「これは悪だと分かっているものか？」という問いに答えているだけで、「この名前が我々のスタックに存在してよいものか？」という問いには答えていません。

SBOMが悪意のあるパッケージを記録する頃には、すでに被害は発生しています。悪意のあるコードは、多くの場合、postinstallスクリプトを介してインストールフェーズ中に実行されます。スキャナーがファイルツリーを認識する前に、環境変数やCIのシークレットを盗み取ってしまう可能性があるのです。

副作用が生じる前に、判定を下す必要があります。

私はこの問題を解決するために、シンプルなツールを作成しました。これは、インストール前のプロベナンス・ゲート（出所確認ゲート）です。スキャナーとは異なる仕組みで動作します。

• npm install が実行される前に名前をチェックします。 • 保証されたベースラインに対して「デフォルト拒否（default-deny）」のアプローチを採用しています。 • 人気パッケージとの編集距離を測定することで、タイポスクワッティングを検知します。 • 既知の安全な名前のいずれにも一致しないハルシネーションを捕捉します。 • .npmrc を検証し、不正なレジストリに接続していないことを確認します。

このツールはオフライン、キーレスで、Pythonの標準ライブラリのみを使用します。ネットワークには接続しません。パッケージの解決（resolve）も行いません。単に提案された名前を見て、「この名前を保証できるか？」と問いかけるだけです。

名前が保証済みのスナップショットにも、人気のあるベースラインにも含まれていない場合、ゲートはDENYを返します。

「何が起きたか」の記録だけに頼るのはやめましょう。「何が起きることを許可するか」を決定し始めるのです。

Source: https://dev.to/alex_spinov/an-sbom-proves-what-you-installed-it-cant-prove-you-should-have-117c

Optional learning community: https://t.me/GyaanSetuAi