ソフトウェアサプライチェーン攻撃を防ぐ方法

ソフトウェアサプライチェーン攻撃は、ますます深刻な脅威となっている。BlueVoyantが最近実施した調査によると、回答企業の実に97%がサプライチェーンにおけるセキュリティ侵害によって悪影響を受けており、38%は、第三者サプライヤーのサイバーセキュリティに潜在的な問題があっても知る手段がないと回答した。Palo Alto NetworksでPrisma Cloud製品担当シニアバイスプレジデントを務めるAnkur Shah氏は、[…].

執筆者
Jeff Goldman
Jeff Goldman
Jun 3, 2022
5 minute read
eSecurity Planet のコンテンツおよび製品のおすすめは、編集上の独立性を保っています。パートナーへのリンクをクリックすると、当社が報酬を得る場合があります。 詳細を見る

ソフトウェアサプライチェーン攻撃は、ますます深刻な脅威となっている。BlueVoyantが最近実施した調査によると、回答企業の実に97%がサプライチェーンにおけるセキュリティ侵害によって悪影響を受けており、38%は、第三者サプライヤーのサイバーセキュリティに潜在的な問題があっても知る手段がないと回答した。

Palo Alto NetworksでPrisma Cloud製品担当シニアバイスプレジデントを務めるAnkur Shah氏は、eSecurity Planetに対し、Log4jやSpring4Shellの脆弱性のような注目度の高い脅威が、こうした懸念を常に意識させてきたと語った。Shah氏によると、こうした脅威が広がっている理由は主に3つあるという。

サプライチェーンの脅威が高まる3つの要因

第1に、Shah氏によると、同氏が開発者だった数年前は、入念なセキュリティテストと品質保証(QA)テストを終えるまで、構築したものがデプロイされることはなかった。「今では開発者は、ほぼすべてをIDEからボタン1つでテスト、セキュリティ確保、デプロイまで数分で実行できる」と同氏は語る。「顧客は、好きなタイミングで毎時間、毎日アプリケーションをリリースしており、企業はそれを歓迎している。これは循環的な傾向であり、変わることはない。品質やセキュリティを理由に、開発者がゆっくり進めるようにはならない」

第2に、開発者の数がセキュリティ専門家の数を急速に上回り、セキュリティ担当者が追いつくのはほぼ不可能になっている。「今や誰もが開発者だ」とShah氏は語る。「開発者は3,300万人を超えるのに対し、セキュリティ専門家は300万人しかいない。だから、セキュリティ側が勝てない戦いなのだ」

第3に、Shah氏によると、同氏が開発者だったころは、コードの約80%が自作で、オープンソースライブラリは20%だった。ところが現在は、その逆であることが多い。「hack me dot comからオープンソースコードをダウンロードすると、それが何であれコンテナイメージの一部になる。そしてどうなるかは誰にも分からない。何十万ものワークロードにデプロイされ、事態は破綻する」と同氏は語る。

しかも、どこかの無名のウェブサイトから入手したものである必要はない。Log4jは、小規模な第三者ベンダーの無名のコンポーネントなどではない。「これはApacheだ」とShah氏は語る。「Apacheの名声の源は、オープンソースの基本中の基本であること、信頼できるベンダーであり、信頼できるコンポーネントであることだ。それでも誰かが脆弱性を発見し、しかも比較的容易に悪用できた」

関連記事:サプライチェーン攻撃を対象とする新たなオープンソースセキュリティイニシアチブ

コードセキュリティのための4つのステップ

Shah氏によると、企業が対応として行うべきことは、コードからランタイムまでアプリケーションのライフサイクル全体を保護することだ。そのためには、プロセス内の少なくとも4つの重要なポイントで、セキュリティを積極的に監視する必要がある。

第1のステップは開発中に行うもので、使用するオープンソースコードが安全であることを確認する。「開発者がIDEでコードを構築しているときに、『このオープンソースコンポーネントをインポートする』と言ったなら、その場で『本当に実行しますか?そのオープンソースコンポーネントには既知の脆弱性があります』と知らせるべきだ」とShah氏は語る。

こうした懸念について開発者の認識を高めることが第一歩となるが、各企業は自社のリスク許容度を判断する必要があると同氏は述べた。フィンテック企業、医療機関、政府機関は、セキュリティとデプロイ速度のバランスを別の形で取りたいと考える他の業界よりも、オープンソースコンポーネントについて慎重になる必要があるだろう。

次に検討すべき領域は、コードとしてのインフラ(IaC)だ。「悪意のある攻撃者は、過度に許可範囲の広いセキュリティグループなど、インフラの弱点を悪用することが多い。したがって、オープンソースコードに加えて、コードとしてのインフラも保護すべきだ」とShah氏は語る。

Shah氏のプロセスにおける第3のステップは、コードリポジトリを保護することだ。「VCS、つまりGitリポジトリに、パブリックインターネットに公開されているといった弱点がないことを確認する。Capital Oneではコードリポジトリが公開され、誰かがそれを悪用できた。多要素認証を使い、社内VPN内からのみアクセスできるようにし、パブリックインターネットから利用できないようにする」

最後に、デプロイ前に追加のチェックを行うべきだ。「コンテナレジストリをスキャンし、CI/CDパイプラインをスキャンして、そこで追加のチェックをもう1回実施していることを確認する」とShah氏は語る。「そして最終段階で、本番環境に移行する」

Advertisement

関連記事:

多層防御

Shah氏によると、この一連のプロセスは多層防御を実現するためのものだ。「1つのステップだけを実施するのではない」と同氏は語る。「コードの作成時、ビルド時、デプロイ時、実行時のあらゆる段階で、こうしたセキュリティのチェックと均衡を実施する。そうすれば、ミスが起きる可能性を最小限に抑えられる」

プロセス全体を通じてチェックを行うことで、コードに対して、欠陥を見つけた人なら誰でも組み立てラインを止められるトヨタの「自働化」のようなアプローチを取ることになると、Shah氏は述べた。「車が組み立てラインを進めば進むほど、問題は深刻になる。だから、できるだけ早く修正する。あらゆる段階で品質チェックを行うのだ」

最後にShah氏は、多くの企業にとって、個別のソリューションをつなぎ合わせるよりも、プラットフォーム型のプレーヤーを検討する価値があると述べた。「セキュリティツールを増やせば安全性が高まるわけではない」と同氏は語る。「むしろ安全性は低下する。セキュリティにプラットフォーム型のアプローチを採用すれば、全体を一元的に可視化でき、ばらばらのものを数多くつなぎ合わせる必要もない」

詳しくはこちら:

Jeff Goldman

eSecurity Planet contributor Jeff Goldman has been a technology journalist for more than 20 years and an eSecurity Planet writer since 2009. He's also written extensively about wireless and broadband infrastructure and semiconductor engineering. He started his career at MTV, but soon decided that technology writing was a more promising path.

eSecurity Planet Logo

eSecurity Planet is a leading resource for IT professionals at large enterprises who are actively researching cybersecurity vendors and latest trends. eSecurity Planet focuses on providing instruction for how to approach common security challenges, as well as informational deep-dives about advanced cybersecurity topics.

TechnologyAdvice が所有・運営しています。 © 2026 TechnologyAdvice. 無断転載を禁じます

広告主に関する開示:このサイトに掲載されている製品の一部は、TechnologyAdvice が報酬を受け取っている企業のものです。この報酬は、製品がこのサイトのどこにどのように表示されるか(表示される順序など)に影響する場合があります。TechnologyAdvice は、市場で入手可能なすべての企業やすべての種類の製品を掲載しているわけではありません。