セキュリティテストと開発速度の対立の実態
となると、これまでと同様にセキュリティリスクを継続的にチェックし、その結果を正しく認識・改善につなげていくことが重要になってくる。しかし、これは言うほど容易なことではない。バグなどのソフトウェアの品質だけならまだしも、業界や国ごとに適合しなければならない法律や基準もたくさんある。特に日本ではソフトウェア品質に大きなこだわりがある。
そうしたなかで、セキュリティテストと開発速度の対立が起こってしまうことは必至であろう。実際に調査結果からは、86%の回答者が何らかの開発速度低下を認識していることが分かる。また、12%の回答者は「十分な情報がない」と回答しており、そもそも開発サイクル全体を把握できていない可能性も示唆された。
こうした遅延の原因の一つとして、ツールと誤検知(ノイズ)の問題が挙げられる。調査によると、6~20種類のセキュリティテストツールを利用している組織が大半を占めている。また、6割がノイズがあると回答した。
「こうなると、トリアージをするときの判断が難しくなってくる。仮にバグあるいは不具合が1000件見つかったときに、そのうち600件がノイズ、つまり誤検知だったり結果が重複していたりする。複数のツールのテストの結果が異なっていれば、さらに判断は難しくなる」
またこうした課題に対して自動化で対応しようにも、そもそも導入自体が進んでいない状況も明らかになった。
「もしこの数字から自動化を適用できないプロジェクトが多いということであれば、我々のようなベンダーが提唱している世界観と現場にはまだまだ大きなギャップがあるのだろうと思います」(松岡氏)
ここまでの説明を踏まえ、松岡氏は改善に向けた3つのポイントを紹介してくれた。
1つはAIガバナンスの確立。AIツールの使用はもはや避けられない中で、ポリシーの定義や生成されたコードの問題点を素早く指摘できる体制を作ること。またトレーニングモデルを自前で整備している場合はそれ自体のセキュリティも担保する必要がある。
2つ目は自動化の実践。IaCによる自動化の実装や、開発段階で自動化を支援する仕組みづくりが手法として示された。「自動化で開発効率と速度を上げるには、マニュアル作業との組み合わせの中で、より良い仕組みを作っていかないといけない」(松岡氏)
最後はやはりツール・スタックの合理化。複数のツールで評価することのメリットも確かにある。しかし、調査結果からデメリットがあることもまた事実だ。ツールのメリット・デメリットを比較し、集約したり合理化をしていくことが求められる。また、ASPMを検討することも選択肢として入れておきたい。
「これらの改善を複合的に実施することで、今回のレポートで明らかになった課題に対して、スピードを下げることなく、安全に開発できる環境は構築できるんじゃないかなと思います」と期待を語り、解説を終えた。