AppSecツールが特効薬だというのなら、なぜ多くの企業がそれを使おうとしないのでしょうか？

本記事の一部は SC Magazine に掲載されたものです。内容を更新し、転載しています。

‍

今日のセキュリティ専門家が直面する多くの難題の一つに、直面するサイバーリスクに対処するためのソリューションのバランスをどう取るかという問題があります。予算をツールと人材にどう配分すべきか？既存の技術スタックに最適なツールスイートは何か？選択肢が多すぎるため、簡単な答えはなく、選択を誤れば後で時間とコストを浪費することになります。

最近のレポートによると、アプリケーションセキュリティツール市場は現在から2025年にかけて「爆発的」な成長を遂げると予測されています。これは、DevSecOpsの実践においてツールが不可欠な役割を果たしていること、そしてセキュリティ脆弱性を抱えるコードの増大に伴い、業界内での重要性が高まっていることを強く示しています。

しかし、奇妙な問題があります。組織の半数近くが、脆弱性のあるコードを認識しながらリリースしています。それも、まさにそれを防ぐために設計された一連のAppSecツールを使用しているにもかかわらずです。市場で確実な需要があり、急速に普及している製品において、これは理解しがたいことです。なぜ多くの企業が高度なセキュリティツールを購入しながら、その結果を無視したり、全く使用しなかったりするのでしょうか？これは、ビーチフロントの家を買っておきながら、森の中でテントを張って寝るようなものです。

AppSecツールが期待通りに活用されていないのにはいくつかの理由があります。それはツールやその機能の問題というよりも、セキュリティプログラム全体にツールがどのように統合されているかという点に起因しています。

ツールの数が増えても、問題が減るわけではありません。

企業がソフトウェア開発プロセスを進化させ、アジャイルからDevOpsへ、そしてDevSecOpsという聖なる理想郷（今のところ、これが最善の策です）へと移行する過程で、複数のスキャナー、モニター、ファイアウォール、その他あらゆる種類のAppSecツールが導入されるのは避けられません。一見「多ければ多いほど良い」ように思えるかもしれませんが、多くの場合、これはフランケンシュタインの怪物のような技術スタックを生み出し、予測不可能な事態を招くことになります。

必要な作業範囲に対して予算や専門リソースがますます限られる中、混乱を収拾し、最適なツール導入の道筋を見つけるのは困難な作業です。スキャンや修正が必要なコードは次々と押し寄せてきます。多くの組織がコードのリリースを止められないのも無理はありませんが、これは非常に憂慮すべき事態であり、データやプライバシーにとって依然として甚大なリスクとなっています。

スキャンツールは動作が遅く、リリースの俊敏性に影響を与えます。

ソフトウェア開発において、セキュリティとスピードを両立させることは「白い鯨（追い求めても手に入らないもの）」のような存在です。DevSecOpsアプローチの導入を推進している現在でも、私たちはその実現に苦心しています。90年代には、綿密な手動コードレビューがセキュリティの安全装置として機能していたかもしれませんが、数千億行ものコードを生成する現代において、それは爪切りでサッカー場の芝を整えるような、極めて非効率な計画です。

スキャンツールは、潜在的な問題を特定するプロセスを自動化し、綿密なコードレビューを代行してくれます。しかし問題は、CI/CDパイプラインがフル稼働している状況下では依然として動作が遅く、また、すべての脆弱性を発見できるツールは存在しないということです。さらに、スキャン後にセキュリティチームに突きつけられる結果には、いくつかの明白な問題があります。

1. 非常に多くの誤検知（および見逃し）が発生します。
2. セキュリティ専門家が、本物のバグと偽のバグを選別するために手動レビューに時間を割かなければなりません。
3. コードがデプロイされる前に検知されるべき一般的な脆弱性が、あまりにも多く放置されていることがよくあります。高価なセキュリティ専門家を、些細な問題に追わせて、重大なセキュリティ課題から目を逸らさせるべきでしょうか？
4. スキャナーは「発見」するだけで、「修正」はしません。

サイバーセキュリティのベストプラクティスに従い、プロセスのあらゆる段階にセキュリティを組み込もうと最善を尽くしている組織であっても、スキャナーが主要な保護手段であり、あまりにも多くの一般的なバグが安全なコードのデプロイを阻んでいるのであれば、上記の問題は致命的です。そのため、どこかで妥協が生じるのは当然であり、それは通常、一連のソリューションを購入していても、すべての潜在的リスクをカバーしきれない最小限のツールに頼るという形で現れます。

一部の技術主導型自動化は、コード品質の低下を招く可能性があります

スキャンやテストはAppSecツールにおける自動化プロセスの負荷を担っており、ファイアウォールや監視といった必須機能と並んで重要ですが、他の一般的なツールは、意図せずして長年培われてきた実践的なセキュリティの基盤を徐々に損なう可能性があります。

例えば、RASP（ランタイムアプリケーション自己保護）技術は、コーディング速度を犠牲にすることなくセキュリティ体制を強化するために適用されることがよくあります。これはアプリケーションの実行環境で動作し、悪意のあるコード入力やリアルタイム攻撃から保護し、異常な実行動作を検知します。

確かに保護層は追加されますが、これをコードベースの潜在的な弱点に対する安全装置だと考えると、開発者は油断しがちになります。特に、新機能のリリースに向けて、実現不可能な市場投入期限に直面している場合はなおさらです。ランタイムでの自己保護がミスを検知してくれるという前提で、セキュアコーディングの実践がおろそかになる可能性があります。開発者がわざと脆弱なコードを書こうとするわけではありませんが、自動化された保護機能があるという前提のもとでは、機能提供が優先され、セキュリティが後回しにされることがよくあります。

ツールは故障する可能性があります（RASPの場合、誤検知を避けるために監視モードで運用されることが多く、その結果、攻撃に対する保護ではなく可視化しか提供されません）。そのような事態において、常に信頼できるのは高品質でセキュアなコードです。コードに携わるあらゆる役割においてセキュリティ意識を持つことはDevSecOpsの基本であり、開発者がセキュアなコードの作成や学習を行わないことは誤りです。セキュアなコードもそうでないコードも、記述にかかる労力は同じです。真のエネルギーを要するのは、セキュアにコーディングするための知識を習得することです。RASPの実装や最適化に費やす時間は、開発者が最初からミスを犯さないようにスキルアップさせることに充てる方がはるかに有益です。

ツールと人のバランス：特効薬ではありませんが、（現時点では）それに最も近い解決策です。

DevSecOpsの主要な理念は、セキュリティを共通の責任とすることです。電力網からドアベルに至るまで、私たちの生活を支えるソフトウェアを開発する組織は、より高いレベルの安全性を確保するために、全員をこの取り組みに巻き込む必要があります。

ツールだけで全てを解決することはできず、それが最も安上がりな方法でもありません。コードに携わる全員に適切なセキュリティトレーニングを優先的に提供し、開発チームが常にセキュリティを意識できるよう積極的に働きかけ、ツールを補助的な役割として活用しながら、人間主導のポジティブなセキュリティ文化を構築することこそが、最も優れた結果をもたらします。

時間的制約や妥協など、セキュリティ専門家を悩ませる要因がある中でも、開発者が最初から一般的なセキュリティ欠陥を作り込まなければ、それらのツール（の使用有無にかかわらず）がリスク要因となる可能性は大幅に低減します。

‍