「世界の DevSecOps の現状 2024」から得られた知見

AppSec のベストプラクティス

組織の 36% は、OWASP などの第三者組織が推奨するベストプラクティスに依存しています。確立されたガイドラインを順守することで、さまざまな開発環境にわたってセキュリティのベースラインを確保できます。ただし、AI 生成コードによってもたらされる独自のセキュリティ上の課題など、急速に進化する脅威に直面した場合、これらの標準の適応性について疑問が生じます。

たとえば、開発者は一般的に、オープンソースの「スニペット」（大きなコードの一部から抜粋した小さな部分）をソフトウェアに使用するというものがあります。コードのスニペットがどれだけ小さくても、ソフトウェアのユーザーはそれに関連するライセンスに従う必要があります。この問題は、出所を参照せずにコードを生成する AI アシスタントの使用によってさらに悪化しています。公開されているオープンソースのコードベースでトレーニングされた AI ツールは、そのコードがプロプライエタリソフトウェアで使用される場合は特に、生成したコードによって潜在的な IP、著作権、ライセンスの問題をもたらす可能性があります。

ソフトウェアに非準拠のライセンスが 1 つでも含まれていると、法務調査、合併および買収取引の凍結、知的財産権の喪失、修正作業に時間を失い、製品の市場投入の遅延につながる可能性があります。

ブラック・ダックの 2024年度の OSSRA レポートによると、調査したアプリケーションの半数以上（53%）にライセンス競合のあるオープンソースが含まれており、それらのアプリケーションの所有者は潜在的な IP 所有権の問題にさらされています。

統合による AppSec テストの簡素化

回答者の 35% は、優先する自動化とテスト構成の容易さを重視しており、DevOps プロセスへのセキュリティの統合が進んでいることを強調しています。全体として、セキュリティテストの一元化とベンダーの整理により、管理の簡素化、調整の改善、コストの削減が可能になり、組織のデジタル資産保護能力が大幅に向上します。

セキュリティツールを一元管理することで管理インターフェイスが統一され、セキュリティ対策の監視と構成が簡素化されます。これにより、複数の異なるシステムの管理に伴う複雑さが軽減され、パイプラインの各段階での統合が容易になり、セキュリティポリシーの組織全体への一貫した適用が容易になります。一元化されたシステムによって、セキュリティ対策の調整が容易になり、セキュリティの適用範囲のギャップや重複の可能性が減ります。

セキュリティ・テストツールによる DevSecOps におけるノイズ問題

最も印象的な発見の 1 つは、組織が使用しているセキュリティ・テストツールの数の多さです。組織の 82% が 6～20個のツールを使用しています。これは、包括的なカバレッジが実現できるとも言えますが、ツールの数が多いことで、統合や結果の解釈、全般的な管理が著しく複雑になります。これは、セキュリティテスト結果による「ノイズ」という別の重要な課題と密接に関連しています。

また、回答者の 60% は、セキュリティテストの結果の 21% ～ 60% が「ノイズ」、つまり誤検知や重複、競合であると報告しています。このようにノイズのレベルが高いことで、アラート疲れや非効率的なリソースの割り当てにつながる可能性があります。

開発者のための AI革命

90% を超える組織が、ソフトウェア開発に何らかの形で AI ツールを使用していると報告しています。この急速な導入により、生産性向上の機会と AI 生成コードのセキュリティ確保における新たな課題の両方が生じています。回答者の 85% が AI 関連の課題に対処するための対策を講じていると考えている一方で、AI 生成コードのテストに「非常に自信がある」と回答したのはわずか 24% でした。

開発チームが AI ツールを急速に導入しているにもかかわらず、調査結果によると、多くの組織がその導入ペースに追いつくのに苦労しており、AI 生成コードによってもたらされる固有の課題を管理するためのポリシーとツールを導入している最中であることがわかっています。

図1: 開発者のAI使用（許可の有無に関わらず）とセキュリティ対策に対する中程度から高い信頼度との相関関係（ブラック・ダック 「世界の DevSecOps の現状 2024」レポート）

図 1 の一番左のグラフは、AI ツールの使用を全面的に禁止している回答者の 5% 未満が、セキュリティ対策に「ほとんど自信がない」か、「まったく自信がない」と報告していることを示しています。このグループの約 42% は、セキュリティ対策は優先事項ではないと主張しています。AI 対応の開発を許可しないという選択は、AI 生成コードのセキュリティ保護に対する組織的なアプローチが遅れていることに起因している可能性があります。

最も右のグラフは、AI 支援開発ツールの使用を認識しているにもかかわらず、AI 生成コードに対する自動化テストの優先順位が著しく低いためリスクにさらされていると答えた 21% の回答者を示しています。

右から 2 番目のグラフは、回答者の 43% が AI 対応の開発とセキュリティ対策を段階的に導入していることを示しています。おそらく、準備状況に対するわずかな自信に基づいて、限定的な許可が与えられていると考えられます。

最も憂慮されるべきなのは左から 2 番目のグラフです。リスクを軽減するための準備に明らかに自信がないにもかかわらず、回答者の 27% が許可を得て AI を使用している開発チームを持っていることを示しているからです。

セキュリティ/開発速度のトレードオフ

ツールやプロセスの進歩にも関わらず、徹底したセキュリティテストと、必要とされる開発速度の間には緊張関係が残されたままです。回答者の 86% は、セキュリティテストによって開発が多少（「わずか」から「大幅」に) 遅くなると感じています。大多数 (43%) は、テストによって開発が中程度に遅くなると感じています。回答者の 4 分の 1 は、セキュリティテストによって開発/配信がわずかに遅くなると感じており、別の 18% は、セキュリティテストによって開発ライフサイクルが大幅に遅くなると感じています。

回答者がプロジェクトをセキュリティテストのキューに追加する方法と、それが開発やデリバリパイプラインに遅延をもたらす障害になっているかどうかを調べると、さらに深い知見が得られます。セキュリティテストによってパイプラインの速度が大幅に低下していると報告した回答者のうち、33% がテストキューを完全に手動で管理しているのに対し、パイプラインを完全に自動化して管理しているのは 17% でしかありません。

このような統計データは、ボトルネックを発生させることなく、ペースの速い開発サイクルにセキュリティテストをシームレスに統合することが引き続き課題であることを強く示しています。

DevSecOps の向かう先

2024年における DevSecOps の状況における特徴は、急速な AI の導入、ツールの増加、徹底したセキュリティプラクティスと、開発速度のバランスを取るための継続的な取り組みが必要だということです。セキュリティテストの自動化と、開発プロセスへのセキュリティテストの統合の明らかな傾向が見られる一方で、多くの組織は依然としてセキュリティテストの結果による「ノイズ」や、手動プロセスの自動化に粘り強く取り組んでいます。

今後、最も成功する組織は、ツール群を効果的に合理化し、責任を持って AI を活用し、セキュリティテストのノイズを減らし、セキュリティ、開発、運用の各チーム間の緊密な連携を促進できる組織になるでしょう。DevSecOps の旅はまだ終わっていませんが、今後どこへ進むのが良いかについては、より明確になりつつあります。