依存関係は「時限爆弾」だ：SCAとSBOMでサプライチェーン攻撃を封じ込めろ
やあ。現場でコードを書いている諸君、今日も依存関係のアップデート通知に追われているか？
正直に言おう。現代の開発において、自前で書いたコードなんて全体の10%程度だ。残りの90%は、誰かがどこかで書いたオープンソースライブラリ（OSS）で構成されている。お前たちが使っているそのライブラリ、本当に安全だと断言できるか？
今日のテーマは「依存関係の脆弱性管理（SCA）」と「SBOM（ソフトウェア部品表）」だ。耳触りのいい言葉だが、実態は「いつ爆発するか分からない爆弾の在庫管理」に他ならない。これを怠れば、Log4jの悪夢を再び繰り返すことになる。
—
1. なぜ「依存関係」が最強の攻撃経路になるのか
攻撃者は、もはや強固なファイアウォールを正面突破しようとはしない。彼らが狙うのは「信頼された供給源」だ。
例えば、npmやPyPIに紛れ込んだ悪意あるパッケージ（タイポスクワッティング攻撃）や、長年放置されたライブラリに後から発見された脆弱性。これらを取り込んだ瞬間、お前たちのアプリは「自ら外部からの侵入を許すバックドア」をインストールしたことになる。
PoCのリアル：依存関係が悪用されるシナリオ
1. 偵察: 攻撃者はターゲットの `package-lock.json` や `requirements.txt` を公開リポジトリ（GitHub等）から特定。
2. 脆弱性検索: 特定されたライブラリの既知のCVEをスキャンし、RCE（リモートコード実行）が可能なバージョンを見つける。
3. エクスプロイト: そのライブラリを呼び出すエンドポイントに対し、不正なペイロードを送信。アプリケーション側で意図しないコマンドが実行される。
現場で最も恐ろしいのは、「自分のコードが原因ではないため、ログを見てもどこで何が起きているか全く見当がつかない」という事態だ。
—
2. SCA（Software Composition Analysis）を自動化せよ
「脆弱性が出たら直す」というリアクティブな対応はもう古い。CI/CDパイプラインにSCAツールを組み込み、「脆弱なライブラリはデプロイさせない」というゲートキーパーを設置しろ。
GitHubを使っているなら、まずは「Dependabot」を全リポジトリで有効にするのは基本中の基本だ。だが、それだけでは足りない。GitHub Actionsで自動スキャンを行う例を示そう。
実装例：GitHub Actionsによる脆弱性スキャン (Snyk活用)
.github/workflows/security-scan.yml
name: Security Scan
on: [push, pull_request]
jobs:
snyk-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Snyk to check for vulnerabilities
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }} # Snykのアカウントで発行したトークン
with:
# 脆弱性が発見されたらビルドを失敗させる（重要！）
args: –severity-threshold=high
このように、「High以上の脆弱性があればビルドを落とす」という強制力を働かせる。これが開発現場の規律だ。
—
3. SBOM：お前のシステムは何でできているか？
SBOM（Software Bill of Materials）は、いわばソフトウェアの「成分表示ラベル」だ。どのライブラリの、どのバージョンが、どのようなライセンスで組み込まれているか。これを可視化できなければ、ゼロデイ脆弱性が出た瞬間に「うちのシステムは影響を受けるのか？」という問いに対して、数日間の調査が必要になる。
SBOMの生成（CycloneDX形式）
Node.js環境であれば、`@cyclonedx/cyclonedx-npm` を使って簡単にSBOMを生成できる。
プロジェクトルートで実行
npx @cyclonedx/cyclonedx-npm –output-format JSON –output-file bom.json
この `bom.json` を資産として保管しておけば、新たな脆弱性が報告された際、grepするだけで自社プロダクトの被弾状況が即座に判明する。「即断できる」という状態こそが、インシデントハンドリングにおける最大の武器だ。
—
4. 最後に：エンジニアとしての心構え
「依存関係の管理なんて面倒だ」「アップデートすると動かなくなる」という愚痴をよく聞く。だが、セキュリティとは「面倒なことを仕組みで解決する能力」のことだ。
1. 依存関係を最小化せよ: 不要なライブラリは削除する。依存が少なければ脆弱性の発生確率も減る。
2. 自動化を信じろ: 人間の記憶力や確認作業は当てにならない。ツールに任せろ。
3. SBOMを資産化せよ: 開発の成果物にはソースコードだけでなく、SBOMもセットで付随させる文化を作る。
君たちが書くコードは、世界中のユーザーを守るための防壁だ。その防壁の中に、穴の空いたレンガ（脆弱なライブラリ）を混ぜてはいけない。
明日から、君たちのプロジェクトの `package.json` や `requirements.txt` をもう一度見直してみてくれ。そこに潜む小さな「警告」が、次のインシデントの火種かもしれないのだから。
健闘を祈る。何かあればいつでも相談してくれ。
コメント