プロダクト開発が高速化するなか、脆弱性対策は追いついているか？
DevOpsやアジャイル開発という言葉が浸透し、実践も進んできた。現在、開発の高速化はどのくらい進んでいるだろうか。Google「State of DevOps 2021」によると、SDO（Software delivery and operational）パフォーマンス評価で「高」以上に該当する企業は全体の66％を占める。これらの企業はデプロイの頻度が少なくとも月に1度、変更のリードタイム（コードをコミットしてから本番で正常に稼働するまでの時間）が1週間以下、インシデントや不具合発生からサービス復旧までの時間が1日未満とされる。
プロダクト開発をアジャイルやDevOpsという手法を通じて高速化するなか、新しい脆弱性にも対応していく必要がある。記憶に新しいところだと、Log4jやArgoCDの脆弱性が話題になった。慌てて対応したシステム担当者も多いことだろう。脆弱性は対応せずに放置していると、攻撃されてしまいかねない。ここ1年で見ても、脆弱性を攻撃されたことから情報漏えいに繋がったインシデントが後を絶たない。
スリーシェイク 手塚氏は対策として、何らかのセキュリティ対策を導入することや脆弱性診断を挙げた。0day攻撃に対しては、パッチを当てるまでの短い期間はWAFなどでパッチの提供まで時間を稼ぎ、パッチ提供後は速やかに検証を行ってパッチの適用を行う必要がある。
XSSやLog4jのようなpayloadを難読化しやすいものに関しては、多くのWAFでbypassができ、またWAF自体を迂回できるケースもあるため、脆弱性の対策としてWAFを利用することは非常に危険と考えている。
WAFは攻撃者の診断や調査の難易度を上げるため、緊急時の一時的な対策としてのみ利用するべきである。そのため手塚氏は「サイト自体の弱点（脆弱性）をなくし、堅牢なものにすることが重要」と述べる。
後者の脆弱性診断も欠かせない。かつてのウォーターフォール型開発ならリリース直前程度にしかやらなかったかもしれないが、昨今では大きな機能アップデートリリース時に、あるいは一定期間おきの実施が多いのではないだろうか。冒頭で述べたように、今では半数以上の企業が高頻度でリリースしている。もしかしたら脆弱性診断から次の脆弱性診断までの間に細かなリリースもあるのではないだろうか。そうなると脆弱性診断をしてから次の脆弱性診断をするまでの間に隙ができてしまう。高頻度で脆弱性診断をしたくても人員が限られてしまってできないか、費用が高額で諦めているケースもあるだろう。
開発を高速化するなら、脆弱性対策も追随して高速化していく必要がある。手塚氏は解決策として「継続的セキュリティ対策」というアプローチを提案する。発想としてはDevSecOpsに近い。開発プロセスには企画、設計、実装、テスト、リリースがあり、このライフサイクルを高速に回していくものになる。
脆弱性が混入してしまいがちなタイミングは企画・設計、および実装だ。脆弱性の発見や修正は、後のプロセスでいくつかの方法がある。設計段階ならセキュアコーディング、実装段階ならSAST（静的アプリケーション セキュリティ テスト：Static Application Security Testing）、テスト段階ならDAST（動的アプリケーション セキュリティ テスト：Dynamic Application Security Testing）やIAST（インタラクティブ アプリケーション セキュリティ テスト：Interactive Application Security Testing）など、リリース前なら脆弱性診断がある。
また利用しているOSSに既知の脆弱性がないか管理するにはSCA（Software Composition Analysis）もある。コンテナを用いているならコンテナイメージの脆弱性スキャン（Trivyなど）、いずれかのクラウドサービスを用いているなら設定をアセスメントするためのCSPM（クラウドセキュリティの状態管理：Cloud Security Posture Management）も有効になるだろう。
こうした各種ツールはCI/CDに組み込むことで、開発と同時に脆弱性の発見と改修を継続的に実行していくことが可能となる。高速開発にセキュリティ対策を追随させることになり、DevSecOpsの実現でもある。
