開発者セキュリティにおいてツールの統合が重要な理由

クラウドネイティブアプリケーションへの脅威が増大するなか、セキュリティリーダーは、絶えず変化するリスク環境に対抗するため、かつてないほどのプレッシャーにさらされています。しかし、セキュリティソリューション市場が急速に拡大するなか、こうした高まる要求に応えるために製品を追加する組織も少なくありません。

セキュリティ課題に対応する新しいツールが次々と登場するなか、いつも「手の届かないところにあるツールが正解」だと思えてしまうこともあります。しかし、セキュリティ技術スタックにツールを次々と追加すると、ある時点から組織全体の効率や費用対効果が高まるどころか、かえって損なわれます。さまざまな意味で、ツールの乱立は現代のセキュリティリーダーが直面する最大の課題の一つです。

ツールの乱立による影響を解消するには、セキュリティリーダーがいったん立ち止まり、セキュリティツールを現実的な方法で統合する必要があります。Gartnerの調査によると、2022年にはすでに75%の組織がセキュリティベンダーの統合を進めていました。多くの組織がセキュリティツールの乱立による悪影響を認識し、その結果、セキュリティへの取り組みを統合し始めています。

セキュリティツールを統合しないことの代償

すでに多様化しているツール群にツールを追加しすぎると、セキュリティチームはツールの乱立による悪循環に陥りがちです。ツールが過剰なセキュリティ技術スタックは、リスクを軽減しようとする組織に不要な複雑さをもたらします。さらに、開発者のセキュリティにとって特に大きな妨げとなり、セキュリティプロセスを複雑にして、導入しにくくします。ここでは、ツールの乱立が組織にもたらす悪影響と、業界全体でセキュリティツールの統合が進む主な理由をいくつか紹介します。

限られたセキュリティリソースの不適切な活用

セキュリティ部門はもともと人手もリソースも不足しています。Enterprise Strategy Groupによると、半数以上の組織で、サイバーセキュリティ人材やスキルの深刻な不足が生じています。そのため、ツールが過剰なセキュリティ技術スタックを管理する人員が足りません。人手不足のセキュリティチームには、新しい開発者向けトレーニングや管理プロセス、ROIの追跡、導入を継続的に定着させるための投資に取り組む時間がありません。これらは新しいツールを導入するたびに必要になります。

開発パイプラインのボトルネック

今日、多くのセキュリティチームは、アプリケーション開発にDevSecOpsのアプローチを取り入れる価値を認識し、ソフトウェア開発ライフサイクルのできるだけ早い段階にセキュリティ対策を組み込んでいます。ツールの乱立は、組織がこれを実現する妨げになります。開発パイプラインに異なるツールやインテグレーションが混在すると、摩擦が生まれ、可視性のギャップが広がり、SDLCのボトルネックとなります。さらに、新しいツールを導入するたびに新たなAPIが加わるため、ツールを横断するセキュリティ自動化の実装は運用上の悪夢となります。

開発チームとセキュリティチーム双方の時間を浪費する

セキュリティツールごとに、レポートの仕組みは大きく異なります。異なるコンソールやダッシュボードを確認する作業は、やがて多大な時間を要するようになります。こうしたばらばらのレポートは、インシデントへの迅速な対応を妨げ、開発者による導入への抵抗を招くことも少なくありません。別のESGレポートによると、「回答者（サイバーセキュリティ担当者）の27%は、自社のセキュリティ製品が大量のセキュリティアラートを生成するため、セキュリティインシデントの優先順位付けや調査が難しいと答えています。つまり、セキュリティツールが増えるほど、アラートが増え、作業が増え、問題も増えるのです。」

セキュリティツールを統合するメリット

技術スタックが管理しきれない状態になり、上記のような問題が生じないよう、組織は可能な限りセキュリティを統合する必要があります。

これには、同じ種類のサイバーセキュリティツール（AppSecツール同士、クラウドツール同士など）を統合するだけでなく、より幅広い取り組みも含まれます。Infrastructure as Code（IaC）の普及とクラウドの成長により、アプリケーション、ソフトウェアサプライチェーン、クラウドセキュリティの境界は、かつてないほど曖昧になっています。カスタムコード、オープンソースライブラリ、コンテナ、インフラストラクチャなど、さまざまな要素が一つのアプリケーションに含まれています。開発の観点では、これらのコンポーネントはそれぞれ全体を構成する一部です。すべて同じプロジェクト内のコードです。そのため、ツールの統合は単に「同種のツール」をまとめることではありません。ツールを切り替えることなく、開発者がこれらさまざまなコンポーネントすべてを保護できるようにすることが重要です。

ツールの統合で実現できること…

• 全体的なリスクの低減。クラウドとアプリケーションのセキュリティを統合することで、クラウドからコードまで、コードからクラウドまで、より広範囲を保護する基盤を構築できます。

• ワークフローの統一による開発者の導入促進。開発者は、使い慣れたワークフローから離れることなくセキュリティツールを利用できます。場合によって新しいワークフローを学ぶ必要があっても、その数は限られます。ワークフローを統一すれば、誰にとってもトレーニングや導入が容易になります。

• コンプライアンスの達成。セキュリティベンダーを統合すると、コンプライアンス対応を大幅に迅速化できます。たとえば、複数のベンダーに同じSBOMを依頼するのではなく、1つのツールについてソフトウェア部品表を依頼するだけで済めば、所要時間を大幅に短縮できます。

• 調達の効率化とコスト削減。最終的に、セキュリティの統合はコスト削減につながります。ベンダーが少なければ調達に費やす時間が減り、多くの場合、総コストも削減できます。

Snykの開発者セキュリティプラットフォームで統合

Snykの開発者セキュリティプラットフォームは、クラウド、アプリケーション、ソフトウェアサプライチェーンなど、複数の領域のセキュリティを一元化します。コードからクラウドまで、そしてクラウドからコードまで、脆弱性に対処できる単一のプラットフォームを提供します。開発者は複数のばらばらなツールを確認する代わりに、単一のプラットフォームで、アプリケーションを構成するすべてのコンポーネントを把握できます。

プラットフォームには、次の製品が含まれます。

• コードの記述中に静的コードを保護するSnyk Code。

• クラウドセキュリティのポリシーをコードとして定義し、適用するSnyk Cloud。

• コンテナやワークロードの脆弱性を自動で検出・修正するSnyk Container。

• インフラストラクチャをソースから保護するSnyk IaC。

• オープンソースの依存関係におけるセキュリティ上の問題やライセンスの問題を特定し、軽減するSnyk Open Source。

これらのツールはそれぞれ特定のセキュリティ領域をカバーしながら、同じプラットフォーム上で連携し、開発者、セキュリティチーム、クラウドアーキテクトが利用できる統合セキュリティハブを実現します。各ツールがSDLCの異なる側面をカバーする一方、すべてのツールは共通の情報源を活用しています。それは、公開情報、開発者コミュニティのデータ、独自の専門家調査、機械学習、そして人間が関与するAIで構成される、Snykのセキュリティインテリジェンスデータベースです。

Snykの開発者セキュリティプラットフォームについて、ぜひ詳しくご覧ください。