“ソフトウェア部品表”があれば本当に安全？ 現場にはびこる「誤った安心感」：全権限を握る「CI/CD」を守れ

ソフトウェアの構成を可視化するSBOM（ソフトウェア部品表）があるだけで安全だと思い込むのは早計だ。検証を伴わないSBOMは、かえって危険な状態を招く。開発現場の安全を確保する3つの防衛策とは。

[TechTargetジャパン]

　現代のソフトウェア開発において、ソフトウェアの供給網を狙うサプライチェーン攻撃や、パッチ（修正プログラム）が提供される前の「ゼロデイ脆弱（ぜいじゃく）性」への対処は、避けて通れない課題だ。社内開発インフラの構築・運用を担う部門に「次の攻撃やゼロデイ脆弱性への備えは十分か」と尋ねると、開発現場から悲観的な声が上がるのが実情だ。

　欧米の法規制や政府調達の要件を皮切りに、ソフトウェアの構成要素を可視化する一覧表「SBOM」（ソフトウェア部品表）の提出をベンダーに義務付ける動きが強まっている。しかし、単にリストを作成するだけでは不十分だ。その構成要素が改ざんされていない正しいものであると証明する「アテステーション」（検証）の仕組みがなければ、ソフトウェアを利用する顧客や管理者に対し、かえって誤った安心感を与えてしまう危険性がある。

　このような状況下で、開発効率の向上と安全なインフラの提供を両立する「プラットフォームエンジニアリング」が台頭している。本稿は、プラットフォームエンジニアが実践すべきゼロデイ脆弱性への「3つの防衛策」を紹介する。

ゼロデイ攻撃から開発現場を守るには

併せて読みたいお薦め記事

プラットフォームエンジニアリングのヒント

• プラットフォームエンジニアリングが「“何でも屋”にされる開発者」を救う
• “開発者体験”を向上させる「IDP」の効果　成功の鍵は？

　以下の内容は、クラウドネイティブ技術の標準化を推進する団体であるCNCF（Cloud Native Computing Foundation）が主催した「Platform Engineering Day」におけるパネルディスカッションを基にしている。セキュリティとクラウドネイティブの専門家5人が登壇し、日々の運用に取り入れるべき戦略を提示した。

1．インフラの可視化と避難訓練の実施

　コンテナの脆弱性スキャンツールを開発するAnchoreのジョシュ・ブレッサーズ氏は、最大の課題は「インフラの複雑化」だと指摘する。複数のクラウドや外部サービスが絡み合い、全体の構成を把握することが難しくなっている。自社がどこでどのような仕組みを動かしているのか、その全容を定義し理解することが防御の第一歩となる。

　インシデント発生時に時間をロスしやすいのは、情報伝達の遅れだ。AIセキュリティベンダーであるGadflyAIのサル・キミッチ氏は、本番環境に影響を与えない形での「ゲームデー」（避難訓練）の実施を推奨する。これは開発者を試すものではなく、1時間程度のシミュレーションを通じて「誰がどのシステムを担当し、どのような形式でレポートを作成するか」などの連絡網を確認する組織的な訓練だ。これによって初動スピードが上がるだけではなく、経営層のセキュリティ意識の向上や予算獲得にもつながるという。

2．防御側もAIツールを駆使したCI/CDの保護

　攻撃者はAIエージェントを用いて、公開リポジトリやインフラの脆弱性を探索している。独立系コンサルタントのジャスティン・コーマック氏によれば、AIエージェントは未知のゼロデイ脆弱性を見つけるのではなく、既知の脆弱性をかつてないスピードで悪用している。

　これに対抗するには、防御側もAIツールを導入し、攻撃者と同じ視点で自社のインフラを継続的にスキャンし、問題を抽出するようAIに問いかける必要がある。AIセキュリティツールは問題の発見にとどまらず、修正コードの提案も可能であるため、修復プロセスの自動化に大きく寄与する。

　コンテナセキュリティベンダーChainguardのエリカ・ハイディ氏は、「ソフトウェアのビルドや配備を自動化するCI/CD（継続的インテグレーション／継続的デリバリー）のパイプラインは、全ての秘密情報やデプロイ権限を握る『王国への鍵』だ」と警告する。近年、開発自動化ツールの「GitHub Actions」などの自動化ツールを狙った攻撃が勢いづいている。これに対抗するには、ワークフローの設定を見直し、アタックサーフェス（攻撃対象領域）を最小化することが重要だ。脆弱性が公開されてから攻撃コード（エクスプロイト）が作成されるまでの時間は「わずか数時間程度にまで短縮されている」とハイディ氏は指摘しており、自動化を用いた迅速な対応が不可欠だ。

3．持続可能な開発環境の維持とパートナー選定

　独立系コンサルタントのハンナ・フォックスウェル氏は自身の経験を振り返り、システムの土台となるベースイメージに脆弱性が発見された際、提供元のパッチ配布を待つしかなかった無力さを語った。こうした事態を防ぐには、ハイディ氏が指摘するように、サービス水準合意（SLA）が明確で、迅速にパッチを提供するベンダーを選定することが必須となる。

　キミッチ氏は、「開発者の燃え尽き症候群（バーンアウト）こそが、コードに脆弱性を生み出す最大の要因だ」と指摘する。開発者が複雑なセキュリティ要件に疲弊することなく、本来の開発業務に集中できる仕組みをプラットフォームエジニアリングチームが用意すること。これこそが、中長期的な視点での最大のセキュリティ対策だと言える。

本稿は、CNCFが2026年4月14日に公開した動画「Panel: Platform Engineering to the Rescue - A Practica... Hannah F, Justin C, Sal K, Erika H, Josh B」を基に作成しました。