Sonatype社の最新レポートによると、2023年にはソフトウェアサプライチェーンへの攻撃が劇的に増加し、2022年と比較して200%増加しました。また、ダウンロードされた依存関係には依然として脆弱性が存在しており、ソフトウェア開発においてさらなる規制とプロセスが必要であることが分かります。
ソフトウェアのサプライチェーン管理とセキュリティを専門とする米国企業、Sonatype によるこの調査では、開発者の課題と AI セキュリティ ソリューションの使用による潜在的なメリットについても取り上げられています。
ジャンプ先:
- 悪意のあるパッケージを拡散させるためのオープンソースソフトウェアへの攻撃
- オープンソースソフトウェアの脆弱性との戦い
- 開発者の課題とオープンソースの依存関係管理の問題
- ソフトウェアサプライチェーン規制
- AI駆動型セキュリティソリューションを利用するメリット
悪意のあるパッケージを拡散させるためのオープンソースソフトウェアへの攻撃
Sonatypeのレポートによると、2022年にはオープンソースソフトウェアのサプライチェーンに対する悪意のある攻撃が大幅に増加し、2023年も増加を続けています。前年比のモニタリングでは、2023年9月時点で245,032個の悪意のあるパッケージが確認されており、これは2022年に確認された悪意のあるパッケージ数の3倍、または過去すべての年の合計数の2倍に相当します（図A）。Sonatypeの調査は、ソフトウェアの依存関係を介したソフトウェアサプライチェーンの侵害が最大の新たな脅威であるという、欧州連合サイバーセキュリティ機関の2022年末の報告と一致しています。
図A
この攻撃の大幅な増加により、多くのオープンソース システムでは、開発者に対する多要素認証の義務化など、新しいセキュリティ ポリシーと改善が実装されています。ただし、多くの場合、悪意のあるパッケージは脆弱性のあるパッケージと同じように扱われ、脆弱性と同じ方法で削除されます。これは、パッケージがより長い時間オンラインに残る可能性があるため、悪意のあるコンテンツには不適切です。
調査回答者によると、組織内の脆弱性が検出されてからそれを軽減するのにかかる時間は次のとおりです (図 B )。
- 1週間から一度も行ったことがない： 39%
- 1日未満: 19.2%
- 1週間以上: 36.2%
- 1時間未満: 3.1%
図B
リポジトリのダウンロードに関しては、既知の脆弱性を持つコンポーネントのダウンロードの約96%は、ダウンロード時に既に修正プログラムが利用可能であったため、回避できました。これは、組織がインストールするソフトウェアのバージョンにさらに注意を払う必要があることを示しています。悪い例として、Log4jの脆弱なバージョンは、依然として同ソフトウェアの新規ダウンロード全体の約4分の1を占めています。
Maven Central リポジトリからの平均月間ダウンロード数 378 億回のうち、39.7 億個の脆弱なコンポーネントが消費されました。
「私たちの業界は、その努力を正しい方向に向ける必要があります。既知の脆弱性を持つコンポーネントのダウンロードのほぼすべてに修正プログラムが提供されているという事実は、開発者がより適切な意思決定者になれるよう支援し、適切なツールへのアクセスを提供することに、当面の焦点を当てるべきであることを示しています」と、Sonatypeの最高技術責任者であるブライアン・フォックス氏はTechRepublicとのインタビューで述べています。
オープンソースエコシステム全体の成長
オープンソース・エコシステム全体が成長していることも興味深い点です。主要4大オープンソース・エコシステム（Java（Maven）、JavaScript（rpm）、Python（PyPI）、.NET（NuGet Gallery））はいずれも、プロジェクト数で前年比27%から28%の成長を示しており、エコシステムごとに36万7,000件から250万件のプロジェクトが存在します（図C）。
図C
この成長は、おそらくCOVID-19パンデミックの影響による2020年から2022年にかけての減速の後、ソフトウェア生産性が上昇したことを示しています。Sonatypeによると、もう一つの説明として、「…これらのプロジェクトの多くは、実際には商業活動から生まれたものであり、パンデミック中に豊富だった余暇を持つ人々から生まれたものではない」ということが挙げられます。
オープンソースソフトウェアの脆弱性との戦い
ソフトウェアの脆弱性を特定する最良の方法はコードレビュー (図 D ) です。コードレビューでは、コードの変更がオンラインに公開される前にピアレビューされます。
図D
次にバイナリチェックを行います。パッケージにバイナリが含まれている場合、脆弱性がないか適切にチェックする必要があります。また、プロジェクトの依存関係を特定のバージョンに固定する必要があります。
メンテナーが更新時に継続的インテグレーションテストやコードレビューなどのワークフローを回避できないようにするには、「default」ブランチと「release」ブランチでブランチ保護が必要です。
さらに、脆弱性の発生率が低いため、適切にメンテナンスされたプロジェクトを利用することが重要です。Sonatypeは次のように述べています。「…オープンソースの脆弱性リスクを最小限に抑えたい企業は、コードレビューを実施し、サポート終了になっていないことを確認するために監視を行っている、適切にメンテナンスされたプロジェクトを選択する必要があります。」
参照:チェックリスト: ネットワークとシステムのセキュリティ(TechRepublic Premium)
開発者の課題とオープンソースの依存関係管理の問題
ソフトウェアサプライチェーンのセキュリティは複雑で、様々な要因の影響を受けます。例えば、開発者はプログラミング上の課題に加え、ソフトウェアプロジェクトで使用するオープンソースコンポーネントについて十分な情報に基づいた選択を行うなど、業務上の責任も負っています。依存関係の管理は、開発者コミュニティでは「依存関係地獄」として知られており、対処が非常に困難です。
例えば、平均的なJavaアプリケーションは148個の依存関係を必要とし、年間約10回のリリースがあります。このようなアプリケーションを開発するには、開発者はこれら148個の依存関係を慎重に選択・管理するだけでなく、年間平均1,500件の依存関係の変更を追跡する必要があります。この追跡にはセキュリティと法務に関する専門知識が必要であり、最も安全なバージョンを選択するためには、すべての開発者がこれらの専門知識を持っているとは限りません。
開発者に効率性とスピードを求めるプレッシャーをかけると、開発者は圧倒され、選択が弱まる可能性があります。
こうした依存関係の選択はソフトウェアの人気度によっても変化しますが、人気のあるコードが必ずしも安全なコードとは限らないため、誤った安心感を与えてしまう傾向があります。リポジトリ内のプロジェクトの85%を占める非アクティブなリリースは、利用可能な選択肢が多すぎて開発者を圧倒してしまいます。
この問題を解決するために、Sonatype は、セキュリティ、ライセンス、年齢、人気、リリースの安定性という 5 つの主要な要素に基づいたスコアリング システムを開発しました (図 E )。
図E
これらのコンポーネントを慎重に分析することで、ソフトウェアサプライチェーン管理における意思決定が容易になります。また、組織のニーズに合わせてカスタマイズでき、開発者が過剰なアップデート処理に時間を浪費するのを防ぐのに役立つリポジトリ管理ソフトウェアの使用も推奨されます。
ソフトウェアサプライチェーン規制
ソフトウェアサプライチェーンの規制はまだ初期段階ですが、多くの国でガイドラインや規制が策定されていることからも、その重要性は十分に理解できます。米国、欧州、英国、オーストラリア、カナダ、日本、ニュージーランドといった主要国における規制措置は、デジタル防御を強化し、組織のインフラを保護するという共通の動機を示しています。
ソフトウェアに本質的にセキュリティ機能が統合されていない場合、ソフトウェアメーカーはより多くの責任と賠償責任を負う可能性が高く、一方でサイバーセキュリティインシデントに対処するための堅牢なプロセスをすべての組織に導入する必要があります。
ソフトウェア開発におけるセキュリティを強化するには、より国際的な協力が不可欠です。Sonatypeのレポートで述べられているように、「…そして将来の関連イニシアチブは、世界規模でのサイバーセキュリティのポリシーと実践の将来を形作る上で極めて重要な役割を果たすでしょう。」
AI駆動型セキュリティソリューションを利用するメリット
人工知能と機械学習は、ソフトウェア開発を変革する力を持つテクノロジーです。
調査によると、AIは広く導入されており、現在97%の企業がワークフローに生成型AIを何らかの形で組み込んでいます。また、DevOps担当者の47%とSecOps担当者の57%が、AIの活用により週6時間以上の時間を節約できたと回答しています。
セキュリティの観点から見ると、AIを活用したソリューションは、従来の方法よりも迅速かつ効率的にソフトウェアコードの脆弱性やバグを特定できます。あらゆるレベルの開発者にメリットをもたらします。
上級開発者はAIツールを活用して、面倒なタスクをこなしたり、コードの一部を開発したりできます。一方、初級開発者は、AIツールが質問に効率的に回答し、技術用語や専門用語への洞察も提供してくれるというメリットがあります。初級開発者と上級開発者の両方がクエリを使用することで、基本的なコードを迅速に開発しながら、プロジェクトのより複雑な問題に集中することができます。AIツールは、コード生成に加えて、貴重なデバッグツールとしても活用できる可能性があります。
AIツールの導入と監視には注意が必要
AIツール、特に大規模言語モデルは、慎重な監視が必要であり、自動化された方法で動作させるべきではありません。LLMは誤った情報や幻覚を経験する可能性があるため、それらを検出し、対処する必要があります。
LLM-as-a-serviceは開発を加速し、パフォーマンスを向上させますが、高頻度で使用するとコストが高くなる可能性があります（企業は送受信されたトークンごとに料金を支払います）。さらに、Sonatypeが述べているように、LLM-as-a-serviceを利用する組織は、「…ベンダーのサービス停止、非推奨機能、あるいはモデルパフォーマンスの予期せぬ変化といった、特定のタスクに合致しない可能性のある状況に脆弱です」。
オープンソースのLLMを組織内で使用する場合、導入には慎重さが求められます。使用するモデルは、用途に応じて慎重に選択し（30万種類以上のモデルが利用可能）、計算要件と構造の性能に合わせて調整する必要があります。ライセンスリスクも存在します。商用利用を制限したり、特定の条件を要求したりするライセンスでリリースされたモデルは、慎重に検討しないと利用規約違反につながる可能性があります。
