こんにちは！日々の開発やインフラの管理、本当にお疲れ様です。
今回は、OWASP Top 10（Webアプリケーションの脆弱性ランキング）の「A06:2021-脆弱で古いコンポーネント」というテーマについて、新人のIT担当者や、これからセキュリティをしっかり学んでいきたいという開発者の皆さんに向けて、優しく丁寧に紐解いていきたいと思います。
「コンポーネント」と言われても、なんだか難しそうに聞こえますよね。でも、安心してください。身近な「防犯」の例えを交えながら、一歩ずつ一緒に学んでいきましょう！
—
1. 家の鍵に例える「コンポーネント」とサプライチェーンの落とし穴
突然ですが、みなさんが自分でお家を建てたり、リフォームしたりするときを想像してみてください。
すべてのネジやドアノブ、窓ガラスを、自分の手でゼロから作り上げる人って……まずいませんよね？ プロの職人さんであっても、メーカーが作った既製品のパーツ（部品）を組み合わせて、効率よく頑丈な家を建てていきます。
現代のソフトウェア開発も、これとまったく同じなんです。
ゼロからすべてのプログラムを書くのではなく、世界中のエンジニアが作ってくれた便利な部品（ライブラリやフレームワーク）をたくさん組み合わせて、効率よくWebアプリを作っています。
この「便利な部品のリスト」のことを、業界では SBOM（Software Bill of Materials：ソフトウェア部品表） と呼びます。料理にたとえるなら、食品の裏側に書いてある「原材料表示ラベル」のようなものです。
攻撃者は「一番ろくでなしの古い鍵」を狙う
ここで問題になるのが、私たちが使っている「便利な部品」の中に、実は古い泥棒の合鍵が出回っているようなもの（既知の脆弱性）が混ざっているケースです。
例えば、ある有名な海外製のドアノブ（部品）に「ドライバーで簡単にこじ開けられてしまう欠陥」が見つかったとします。メーカーはすぐに新しい改良版を出して「アップデートしてください！」と叫びました。
でも、私たちはどうでしょう？
「動いているから、まあいっか」と、古いドアノブをそのまま使い続けていませんか？
攻撃者（泥棒）は、私たちが書いた複雑なプログラムの暗号をわざわざ解こうなんて面倒なことはしません。彼らは、世の中に公開されている「過去に発見された古い部品の弱点リスト」片手に、「あそこのサイト、何年も前にアップデートをサボった古い部品をそのまま使ってるぞ！しめしめ」と、裏口からスルスルと侵入してくるのです。これが、サプライチェーン攻撃の恐ろしいメカニズムです。
—
2. 対策の主役：SCA（ソフトウェア構成解析）とは？
「じゃあ、自分が使っている何百、何千という部品の中に、古い泥棒の合鍵が混ざってないかなんて、手作業でチェックしきれないよ！」と思いますよね。その通り、人間の目や手作業では絶対に限界が来ます。
そこで登場するのが、SCA（Software Composition Analysis：ソフトウェア構成解析）という仕組みです。
SCAは、いわば「お家のセキュリティ診断士」のような存在です。私たちが使っている部品のリスト（SBOM）をスキャンして、「おいおい、君たちが使っているその部品、去年の2月に危ないってニュースになった古いバージョンだよ！ 今すぐ新しいものに交換しなさい！」と、お医者さんのようにピンポイントで教えてくれます。
—
3. 実践！日々の開発にSCAツールを組み込もう
それでは、実際に現場でどうやってこの仕組みを取り入れるのか、具体的な設定を見ていきましょう。
今回は、多くのプロジェクトで使われている Node.js（npm）の環境を例に、プロジェクトの部品に脆弱性がないかをチェックする手順をご紹介します。
ステップ1：npmを使った脆弱性チェック
Node.jsの世界では、標準機能として簡単なSCAチェック（npm audit）が用意されています。ターミナルを開いて、プロジェクトのルートディレクトリで以下のコマンドを叩くだけです。
# プロジェクトが依存している外部パッケージ（部品）の脆弱性をスキャンする
npm auditもし、古い部品が見つかると、以下のようなレポートが表示されます。
# 実行結果のイメージ
found 2 vulnerabilities (1 moderate, 1 high)
Run `npm audit fix` to fix them, or `npm install` for detailsここで「high（重大）」といった警告が出たら要注意です。慌てずに次のステップに進みましょう。
ステップ2：脆弱性の自動修復とアップデート
警告が出た場合、多くのケースでは以下のコマンドで自動的に安全なバージョンに引き上げてくれます。
# 安全なバージョンに自動修復を試みるコマンド
npm audit fixただし、バージョンが大きく変わる場合（メジャーバージョンのアップデートなど）、アプリの別の場所で動かなくなる不具合（デグレ）が起きる可能性があります。
そのため、必ず npm audit fix を実行した後は、ローカル環境でアプリを起動して、ログインや主要な機能がちゃんと動くかテストするようにしてくださいね。
—
4. 自動化が命：CI/CDパイプラインに組み込もう
「よし、たまに手動でチェックしよう！」と思ったそこのあなた。実はそれだと、忙しくなるとつい忘れてしまい、穴が開いたままになってしまいます。
プロの現場では、コードをGitHubなどのリポジトリに「プッシュ（保存）」した瞬間や、本番環境へ「デプロイ（公開）」する自動化の仕組み（CI/CD）の中に、SCAツールを組み込むのが鉄則です。
例えば、GitHub Actionsを使う場合の設定ファイル（.github/workflows/security-scan.yml）のサンプルを書いてみました。
# GitHub Actionsで定期的に、またはコードのプッシュ時に脆弱性をスキャンする設定
name: Dependency Vulnerability Check
on:
push:
branches: [ "main" ]
# 毎日夜間に自動でスキャンを走らせる設定（ゼロデイ対策）
schedule:
- cron: '0 0 * * *'
jobs:
sca-scan:
runs-on: ubuntu-latest
steps:
- name: ソースコードをチェックアウト
uses: actions/checkout@v4
- name: Node.js環境のセットアップ
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: 依存関係のインストール
run: npm ci
- name: 脆弱性スキャン（SCA）の実行
# 深刻度「high」以上の脆弱性が見つかった場合はビルドを失敗させる設定
run: npm audit --audit-level=highこのように、「危ない部品が混ざっていたら、そもそも本番に出荷（ビルド）できない仕組み」をシステム的に作ってしまうのが、インシデントを防ぐ一番確実で泥臭くない賢いやり方です。
—
5. まとめ：今日からできる一歩
セキュリティの世界では、「完璧な要塞を作る」ことよりも、「見つかった穴に素早く気づいて、絆創膏を貼り直す（パッチを当てる）スピード感」のほうが何倍も大切です。
- 私たちが使う便利な部品には、いつか「古い鍵」の烙印が押される日が来ます。
- SBOMで自分の使っている部品を把握し、SCAツールに定期健診を任せましょう。
- 「気づいたらすぐ直す」の自動化を、小さなプロジェクトからでも始めてみてください。
「うわ、うちのプロジェクト、去年のライブラリそのままだったかも……」と思った方、大丈夫です。今気づけたことが、最高のセキュリティ第一歩なんですから！
一歩ずつ、安全で強いシステムを一緒に作っていきましょうね。
コメント