主要なソフトウェアサプライチェーンの脆弱性の解説
はじめに: 最後に、ソフトウェアの依存関係とビルドプロセスを監査したのはいつですか？残酷な真実は、すべてのオープンソースライブラリが npm install、プルするすべてのDockerイメージ、そしてCIパイプライン内のすべてのスクリプトが潜在的な攻撃ベクトルであるということです。現代の開発は外部コンポーネントと自動化に大きく依存しており、これにより新たな種類のソフトウェアサプライチェーンの脅威への扉が開かれました。実際、サプライチェーン攻撃は急増しており、Sonatypeの報告によると、 70万件以上の悪意のあるオープンソースパッケージが 2019年以降に発見されています。また、ごく最近では、単一のnpmメンテナーアカウントの侵害により、 広く利用されている18のパッケージにバックドアが仕掛けられ、 マルウェアが組み込まれ、毎週数十億回に及ぶダウンロードが危険にさらされました。これらの事件は、開発チーム、DevOpsエンジニア、そしてDevSecOpsの実践者が、これまで以上にソフトウェアサプライチェーンセキュリティに関心を持つ必要がある理由を浮き彫りにしています。
「ソフトウェアサプライチェーンの脆弱性」とは、サードパーティパッケージからビルドツール、CI/CDワークフローに至るまで、コードの構築と提供に関わるプロセスやコンポーネントにおけるあらゆる弱点を指します。攻撃者は、1つのアップストリームコンポーネントを汚染することで、無数のダウンストリームアプリケーションを侵害できることに気づきました。この投稿の残りの部分では、最も重要で一般的に見過ごされている9つのソフトウェアサプライチェーンセキュリティの脆弱性について詳しく説明します。それぞれについて、その仕組み、実際のプロジェクトでの現れ方、それがもたらすリスク、そして軽減方法を説明します。また、現代のセキュリティツール（Aikidoの依存関係スキャナー、シークレット検出、SBOM分析、CI/CDスキャンなど）がこれらの問題を特定または防止するのにどのように役立つかを示すために、Aikido Securityの言及も含まれます。
ソフトウェアサプライチェーンの主要な9つの脆弱性
1. 悪意のあるタイポスクワッティングパッケージ
最も単純なサプライチェーン攻撃の一つが タイポスクワッティング であり、攻撃者が人気のあるライブラリと ほぼ同じ名前を使用して、悪意のあるパッケージをレジストリ（npm、PyPI、RubyGemsなど）にアップロードするものです。その目的は、開発者（またはその自動化ツール）がパッケージ名を誤入力したり誤認識したりすることで、偽のパッケージをインストールさせることです。例えば、脅威アクターは typescript-eslint のようなパッケージをnpm上で @typescript_eslinter/eslintのような名前で偽装し、検出されるまでに数千回のダウンロードを記録しました。これらの偽造パッケージにはしばしば隠されたマルウェアが含まれており、トロイの木馬をドロップしたりデータを外部に流出させたりするインストール後スクリプトを実行する可能性があります。あるケースでは、コードフォーマッターのタイポスクワットが 悪意のある実行可能ファイル（ (prettier.bat）を密かにインストールし、Windowsの起動時に永続化させました。
仕組み: 攻撃者は人気のあるライブラリを監視し、その名称が 一般的なスペルミスや派生形である悪意のあるパッケージを作成します。これは、ハイフンの欠落（types-node と正規のものとの比較）のような些細な違いであったり、 @types/node異なる名前空間であったりする場合があります。攻撃者はこれらのパッケージを、魅力的なバージョン番号や説明を付けて公開リポジトリに公開します。不注意な開発者は、急いで名前を打ち間違えたり、間違ったパッケージを選択したりして、悪意のあるコードを取り込んでしまう可能性があります。パッケージ名が1文字でも間違っている場合、自動化されたスクリプトやCIシステムも同様に脆弱です。
リスク: 一度インストールされると、悪意のあるパッケージはアプリケーションのビルドと同じ権限で実行されます。環境変数（シークレット）を窃取したり、バックドアをインストールしたり、セカンドステージのマルウェアをダウンロードしたりする可能性があります。企業環境では、単一の汚染された依存関係が多くのアプリケーションやサービスに拡散する可能性があります。これらの攻撃は、被害が発生するまで開発者が間違いに気づかないことが多いため、非常に巧妙です。パッケージマネージャーに対する信頼が悪用され、開発者のマシンやCIランナー上でコードが実行されることで、認証情報の窃取、データ流出、サーバーの侵害につながる可能性があります。
緩和策: タイポスクワッティングから防御するために、開発者はパッケージ名を再確認し、公式または検証済みのソースからのみライブラリをインストールする必要があります。パッケージレジストリアカウントで2FAを有効にします（攻撃者が似たようなスコープやプロファイルを作成するのを防ぐため）。多くのエコシステムでは現在、パッケージの署名または検証を提供しています。これらの機能を使用して、信頼性を確保してください。自動化されたツールを組み込むことも重要です。例えば、依存関係スキャナーは、既知の公式ライブラリと一致しない疑わしいパッケージや名前をフラグ付けできます。承認されたパッケージの「許可リスト」またはパッケージURL (pURL)識別子を使用することで、見た目が正しいだけのものをインストールするのを防ぐことができます。新しい依存関係を追加する際には、チームに警戒するよう教育してください。
Aikidoの依存関係スキャナーは、既知の悪意のあるパッケージやタイポスクワットの亜種がビルドに取り込まれる前に自動的に検出できます。例えば、Aikidoの SafeChain 機能は、新規または悪意のあることが判明しているパッケージをブロックし、危険な npm install が成功するのを防ぎます。プロジェクトのマニフェストとロックファイルをスキャンすることで、Aikidoは react-router がマルウェアの偽物ではなく、実際のReact Routerであることを確認するのに役立ちます。このようなプロアクティブなスキャンとポリシー（例えば、パッケージに特定の経過期間や人気度を要求するなど）は、 タイポスクワッティング攻撃を早期に阻止し、サプライチェーンをクリーンに保つことができます。
2. 依存関係の混乱（内部パッケージと公開パッケージの混同）
依存関係の混乱は、名前空間の混乱攻撃とも呼ばれ、プライベート（内部）パッケージとパブリックパッケージを併用する組織に対する巧妙なエクスプロイトです。これは、パッケージマネージャーが名前を解決する方法を悪用します。内部パッケージ名が誤ってパブリックレジストリ上のパッケージと一致した場合、攻撃者は同じ名前でより高いバージョンのパブリックパッケージを公開して、リゾルバーを「混乱させる」ことができます。その結果、ビルドシステムは、意図した内部パッケージではなく、パブリックレジストリから攻撃者のコードをプルする可能性があります。この攻撃ベクトルは、2021年にセキュリティ研究者Alex Birsanによって有名に実証されました。彼は、大手テクノロジー企業（Apple、Microsoft、Teslaなど）の内部プロジェクト名と一致する不正なパッケージをアップロードすることで、数十社を侵害しました。
発生の仕組み: 例えば、貴社が @acme/widget-core という内部npmパッケージをバージョン1.3.0でプライベートレジストリにホストしているとします。プロジェクトのpackage.jsonは @acme/widget-coreを要求しています。もし攻撃者が @acme/widget-core バージョン9.9.9をnpm（公開）に公開し、ビルドがプライベートソースにロックされていない場合、パッケージマネージャーは公開レジストリから9.9.9を取得する可能性があります（新しいリリースだと考えて）。この悪意のあるパッケージには、 postinstallスクリプト インストール時に自動的に実行され、ビルド環境でリモートコード実行を達成するものです。CI/CDパイプラインでは、これは特に危険です。コードは、機密性の高い環境変数、ソースコード、デプロイキーにアクセスできる可能性のあるビルドエージェント上で実行されるためです。
リスク: 依存関係の混同は、ビルド環境または開発環境の即時的な侵害につながる可能性があります。悪意のあるペイロードは、リポジトリ内のコードを変更することなく、シークレット（APIキー、トークン、認証情報）を窃取したり、ビルドされたアプリケーションにバックドアを仕込んだりする可能性があります。これは、有害なコードが意図せずプルした依存関係内に存在するため、リポジトリの従来のコードレビューや脆弱性スキャンを効果的に回避します。その影響は深刻になる可能性があります。攻撃者は（ビルドサーバーが侵害された場合）企業ネットワークへのラテラルムーブメントを獲得したり、顧客に提供されるソフトウェアに悪意のあるロジックを挿入したりする可能性があります。内部パッケージ名の衝突がどれほど一般的であるかを考えると、これは広範な脅威の表面です。
緩和策: 依存関係の混同を防ぐには、以下の組み合わせが必要です。 技術的制御と衛生管理。常に プライベートパッケージのスコープを明示的に設定し 特定のネームスペースに対してプライベートレジストリを優先するようにパッケージマネージャーを設定してください。npmの @acme:registry .npmrc内の設定やpipのインデックス設定を使用して、 依存関係を意図したソースにロックする必要があります。 厳密なバージョン固定 とロックファイルを使用し、たとえより新しいバージョンが他の場所で現れても、ビルドが自動的にそれを取り込まないようにしてください。公開パッケージレジストリで、内部パッケージ名が誤って漏洩していないか監視してください（攻撃者は公開リポジトリの言及や設定ファイルを通じてこれらを推測することがよくあります）。多くの組織では現在、プロキシとしてアーティファクトリポジトリを使用しており、それによって 承認されたパッケージのみ がフェッチされるようになっています。これにより、未知のパッケージ（名前が一致していても）がプルされないようにするゲートが作成されます。最後に、依存関係設定の定期的な監査とSBOM（ソフトウェア部品表）の生成は、予期しない外部パッケージが紛れ込んでいないかを発見するのに役立ちます。
Aikidoのプラットフォームは、依存関係の混乱シナリオを捕捉する機能を備えています。例えば、Aikidoの依存関係スキャナーは、パッケージマニフェストを公開ソースとプライベートソースの両方と照合します。npm/PyPIに存在するが内部であるべき依存関係名を発見した場合、アラートを発します。Aikidoはまた、特定のレジストリのみを許可するポリシーを適用したり、ネームスペース制御を強制したりすることで、ビルドが意図せず信頼できないソースにアクセスするのを防ぎます。SBOM分析を通じて、Aikidoはビルドでどのパッケージバージョンとソースが使用されたかを正確に可視化し、意図しない公開パッケージが内部アプリに紛れ込むのを検出・防止しやすくします。要するに、Aikidoは、意図しないコードなしに、構築したものがまさに意図したものであることを保証するのに役立ちます。
3. ハイジャックされたライブラリとプロテストウェア（侵害されたメンテナー）
すべてのサプライチェーン攻撃が新しい偽のパッケージから来るわけではありません。時には 信頼されたパッケージが悪意のあるものになる メンテナーアカウントの侵害や意図的な妨害行為が原因で発生します。攻撃者が（メンテナーへのフィッシング、認証情報の窃取、またはセキュリティの甘さを悪用して）正当なパッケージの制御を奪うと、 トロイの木馬化されたアップデート を公開し、利用者はそれを通常の新しいバージョンだと思ってダウンロードしてしまいます。これは September 2025「qix」として知られるメンテナーが フィッシングされた そして攻撃者は、18の人気npmライブラリに悪意のあるアップデートをプッシュしました。 debug, chalk、および ansi-regex. これらのライブラリは合計で週に数十億回ダウンロードされており、わずか2時間の悪意のあるコードの公開でも、その影響は甚大でした。別のシナリオは「プロテストウェア」と、オープンソースのメンテナーが意図的にライブラリを変更する（例えば、政治的なメッセージを表示するため、あるいはさらに悪いことに、特定の国のシステムを妨害するため）ものです。どちらの場合も、長年信頼し使用してきたパッケージが突然 脅威となる武器に変わる可能性があります。.
仕組み: 攻撃者は影響の大きいパッケージを標的にします。多くの場合、開発者が更新に気づかないように、依存関係ツリーの深いところにあります。一般的な戦術には、メンテナーのログイン認証情報のフィッシング（上記のnpmインシデントのように）やOAuth/トークンの漏洩の悪用が含まれます。アクセス権を得ると、悪意のあるペイロードを含む新しいバージョンを公開します。これらのペイロードは非常に高度な場合があります。2025年のnpm攻撃では、注入されたコードはブラウザコンテキストでのみアクティブになる暗号ウォレット窃盗犯でした。他のバックドアは、環境データを収集したり、リバースシェルを開いたり、データを暗号化したり（ランサムウェア形式）する可能性があります。バージョンが依然として意味的に有効であり（例：4.4.2から4.4.3）、隠された悪意のある副作用を除けばパッケージが通常どおり機能することが多いため、検出される前に広く拡散する可能性があります。ユーザーは通常、セキュリティスキャナーが異常な動作を指摘するか、コミュニティ/公開レジストリがそれを発表したときにのみ侵害を発見します。
リスク: 明らかなリスクは、信頼された依存関係を装って悪意のあるコードを実行していることです。これにより、機密情報の盗難につながる可能性があります（npmインシデントのマルウェアは暗号通貨取引を標的としましたが、認証トークンや顧客データも同様に標的とすることができます）。これはソフトウェアの整合性を損ないます。コードが安全であっても、侵害されたライブラリはそれを完全に破壊する可能性があります。さらに、これらの攻撃はエコシステムへの信頼を損ないます。チームは、恐怖からアップデートを停止する（正当な修正を見逃す）可能性があります。最悪の場合、広く使用されている侵害されたパッケージは、すべてのインストールが攻撃者にコールバックするボットネットを本質的に作成するため、一度に多くの企業へのバックドアとして機能する可能性があります。
緩和策: ハイジャックされたパッケージから防御するのは、信頼の裏切りであるため厄介です。しかし、被害範囲を制限するためのベストプラクティスがあります。依存関係の更新には健全な懐疑心を持って対応してください。特に頻繁に更新されないコアユーティリティについては、新しいバージョンの変更ログと差分を確認してください。新しいパッケージバージョンに対して自動マルウェアスキャンを活用してください。一部のツールはパッケージの動作を分析します（新しいバージョンが突然ネットワーク呼び出しを開始したり、システム情報を読み取ったりするかどうかを検出するなど）。バージョンを固定すること（およびレビューなしで最新版に自動アップグレードしないこと）は、コミュニティレポートを観察する時間稼ぎになります。ロックファイルとチェックサム検証（npm、pipのハッシュチェックモードなどでサポートされている）を使用すると、期待どおりのものがインストールされていることを確認できます。また、自身でパッケージを公開する場合は、2FAと検証を有効にすることを検討してください。プロセス的な観点からは、依存関係のインベントリ（SBOM）を維持し、侵害されたパッケージを使用している場合に迅速に特定して対応できるようにします。
Aikidoの継続的な依存関係監視がここで真価を発揮します。Aikidoのスキャナーは既知のCVEをチェックするだけでなく、 不審なパッケージの挙動 および依存関係内の既知のマルウェアシグネチャ。例えば、新しいバージョンの requests PyPI上でインストール時に突然ネットワーク接続を開こうとした場合、Aikidoはその異常をフラグ付けします。Aikidoは脅威インテリジェンス（既知の侵害されたパッケージやハイジャックされたパッケージのフィードを含む）を統合しているため、サプライチェーン内の依存関係が妨害されたと報告された場合に警告できます。さらに、Aikidoの AutoFix そして 脆弱性フィードs悪意のあるバージョンがすり抜けた場合でも、プラットフォームは安全なバージョンに戻すかアップグレードするための修正PRを推奨し、自動的に開くことさえできます。鍵はスピードです。Aikidoはこれらのインシデントを早期に検出し、 対応を自動化します。露出期間を短縮します。
4. コードまたはCI内の露出したシークレットと認証情報
認証情報とシークレットは王国の鍵であるとよく言われます。サプライチェーンセキュリティの文脈では、漏洩したシークレット（APIキー、クラウド認証情報、署名キーなど）は、あらゆるマルウェアと同様に危険です。なぜでしょうか？攻撃者がGitHubリポジトリやビルドログで有効なAWSキーやCI/CDトークンを発見した場合、それを直接使用してシステムに侵入したり、パイプラインを汚染したりすることができるからです。漏洩した認証情報は主要な侵害原因です。Verizonデータ侵害レポートによると、2024年の侵害の22%は露出した認証情報によって引き起こされました。サプライチェーンの観点から見ると、ソースコードや設定ファイル内のシークレットは、攻撃者が不正なコードを公開したり（認証情報を使用して）、プライベートパッケージレジストリにアクセスしたり、悪意のあるアーティファクトをデプロイメントにプッシュしたりすることを可能にします。
発生の仕組み: シークレットはさまざまな方法で漏洩する可能性があります。開発者が誤ってコミットしてしまうことがあります。 .env データベースパスワードを含むファイルを公開リポジトリにアップロードするケース。あるいは、CI/CDパイプラインが機密性の高いトークンを世界中から読み取り可能なログに出力する可能性もあります。さらに巧妙な手口として、初期アクセス権を獲得した攻撃者が、ハードコードされたキーをコードベースから検索する可能性があります。一度取得されると、これらのシークレットはアカウントを偽装するために使用される可能性があります。例えば、AWSキーがあれば、攻撃者は汚染されたコンテナイメージをプライベートECRレジストリにプッシュし、デプロイ時にそれがプルされる可能性があります。GitHubの個人アクセストークンがあれば、攻撃者はリポジトリにコードをコミットしたり、リリースを改ざんしたりする可能性があります。CIパイプラインにおいて、攻撃者がCIまたはクラウドの認証情報を入手した場合、通常のコードレビューを効果的にバイパスし、悪意のあるコンポーネントやインフラストラクチャを直接挿入することができます。
リスク: 直接的なリスクは不正アクセスです。露出したクラウドキーは、インフラストラクチャの侵害やデータ盗難につながる可能性があります。露出したパッケージレジストリの認証情報は、攻撃者がマルウェアを含む内部ライブラリの新しいバージョンを公開することを可能にする可能性があります（これはハイジャックされたパッケージのシナリオへの別の経路です）。CIでは、漏洩したトークンにより、攻撃者がビルド構成を変更したり、ボールトからシークレットを取得したり、アーティファクトを傍受したりする可能性があります。本質的に、シークレットは合鍵のようなものです。攻撃者がそれらを入手すると、ソフトウェアの脆弱性をエクスプロイトすることなく、システム内を移動できることがよくあります。これにより、本番環境全体の侵害から、攻撃者がアーティファクトを密かに変更する（例えば、リリースパイプライン内のバイナリをバックドア付きのものと交換する）ことまで、あらゆる事態が発生する可能性があります。これらのシナリオは、ソフトウェアデリバリープロセスの整合性が盗まれた信頼によって破られるため、サプライチェーン攻撃の一部です。
緩和策: 最善の緩和策は、そもそもシークレットを漏洩させないことです。言うは易く行うは難しですが、具体的なプラクティスがあります。リポジトリでシークレットスキャンツールを使用して、APIキーやパスワードがコミットされる前に捕捉します。GitHubのようなGitプロバイダーはシークレットスキャンを統合しています。これを有効にしてください。コードに機密性の高い認証情報をハードコードしないでください。代わりに環境変数またはシークレット管理サービスを使用します（そして、リポジトリが設定ファイルにそれらの値を含まないことを確認します）。CI/CDでは、ログ内のシークレットをマスクします（ほとんどのプラットフォームには、シークレット環境変数の出力防止オプションがあります）。何かが漏洩した場合でも、有効期間が短いように、定期的にキーをローテーションします。最小特権の原則を採用します。読み取りアクセスのみを持つ漏洩したトークンは、管理者トークンよりもはるかに被害が少ないです。高特権のキーについては、可能であれば多要素認証またはIP制限を適用します。シークレットの使用状況を監視します。例えば、アプリのみが使用すべきキーが他の場所で使用され始めた場合、それは危険信号です。
Aikidoのシークレット検出機能は、漏洩した認証情報を早期に捕捉するように設計されています。コード、設定ファイル、さらにはCIパイプライン定義をスキャンし、APIキー、秘密鍵、トークンなどに一致するパターンを検出します。例えば、誰かが誤ってGitHub Personal Access TokenやAWSのシークレットキーをコミットした場合、Aikidoはそれを即座に検出し、削除とローテーションを可能にします。しかし、検出は物語の一部に過ぎません。AikidoはCIと統合して、シークレットが発見された場合にビルドを失敗させることができ、機密情報の偶発的なデプロイを防ぎます。また、どこにどのようなシークレットがあるかのインベントリを維持するのに役立ち、ボールトやシークレットマネージャーの使用を補完します。シークレットスキャンを開発ワークフロー（IDEプラグイン、pre-commitフック、CIチェック）に統合することで、Aikidoは開発者が認証情報をリポジトリやパイプラインから遠ざけるのを支援し、攻撃者がサプライチェーン侵害で利用する最も簡単な経路の一つを遮断します。
5. 不適切なCI/CDパイプライン設定（攻撃対象としてのパイプライン）
CI/CDパイプラインは、実質的にソフトウェアファクトリーの組立ラインです。設定が誤っていたり、安全でなかったりすると、攻撃者はそのラインから生み出されるすべてを改ざんできます。CI/CDシステム（GitHub Actions、Jenkins、GitLab CIなど）は、コードの取得、依存関係の統合、テストの実行、アーティファクトのプッシュ、さらには本番環境へのデプロイまで、広範なアクセス権を持つことがよくあります。これにより、それらは格好の標的となります。一般的なパイプラインセキュリティの問題には、過度に広範なアクセス権限、分離の欠如、デフォルトの安全でない設定の使用などがあります。最近の分析では、ソフトウェアサプライチェーン攻撃の約23.8%がCI/CDビルドの脆弱性をエクスプロイトしていることが判明しており、パイプラインセキュリティが現在主要な戦線であることを強調しています。実際には、攻撃者がCIの設定ミスをエクスプロイトして横方向に移動した事例も見てきました。例えば、インターネットに公開された設定ミスのJenkinsサーバーや、意図せず信頼できないコードを実行するCIジョブ（サンドボックスなしで外部コントリビューターからのPRをビルドするなど）は、侵害につながる可能性があります。
その現れ方: 一つのシナリオは、過剰な権限を持つパイプラインランナーです。クラウドへの管理者アクセス権を持つ、またはアーティファクトを直接デプロイできるCIエージェントを想像してください。攻撃者がCIに侵入できる場合（コードインジェクション、侵害された認証情報、またはCIツールのエクスプロイトを通じて）、彼らは事実上「王国の鍵」を手に入れたことになります。ビルドにマルウェアを注入したり、CIエージェントを使用してインフラストラクチャでコマンドを実行したりできます。もう一つのシナリオは、受信コードに対するチェックを強制しないことです。例えば、シークレットを外部に持ち出したりテストをスキップしたりするためのCI設定変更を含む悪意のあるプルリクエストは、コードレビューが緩い場合にすり抜ける可能性があります。また、多くのCIパイプラインは、シークレット（署名キーやデプロイ認証情報など）を環境変数としてマウントします。パイプラインがビルドをトリガーできるユーザーや実行されるコードを制限するように設定されていない場合、それらのシークレットは、ビルドを操作する攻撃者によって盗まれる可能性があります。例えば、一部のデフォルト設定では、フォークされたリポジトリのPRがシークレットへのアクセス権を持つメインCIを実行することを許可する場合があります。これは、悪意のある貢献者にシークレットを漏洩させる可能性がある既知の危険な設定です。
リスク: CI/CDパイプラインが侵害された場合、攻撃者はビルド時またはデプロイ時にソフトウェアを侵害する直接的な経路を得ます。これにより、不正なコードが本番環境またはユーザーに出荷される可能性があります（ソース管理に存在しなかった悪意のあるコードがビルド中に追加されることを想像してみてください）。また、広範なデータ漏洩につながる可能性もあります。CIシステムには、機密情報を含むログやアーティファクトが含まれていることがよくあります。安全でないパイプラインは、他の場所への足がかりとして悪用される可能性があります。例えば、Jenkinsサーバーが内部サービスへのネットワークアクセスを持っている場合、Jenkinsを侵害した攻撃者はそれらのサービスをエクスプロイトできます。本質的に、脆弱なCIは、ソフトウェア製品とインフラストラクチャの両方への入り口となります。また、見過ごされがちな領域でもあります。開発チームはアプリケーションコードのセキュリティに注力しますが、パイプラインを同じ厳密さで精査しない場合があります。
緩和策: CI/CDパイプラインを保護するには、それらを本番資産として扱う必要があります。まず、アクセスをロックダウンします。CIシステムが公開されていないことを確認し、VPNまたはIP許可リストを使用し、機密性の高いジョブをトリガーするには認証を要求します。パイプラインの認証情報には最小特権の原則を適用します。例えば、ビルドジョブがアーティファクトリポジトリへのプッシュアクセスのみを必要とする場合、クラウド管理者権限も与えないでください。ジョブ/ステージごとに個別の認証情報を使用します。次に、入力をサニタイズします。公開されているワークフロー（誰でもPRを開けるオープンソースプロジェクトなど）の場合、シークレットのない隔離されたランナー環境を使用するか、信頼できないコードの実行には手動承認を要求します。多くのCIプラットフォームでは、フォークされたPRでシークレットを利用できないようにマークできます。パイプラインで監査ログを有効にします。ビルド構成で誰が何を変更したかを把握します。もう1つの重要なプラクティスは、CI依存関係を固定することです。パイプラインがビルドコンテナまたはサードパーティのアクション/プラグインを使用している場合、それらを特定のバージョンまたはハッシュに固定し（「latest」タグを避けて）、攻撃者が何かを入れ替えるのを防ぎます（これについては次のセクションで詳しく説明します）。CIツール自体の脆弱性も出現するため、CIソフトウェアとプラグインを定期的に更新してください。最後に、各ビルドに一時的な隔離されたランナーを使用することを検討してください（可能な場合）。これにより、1つの侵害されたビルドが攻撃者の足がかりとして永続化するのを防ぎます。
Aikidoは、CI/CDセキュリティスキャンを提供し、パイプライン構成を監査してベストプラクティスと潜在的な設定ミスを特定するのに役立ちます。例えば、AikidoはGitHub ActionsワークフローやJenkinsファイルを分析し、ピン留めされていないアクション、広範な権限を持つセルフホスト型ランナーの使用、フォークされたPRに公開されたシークレットなどの問題を検出できます。これはCIセキュリティのリントツールのように機能します。Aikidoのプラットフォームは、CIパイプラインとも統合され、ポリシーを適用します。権限のないブランチからデプロイジョブを実行しようとした場合や、重要なワークフローファイルがPRで変更された場合、Aikidoは追加の承認を要求できます。パイプライン設定を継続的にスキャンすることで、Aikidoは「ソフトウェアファクトリー」が十分に保護されていることを保証します。つまり、開かれたドアがなく、攻撃者がプロセスを乗っ取る簡単な方法がない状態です。DevOpsチームと連携して機能するCI/CD構成の監視役と考えてください。
6. 汚染されたパイプライン依存関係（サードパーティのCI/CDツールとアクション）
現代のパイプラインでは、さまざまな サードパーティツール、Dockerイメージ、スクリプト、アクションを タスク（コードカバレッジ、デプロイなど）を実行するために使用されます。これらはそれぞれ、サプライチェーンにおける暗黙の依存関係です。そのいずれかが悪意のあるもの、または侵害されたものである場合、パイプライン（および結果として得られるソフトウェア）が侵害される可能性があります。その顕著な例は、 への攻撃でした。 reviewdog/action-setup GitHub Actionと、その後の tj-actions/changed-files 2025年の事例です。攻撃者は、これらの広く使用されているCIアクションの更新プロセスを悪用することで、悪意のあるコードを注入し、それらを使用するすべてのプロジェクトがCIランナーからシークレットを漏洩させる原因となりました。同様に、Codecov Bashアップローダーのようなパイプラインスクリプト（2021年に侵害されました）を考えてみてください。何千ものパイプラインが、データを密かに外部に送信していたツールを信頼していました。これらのインシデントは、攻撃者がどのようにして 供給源を汚染できるかを示しています。 パイプラインが依存するツールを標的にすることで、供給源を汚染できるかを示しています。
仕組み: 攻撃者は、サプライチェーンに脆弱性を持つ人気のCI/CDユーティリティやイメージを探します。例えば、コミットに署名しないメンテナーや、Dockerイメージ内の古い依存関係などです。アップストリームプロジェクトを侵害する（アカウント乗っ取り、エクスプロイト、または貢献者として潜入する）ことで、悪意のあるコードを挿入できます。GitHub Actionsのケースでは、攻撃者がメンテナーのアカウントまたはトークンにアクセスし、 アクションコードを改ざんしました。Gitリファレンスを再タグ付けし、「v1」とタグ付けされていたものが悪意のあるコミットを指すようにしました。 uses: reviewdog/action-setup@v1 ワークフローで突然、シークレットをダンプする汚染されたアクションをプルしました。CIシステムは通常、実行ごとに最新のタグ付きコードをフェッチするため、パイプラインは知らず知らずのうちにサードパーティの改ざんされたコードを実行する可能性があります。CIで使用されるDockerイメージ（ビルドまたはテスト用）も同様にリスクにさらされています。誰かが悪意のある更新をイメージにプッシュした場合、 node:alpine パイプラインが使用している場合、そのイメージに含まれるものが実行されます。
リスク: ここでの影響はライブラリのハイジャックに似ていますが、潜在的にはさらに直接的です。CIツールは多くの場合、高い権限（一部のGitHubランナーはsudoなど）と資格情報へのアクセス権を持って実行されます。汚染されたアクションやスクリプトは、環境のシークレットをすべて即座に外部に送信したり、ビルド/テスト中のコードにバックドアを注入したりする可能性があります。実際のあるインシデントでは、悪意のあるGitHub ActionがCIシークレットを公開ログにダンプしていました。もう1つのリスクは、侵害されたビルドツールがコンパイルされた出力を改ざんする可能性があることです（常に特定の脆弱性やバックドアをバイナリに挿入する悪意のあるコンパイラを想像してみてください）。防御側にとって難しいのは、これらのパイプラインの依存関係が、コードの依存関係ほど厳密に精査されない可能性があることです。多くのチームは、Dockerイメージやオープンソースのアクションが広く使用されているという理由だけで盲目的に信頼しています。これにより、攻撃者は密かに侵入する手段を得て、侵害は（もし発見されたとしても）ずっと後になるまで発見されない可能性があります。
緩和策: アプリケーションの依存関係をピン留めするように、 パイプラインの依存関係もピン留めしてください。。GitHub Actionsでは、 @v1 または @main アクションに特定のコミットSHAを使用することで、密かに変更されることを防ぎます。Dockerイメージの場合、 latestを使用する代わりに、ダイジェストまたは特定のバージョンを使用してください。これにより、毎回既知の良好なバージョンが実行されることが保証されます。次に、検証し、信頼しつつも確認してください。広く信頼されているアクションやツールを優先し、 そして 理想的には検証メカニズム（一部のアクションはGitHubによって検証済みであるか、署名されています）を備えているものを選択してください。アップストリームの通知を監視してください。使用しているサードパーティツールのセキュリティフィードを購読し、侵害があった場合にアラートを受け取れるようにしてください。可能な場合は、重要なパイプラインツールをベンダーから購入するか、セルフホストしてください。例えば、ビルド時にインターネットからランダムなスクリプトをプルする代わりに、レビュー後にコードベースに組み込むことで、意図しない変更を防ぎます。リスクの高いステップにはサンドボックスを使用してください。例えば、リンターやテストカバレッジツールを、アクセスが制限された隔離されたコンテナで実行します。最後に、GoogleのSLSA（Supply Chain Levels for Software Artifacts）のようなフレームワークをパイプラインに採用することを検討してください。これは、ビルドプロセスを強化し、ビルドステップのプロベナンスを要求するためのガイドラインを提供します。
🛡 Aikido Securityのポイント: AikidoのCI/CDスキャンは、 パイプラインの依存関係。ワークフローが可変タグを持つアクションを参照しているか、または信頼できない可能性のあるソースからプルしているかをチェックします。例えば、Aikidoは、 uses: someaction@latest を使用していることを検出し、コミットにピン留めすることを推奨します。Aikidoの依存関係スキャナーは、アプリケーションコードだけでなく、 ビルドコンテナやツール の既知の脆弱性やマルウェアシグネチャもスキャンできます。CIでベースDockerイメージを使用している場合、AikidoはそのイメージのSBOMをスキャンし、既知の不正なコンポーネントが含まれていないことを確認できます。本質的に、Aikidoはパイプラインの構成要素がアプリケーションの構成要素と同じくらい安全であることを保証します。これらのチェックを統合することで、AikidoはCIツールやアクションが隠れたバックドアにならないようにします。もし一般的なツールが 実際に 侵害された場合、Aikidoの脅威インテリジェンスが更新され、パイプラインが影響を受けるとアラートが通知されます。これにより、損害が発生する前に迅速に対応（例：パイプラインの一時停止、安全なバージョンへの更新）することが可能になります。
7. ピン留めされていないバージョンと可変な依存関係（「最新」の問題）
浮動的な、または ピン留めされていない依存関係のバージョン はサプライチェーンの脆弱性であり、2つの方法で問題を引き起こす可能性があります。知らないうちに 悪意のあるアップデート、またはバグのある/脆弱なアップデート を取得してしまう可能性があります。これは常に「latest」をプルするためです。Dockerのベースイメージが :latest とタグ付けされている場合でも、npmで ^1.0.0 のようなパッケージのバージョン範囲を使用している場合でも、固定されていないバージョンを使用すると、今日のビルドが昨日とは異なるコンポーネントを取得する可能性があります。これはビルドの再現性を損ない、攻撃者が動きを仕掛ける機会を与えます。例えば、攻撃者がパッケージを侵害し、特定の既知の良好なバージョンにピン留めしていない場合、次のビルドは侵害されたバージョンを取得してしまいます。先に議論されたGitHub Actionsの攻撃では、プロジェクトが可変タグ（v1）を参照していたことが一因でした。攻撃者はこのタグを悪意のあるコミットにリポイントしました。コミットSHAや正確なバージョンなどの厳密なピンを使用していれば、そのタグのリダイレクトがビルドに影響を与えるのを防ぐことができたでしょう。
仕組み: 例えば、 requests>=2.0 をrequirementsファイルで使用しているPythonプロジェクトを考えてみましょう（これにより、任意の新しい2.xバージョンが許可されます）。pip installを実行すると、最新の2.xリリースがフェッチされます。もしメンテナー（または攻撃者）が requests 2.999 を明日リリースし、それに問題があった場合、環境が予期せず変更されます。あるいは、Dockerfileが FROM node:latestを使用しているとします。Nodeチームがそのイメージを更新するたびに（または攻撃者が似たようなイメージをプッシュした場合）、ビルドは内容が異なる可能性のある新しいイメージをプルします。ピン留めされていない依存関係は、基本的にサプライチェーンの制御を外部のタイムラインに委ねることになります。攻撃者は、アップデートをプッシュするアクセス権を得た場合、多くのユーザーが自動アップグレードすることを知っているため、これを特に好みます。悪意のあるアクターがいなくても、問題のあるアップデートが障害を引き起こしたり、気づかないうちにセキュリティホールを導入したりするリスクがあります。悪名高い left-pad インシデント （パッケージの削除によってビルドが世界的に停止した事例）は、多くのプロジェクトが外部の最新バージョンを暗黙的に信頼した際に何が起こり得るかを示す一例です。
リスク: 主なリスクは制御と可視性の欠如です。同じコードをビルドしていると思っていても、実際には基盤となるライブラリやイメージが変更されている可能性があります。その変更は、重大な脆弱性（新しいCVEを含むバージョンに自動アップグレードした場合）や悪意のあるロジックであることも考えられます。サプライチェーン攻撃ではタイミングが重要です。攻撃者がビルド中に一時的に不正なバージョンを導入できれば、たとえそのバージョンが後で修正されたとしても、彼らの勝利となります。ピン留めされていない依存関係はインシデント対応も困難にします。特定のビルドでどのバージョンが使用されたかを正確に把握していなければ、悪意のあるリリースや脆弱なリリースによって影響を受けたかどうかを追跡することは困難です。本質的に、これは安全なビルドの基盤となる再現性と追跡可能性を損ないます。ソフトウェアビルドの整合性は決定論的な入力に依存しますが、「最新」は決定論的とは対極にあります。
軽減策: 常に依存関係を既知の良好なバージョンまたはダイジェストにピン留めまたはロックしてください。パッケージマニフェストでは正確なバージョン番号を使用し、ロックファイル（package-lock.json、Pipfile.lockなど）を採用して、すべてのユーザーと環境が同じ解決済みバージョンを使用するようにします。Dockerイメージの場合、特定のバージョン、またはさらに良いのはダイジェストSHA（不変です）にピン留めしてください。Gitベースの依存関係やアクションの場合、コミットハッシュにピン留めします。範囲を許可する必要がある場合（マイナーアップデートを取得するため）、自動的にプルするのではなく、新しいバージョンを通知する信頼できるボットや更新ツールを使用することを検討してください。ソース管理（またはメタデータファイル）で明示的に追跡されていないアーティファクトをビルドが消費しないというポリシーを実装します。さらに、各リリースでSBOMを維持してください。これは、製品内の正確なコンポーネントバージョンのリストです。そうすることで、リスクが発生した場合（例えば、バージョンXがY日に侵害された場合）、どのリリースにそのバージョンが含まれていたかを迅速に照会できます。また、依存関係の更新プロセスを個別にテストすることも賢明です。本番ビルドで盲目的に更新するのではなく、ステージングまたはCIジョブで更新をテストして問題を捕捉できるようにします。最終的に、バージョンをピン留めすることで制御が可能になります。アップストリームの変更に驚かされるのではなく、検証後にアップグレードするタイミングを決定できます。
Aikidoのツールは強く推奨しています 依存関係のピン留めとバージョンの可視性。AikidoがプロジェクトのSBOMを生成する際、すべてのコンポーネントとバージョンをリストアップし、「浮動」する依存関係がないことを強制するのに役立ちます。AikidoはCIと統合して、 ピン留めされていない依存関係を使用するビルドを失敗させる または可変タグを使用するビルドを失敗させ、セーフティネットとして機能します。例えば、誰かが FROM python:latest Dockerfileで、またはピン留めされたSHAなしでGitHub Actionを追加した場合、Aikidoのスキャナーがそれをフラグ付けします。さらに、Aikidoの依存関係管理機能は、セキュリティコンテキストを考慮しながら、制御された方法で依存関係を更新するためのプルリクエストを自動的に開くことができるため、古いバージョンに固執することなく安全にアップグレードできます。Aikidoを使用してオープンソースコンポーネントを監視および管理することで、実質的に 何がビルドされているかを正確に把握できます。その知識には力（とセキュリティ）があります。
8. 既知の脆弱性を持つ古いコンポーネント
「最新」の問題とは対照的に、既知のセキュリティ脆弱性（CVE）を持つ古い依存関係を実行するリスクがあります。これはより伝統的な脆弱性ですが、間違いなくサプライチェーンの懸念事項です。ソフトウェアのセキュリティは、その依存関係グラフにおける最も弱いリンクと同じくらいしか安全ではありません。攻撃者は、組織がパッチ適用を怠っている人気ライブラリの既知の欠陥をしばしば悪用します。例えば、公開された重大なCVEを持つStruts、Log4j、またはOpenSSLライブラリの古いバージョンを使用すると、アプリケーションでリモートコード実行やデータ侵害につながる可能性があります。これは実質的に、サプライチェーンの更新失敗です。オープンソースの爆発的な増加により、すべてを最新の状態に保つことは困難です。しかし、ソフトウェア構成分析 (SCA)レポートは、かなりの割合のアプリケーションが既知の欠陥を持つ古いライブラリを使用していることを一貫して示しています。脆弱なオープンソースコンポーネントを含んでいる場合、攻撃者は新しいエクスプロイトを作成する必要はなく、既存のCVEを悪用するだけで済みます。
発生の仕組み: 多くの場合、開発チームは何らかの機能のためにライブラリを含めますが、その後 更新を忘れてしまいます。そのライブラリが他のライブラリ（推移的依存関係）を引き込む可能性があり、そのチェーンのどこかに重大なバグが存在するかもしれません。例えば、古い lodash プロトタイプ汚染の脆弱性を持つバージョンに依存するパッケージを引き込むNode.jsアプリを考えてみましょう。コードに問題がなくても、その脆弱性を介してアプリがエクスプロイト可能になる可能性があります。CI/CDやビルドツールにも古いコンポーネントが潜んでいることがあります。例えば、ビルドコンテナにShellshockバグのある古いOSパッケージが含まれていたり、CIサーバー自体がパッチ適用されていなかったりするかもしれません。通常、その兆候は、スキャナーやペネトレーションテストによって既知のCVEが発見されるか、さらに悪いことにインシデントが発生する（例：そのコンポーネントを介してアプリがハッキングされる）ことです。悪名高い事例としては、 Log4j「Log4Shell」脆弱性 (CVE-2021-44228)でした。多くの組織が古いLog4jバージョンを使用しており、不意を突かれて実環境でのエクスプロイトの被害を受けました。このようなシナリオこそ、プロアクティブなサプライチェーンセキュリティが防ぐことを目指すものです。
リスク: 既知の脆弱なコンポーネントによるリスクは単純明快です。攻撃者はすでにそれらをエクスプロイトする方法を知っています。脆弱性が公開されると、多くの場合、概念実証エクスプロイトまたは少なくとも詳細な説明が伴います。攻撃者は、脆弱なコンポーネントを使用していると思われるアプリケーションやサービス（例えば、アプリのヘッダーや特定の動作をチェックする）をインターネット上でスキャンします。もしソフトウェアがそのコンポーネントを使用し、適用可能な方法で公開されている場合、標的となります。これは、脆弱性に応じて、完全なシステム侵害、データ盗難、またはサービス停止につながる可能性があります。直接的なエクスプロイト以外にも、コンプライアンスや顧客信頼の問題もあります。既知の脆弱性を実行することは、規制や契約上のセキュリティ要件に違反する可能性があります。これはセキュリティ衛生状態が悪いことの指標です。サプライチェーンには、自身で作成するコードだけでなく、消費するコードも含まれることを忘れないでください。更新を怠ることは、攻撃者のプレイブックに詳細に記載されている防御の穴を残すようなものです。
緩和策: の文化を取り入れましょう 継続的な依存関係管理。これは、プロジェクト（およびコンテナイメージ）を定期的にスキャンして既知の脆弱性を検出することを意味します。SCAツールを使用して、依存関係のバージョンにCVEが報告された場合にフラグを立てます。多くのパッケージマネージャーには、現在監査コマンドがあります（例： npm audit, pip audit)をリストアップします。これをCIの一部とし、新たな脆弱性が導入された場合にビルドが警告を発するか失敗するようにします。パッチ適用済みバージョンへのアップグレードを促すプロセス（DependabotやAikidoのAutoFixのようなボットによる自動化も可能）を設けます。すべてのCVEが同じではないため、優先順位付けが重要です。重大度が高いものや、アプリケーションからアクセス可能なソフトウェアに存在する脆弱性に焦点を当ててください。また、以下も確認してください。 ビルドおよびデプロイ環境を更新します。 例えば、ベースとなるDockerイメージをセキュリティパッチで常に最新の状態に保ち、CIツールやプラグインをパッチ適用済みリリースに更新します。もう一つの重要な点は、 ソフトウェア部品表（SBOM）を維持することです。 前述の通り、これにより「今週話題になっているライブラリを使っているか？」という問いに素早く答えることができます。Log4Shellが発生した際、優れた対策を講じていた組織は SBOM プロセスは、Log4jがどこで使用されているかを即座に検索し、見つけることができます。最後に、使用している主要なプロジェクトのセキュリティ速報を購読し、新たな脆弱性が発生した際に事前に通知を受け取れるようにしてください。迅速なパッチ適用は不可欠です。攻撃者は、発表から数日、あるいは数時間以内に人気のCVEをエクスプロイトし始めることがよくあります。
Aikidoの依存関係スキャナーとSCA機能は、この特定の問題に対処するために構築されています。プロジェクトをスキャンしてすべてのオープンソースコンポーネントを特定し、継続的に更新される脆弱性データベースと照合します。出力は単なる問題のリストではなく、Aikidoは重大度、利用可能な修正の有無、さらには AutoFix機能といった実用的な情報を提供します。 安全な更新パッチを自動的に生成できます。例えば、Mavenプロジェクトが古いStrutsライブラリに致命的な欠陥を抱えている場合、Aikidoは安全なバージョンを提案し、 pom.xml を更新できます。さらに、Aikidoは開発ワークフロー（IDEプラグイン、PRチェック、CI）全体に統合されており、既知の脆弱性がソフトウェアが本番環境に移行した後ではなく、早期に検出されるようにします。また、SBOMの生成も容易にし、ソフトウェアに含まれるものの可視性を提供します。これにより、一般的なライブラリにおける次のゼロデイ脆弱性がニュースになった際にも、Aikidoダッシュボードを迅速に照会して影響を受けているかどうかを確認できます。 更新を常に把握することは Aikidoが継続的に監視し、古いコンポーネントが未対応のまま放置されないようにすることで、はるかに容易になります。
9. 整合性検証の欠如（不十分な署名とオリジン検証）
最後に強調すべき脆弱性は、よりシステム的な問題です。それは、コンポーネントの整合性とオリジンを検証しないことです。言い換えれば、ソフトウェアサプライチェーンを流れるコードやバイナリに対して、署名、チェックサム、またはプロベナンスを使用または確認しないことです。整合性検証がなければ、本質的にデフォルトで信頼していることになります。攻撃者は、アーティファクトを改ざんしたり、ソースになりすましたりすることで、これを悪用できます。例えば、ハッシュ/署名を検証せずに平文HTTP経由で、またはミラーサイトからサードパーティ製ライブラリやインストーラーをダウンロードした場合、中間者攻撃者が改ざんされたバージョンを提供する可能性があります。同様に、コンテナイメージが信頼できる当事者によって署名されていることを検証しない場合、誰かがバックドア付きのそっくりなイメージを実行するように仕向ける可能性があります。CI/CD内であっても、検証の欠如は、攻撃者が1つのステップを侵害した場合、後続のステップが出力を盲目的に信頼する可能性があることを意味します。Dockerの世界での典型的なケースは、「ゴーストライティング」またはイメージレイヤー改ざん攻撃でした。これは、イメージの内容がマニフェストダイジェストを変更せずに改ざんされ、簡易的な検証を回避するものでした。この原則はサプライチェーン全般に当てはまります。厳格な整合性チェックがなければ、攻撃者は気づかれない変更を忍び込ませることができます。
仕組み： コード署名と検証が、ここでの主要な防御策です。多くのパッケージエコシステムは現在、パッケージ署名（例：npmのパッケージ署名、PyPIの今後の署名など）をサポートしており、コンテナレジストリはイメージ署名（NotaryによるDocker Content TrustやKubernetes向けSigstore Cosignなど）をサポートしています。これらが使用されていない、または強制されていない場合、ネットワークトラフィックを傍受したり、ビルドパイプラインを侵害したりできる攻撃者は、正規のものとして受け入れられる悪意のあるアーティファクトを挿入する可能性があります。整合性検証の欠如には、依存関係の整合性を検証しないことも含まれます。例えば、ダウンロードしたライブラリのチェックサムをベンダーが公開したものと照合しないことです。CIでは、ソースの身元を検証しないこと（Gitコミットが署名されているか、期待されるリポジトリからのものであるかを確認しないことなど）は、誤ったコードを取り込むことにつながる可能性があります。このシナリオはしばしば高度な攻撃であり、例えば、巧妙な攻撃者がアーティファクトサーバーへのDNSまたはBGPルートを侵害し、短期間マルウェアを提供したり、ビルドサーバーを侵害してコンパイル後にバイナリを改ざんしたりする可能性があります。署名/ハッシュを検証していなければ、それに気づくことはないでしょう。
リスク： 明らかなリスクは、ソフトウェア整合性の完全な侵害です。攻撃者によって改ざんされたソフトウェアを出荷し、他のすべてのセキュリティ対策を損なう可能性があります。これは、インストーラーファイル、アップデート、または広く配布されるコンテナイメージのようなものにとって特に懸念されます。ここでの攻撃は、甚大な影響範囲を持つ可能性があります（ビルドシステムの侵害がトロイの木馬化されたソフトウェアアップデートにつながったSolarWinds事件に類似）。もう一つのリスクはサプライチェーンアテステーションです。コンポーネントの整合性を証明できなければ、安全な環境でそれらを信頼することは困難です。検証済みのプロベナンスに対する業界および規制当局からの推進が増加しています（例：米国安全なソフトウェアに関する大統領令は、SBOMと署名による整合性チェックを要求しています）。検証の欠如は、依存関係の置き換えのようなより単純な攻撃も許容する可能性があります（攻撃者は、検証しないため、ビルドマシン上のファイルやライブラリを入れ替えることができます）。本質的に、検証しないことは攻撃者が創造的になるための招待状です。なぜなら、明らかに何かが壊れた場合にのみ攻撃者を捕らえることができ、隠れた変更は気づかれないからです。
緩和策： 開発ライフサイクルにおいて、署名と検証のプラクティスを採用し始めてください。ビルドおよび配布するパッケージとコンテナに対してGPGまたはSigstore署名を有効にし、同様に消費するものの署名を検証してください。例えば、リリースからのバイナリを使用する前に、そのGPG署名を検証するか、少なくともそのSHA-256ハッシュを公式のものと比較してください。コンテナデプロイメントでは、Cosignのようなツールを使用して、期待される公開鍵に対してコンテナイメージを検証したり、アドミッションコントローラーを利用して未署名のイメージをブロックしたりします。アーティファクトに対するゼロトラストを実装してください。ファイルがネットワーク上にあるからといって安全であるとは限りません。検証してください。すべてのパッケージおよびアーティファクトのダウンロードにはHTTPSを使用してください（現在ではほとんどがデフォルトですが、誰もダウングレードしていないことを確認してください）。内部ビルドプロセスでは、再現可能なビルドやビルド出力のハッシュを保存して改ざんを検出するなどの手法を検討してください。CIまたはデプロイにおいて、「既知の良好なチェックサムまたは署名に一致するアーティファクトのみを許可する」というアドミッションコントロールを導入することは、上流で何か不正なことが起こった場合の最後の防衛線となり得ます。重要なのは、検証を自動化し、義務付けることです。これにより、開発者が警告を手動で「OK」とクリックするのではなく、パイプラインが未検証のコードを拒否するようになります。
Aikidoは複数の方法で整合性の確保を支援します。SBOM分析と署名ツールとの統合を通じて、Aikidoは依存関係とコンテナが主張どおりのものであることを検証できます。例えば、AikidoはSigstore/cosignと統合し、パイプラインを通じてデプロイされるコンテナイメージが組織からの有効な署名を持っていることを保証できます。署名がない場合は、フラグを立てるかブロックします。Aikidoのプラットフォームは、スキャンされたコンポーネントのチェックサムも追跡します。アーティファクトのコンテンツが予期せず変更された場合（SBOMまたは以前のスキャンと一致しない場合）、それはレッドアラートとなります。さらに、Aikidoの脆弱性データベースとポリシーには、「このパッケージは公式ソースからのものか？」といったチェックが含まれており、これは間接的に整合性をカバーします（誰かが偽のパッケージソースを忍び込ませた場合、Aikidoはメタデータの不一致を通じてそれを検出します）。Aikidoを導入することで、チームは自動化された整合性ゲートキーパーを手に入れます。これにより、コードコミットからビルド、アーティファクトのデプロイまで、各要素が追跡可能で信頼できるものになります。他のプラクティス（スキャン、シークレット管理など）と組み合わせることで、開発者はソフトウェアサプライチェーンがエンドツーエンドで安全であるという自信を得ることができ、Aikidoがチェーンの各リンクを検証します。
結論：初日からサプライチェーンを保護する
ソフトウェアサプライチェーン攻撃は複雑に聞こえるかもしれませんが、これまで見てきたように、多くの場合、未検証の依存関係、安全でないパイプライン、漏洩した認証情報、未検証のアーティファクトといった、むしろ基本的なギャップを悪用します。良いニュースは、これらの一般的な脆弱性の種類を認識することで、開発チームが積極的に対策を講じて欠陥を解消できることです。セキュリティは後から誰かが対処するものではなく、開発の初日から始まり、すべてのコミット、ビルド、デプロイメントを通じて継続されます。開発者フレンドリーなセキュリティアプローチを採用するということは、依存関係スキャン、シークレット検出、CI/CD監査といったプラクティスを後回しにするのではなく、日々のワークフローに組み込むことを意味します。
悪意のあるnpmパッケージからCIパイプラインの侵害まで、脅威は現実のものであり、増大しています。しかし、適切な考え方とツールがあれば、一歩先を行くことができます。チームに「サプライチェーン衛生」を実践するよう奨励してください。インポートするものをレビューし、シークレットを定期的に変更して保護し、ビルドプロセスをロックダウンし、すべてを検証します。最新のDevSecOpsツールを使用して、可能な限り自動化を進めましょう。実際、Aikido Securityのようなプラットフォームを活用することで、これをはるかに容易にすることができます。Aikidoはインテリジェントなセキュリティアシスタントとして機能し、リスクのある依存関係や設定を早期に検知し、インシデントになる前に（多くの場合自動で）修正をガイドします。
見出しを飾るような攻撃が行動を強制するのを待たないでください。今すぐソフトウェアサプライチェーンのセキュリティを管理しましょう。CI/CDパイプラインとIDEにセキュリティツールを統合することから始めましょう。例えば、Aikidoの無料開発者ツールキットを試して、依存関係とパイプラインの脆弱性やシークレットをスキャンしてください。これらの脅威について開発者を教育し、彼らがオープンソースの単なる消費者ではなく、保護のステークホルダーとなるようにしましょう。警戒心とスマートなセキュリティ自動化の助けを借りて、コードからクラウドまでのサプライチェーンが攻撃者に対して回復力があるという自信を持ってソフトウェアを提供できます。安全なコーディングと構築は速度の障害ではなく、製品の信頼と信用への投資です。今日、チームがこれらのプラクティスを採用するように促し、次のサプライチェーンの警告事例となるリスクを大幅に削減しましょう。ハッピー（そして安全な）コーディング！
続きを読む:
Docker コンテナのセキュリティ脆弱性トップ9
クラウドセキュリティ脆弱性トップ7
すべてのチームが知っておくべきWebアプリケーションセキュリティ脆弱性トップ10
Kubernetesのセキュリティ脆弱性および設定ミス トップ9
最新のアプリケーションで見つかるコードセキュリティ脆弱性トップ
開発者が避けるべきPythonセキュリティ脆弱性トップ10
最新のWebアプリにおけるJavaScriptセキュリティ脆弱性トップ
