vpierre/ndaal_public_sbom_auditorCycloneDX、SPDX、syftのSBOMを取り込み、CVEスキャナのアンサンブルを実行し、検出結果をEPSS、CISA-KEV、nucleiで強化し、SARIF、CSAF、PDFをエクスポートするオフラインのシングルバイナリWebアプリ。
SBOM（Software Bill of Materials）ファイルを調査するための、単一バイナリ・オフラインの Web アプリケーション。SBOM をアップロードするか、それらを含むフォルダーをインポートし、独立したツール群のアンサンブルでそれぞれを分析し、正規化された検出結果を 1 つのローカル UI で確認し、結果を 8 つの形式でエクスポートできます。インストール不要、ネットワークアクセス不要、テレメトリなし。
NOASSERTION と、単に存在しないフィールドとを区別します。ホームページ（/）は保存されているすべての SBOM を一覧表示し、コーパスが増えても使い続けられます：
log4j や openssl といったクエリで、そのコンポーネントを含むすべての SBOM を見つけられます。クエリは長さが制限され、寛容に解析されます。/components は逆の問い — 自分の SBOM のうちどれがこのコンポーネントを宣言しているか — に、コーパス全体を一度に、コンポーネント名または正確なパッケージ URL で答えます。これは取り込み時に構築される専用のコンポーネントインデックスを読み取り、ダッシュボードの全文インデックスとは別です。
古いインデックスは、実際に影響を受ける SBOM を「影響なし」と読ませてしまうため、このページはまだインデックスされていない SBOM の数を示し、Rebuild index を提供します。これはまさにそれらのために保持されたバイト列を再解析します。検索が完全になるのは、その警告が消えてからだけです。
「インデックス済み」とはインデックスが構築されたことを意味し、「行を生成した」こととは同じではありません。メタデータのみの SBOM はコンポーネントを宣言しないため、何も寄与しませんが、それでも完全にインデックス済みです。ストアは行の存在から推測するのではなく、SBOM ごとにインデックス化の事実を記録します（スキーマ v8、components_indexed_at）— 推測していたときは、コンポーネントを持たない SBOM が「まだインデックスされていない」集合から決して抜け出せず、警告は再構築のたびに残り、ボタンは同じ SBOM を永遠に新たにインデックスされたものとして報告していました。アップグレードは自動的に移行し、すでに行を持っていたものはバックフィルします。1 回の再構築で残りは解決します。
各ツールは実行時に任意であり、PATH 上で検出されます（バイナリは SBA_TOOL_<NAME>_BIN で上書きできます）。検出結果は決して単一のツールに依存しません。各スキャンの前に、ツールはそのバージョン引数で一度起動されます。バイナリがなければ skip（not found on PATH）となり、起動できないバイナリ、または 15 秒以内に応答しないバイナリは、その理由を伴う fail となります。
| ツール | 役割 | 検証済みバージョン |
|---|---|---|
| syft | SBOM 正規化 / CycloneDX 1.6 コンバーター | 1.52.0 |
| grype | CVE マッチャー | 0.119.0 |
| trivy | 脆弱性スキャナー | 0.74.0 |
| osv-scanner | OSV データベース検索 | 2.4.0, 2.6.0 |
| bomber | 独立したアンサンブルマッチャー | 0.5.1 |
| bomdrift | サプライチェーンドリフト / タイポスクワット（SARIF） | 0.9.9 |
| inspektr | SBOM 脆弱性スキャナー（JSON） | 0.1.9 |
| shieldbom | オフライン組み込み/IoT CVE スキャナー（SARIF） | 0.3.0 |
| provenant | ライセンス / 著作権 / 来歴（ScanCode） | 1.0.10 |
「検証済みバージョン」とは、各呼び出しが実際に実行されたバージョンであり、下限でも固定でもありません。ツールは実行時に PATH 上で解決され、互換性のある任意のバージョンが動作します。osv-scanner が 2 つ挙げられているのは、2.x 系がログ出力を変更した後に 2.6.0 が再検証されたためです — 文書化された scan --lockfile <input> --format json の形式は変わらず、検出時に依然として非ゼロで終了するため、コード変更は不要でした。
最初の 8 つのツールは CVE 形状の脆弱性検出結果を寄与します。provenant は異なります — それはライセンス、著作権、保持者、著作者の来歴を報告し、監査ツールはそれを破棄するのではなく、独自の検出結果形状として保存・表示します（実行ごとの「Licence & provenance」セクションで、Markdown エクスポートにも含まれます）。
スキャナーはすべての形式を直接読めるわけではありません。bomber は CycloneDX ≤ 1.6 のみを消費し、どのスキャナーも SPDX 3.0 JSON-LD を読みません。どちらの場合も、監査ツールはまず syft convert を介して入力を CycloneDX に正規化し、syft が利用できないときは、ツールにゼロパッケージを報告させるのではなく、文書化された理由を伴ってスキップします。grype の脆弱性データベースは実行ごとに 1 回（帯域外で）更新されるため、日常的な古さは失敗したスキャンではなく、新鮮なスキャンとなります。
分析後、各 CVE 形状の検出結果は、vulnlookup サービス（デフォルト https://vulnlookup.ndaal.eu）から取得した 3 つの実際のシグナルでエンリッチされます：
各検出結果は KEV、Nuclei、EPSS、Source の値を表示し、Source は vulnlookup レコードへリンクします。検出結果は最も緊急なものが先頭になるよう並べられます。既知の悪用済み（KEV）エントリが先頭に立ち、次に EPSS パーセンタイルが高いものが続きます。エンリッチメントのない検出結果は、アナライザーが生成した順序を保ちます。エンリッチメントはすべてのエクスポート形式に引き継がれます — SARIF 2.1 / 2.2、Markdown、ODT、DOCX、PDF および CSAF 2.1 / 2.2 で、CSAF は EPSS をネイティブメトリクスとして持ち、CISA-KEV と nuclei をノートとして記録します — そしてエクスポートフォームは現在、デフォルトですべての形式にチェックを入れます。
Settings → Vulnerability enrichment で設定します：オン/オフのトグル（デフォルトで有効）と最大 3 つの vulnlookup ソースで、それぞれにベース URL、TCP ポート、QUIC ポートがあります（空のポートは 443 として扱われます）。ソース 1 と 2 はデフォルトで公開 https://vulnlookup.ndaal.eu のポート 443 を指し、ソース 3 はデフォルトでこのホスト自身の 8680（TCP）/ 8681（QUIC）ポート上のループバック https://127.0.0.1 を指すため、同一設置の vulnlookup がそのまま動作するフォールバックとなります。ソースは順に試され、最初がプライマリ、残りはフォールバックです。
検索はブラウザーではなく監査ツールのサーバープロセスによって行われるため、それが動作するホスト自体が HTTPS 経由でソースに到達できなければなりません。クライアントは TLS 1.3 のみを話し、オペレーティングシステムの CA バンドルを信頼します。到達できない場合、すべての検出結果は Not enriched のままですが分析は完了し、サーバーログには post-analysis enrichment finished と非ゼロの failed= カウントが表示されます（クライアントがまったく起動できなかった場合は post-analysis enrichment failed）。エンリッチメントはすべてのアナライザーが終了した後に 1 回実行されるため、列は実行完了後まもなく埋まります。
結果を読むときは、各検出結果がどのパッケージにマッチしたかを確認してください。パッケージのない検出結果 — たとえば affects fedora @ 40 — の KEV バッジは、インストールされたパッケージではなくオペレーティングシステムのリリースへのマッチに由来し、通常は該当しません。Go 標準ライブラリに対して報告される CVE-2020-0601 も同じ種類のミスマッチです。これは Windows CryptoAPI の欠陥で、Go は 1.13.6 で修正しました。
1 つの検出結果で 3 つのシグナルすべてを見るには、ndaal_public_sbom_examples リポジトリの jenkins:2.60.3 イメージ SBOM（example/anchore-sbom-examples/results/docker.io_library_jenkins:2.60.3/sbom/）を分析してください：Spring4Shell（CVE-2022-22965）と Jenkins Stapler RCE（CVE-2018-1000861）はそれぞれ、KEV バッジ、クリティカルな nuclei テンプレート、0.98 を超える EPSS を持ちます。
GitLab 作業項目 #2 は Create CSAF document アクションを追加します：1 つの SBOM の監査検出結果がドラフト CSAF 2.1 アドバイザリ（ステータス draft、バージョン 0.1.0、トラッキング ID ndaal-sba-draft- に SBOM の SHA-256 の先頭 16 桁の 16 進数を付加）となり、csaf.ndaal.eu のような csaf-crud サービスに提出されます。このビルドにはドラフトジェネレーターと Settings → CSAF upload カードが含まれます：3 つのエンドポイントを順に試し（csaf.ndaal.eu を 2 回、次にこのホスト上の csaf-crud を https://localhost:8180）、ループバックエンドポイントに限り自己署名証明書を信頼するオプトインがあります。SBOM ページのボタン、ドラフトのダウンロード、--export-csaf コマンドラインオプションは次のフェーズで続きます。