成果が見えづらいソフトウェアの安全性向上、しかしそうは言っていられない現状も
概して、ソフトウェアの安全性向上というと、起こるか分からないリスクを未然に防ぐ、あるいは被害を最小限にするためのものだ。かけた工数やコストが成果や売上に直結するものではないので、なかなか積極的に進めにくい。
一方で、ソフトウェアやアプリケーションの社会に対する影響力は年々大きくなっており、些細な不備から致命的な被害につながることもありうる。特に医療や自動車など人命に関わる領域では、ソフトウェアの安全性検証は欠かせない。ベストプラクティスやルール作りも進んでいる。ここは危機管理に対する奥深い理解や視野の広さが必要となるところだ。
そうした中で、自社製品・サービスのセキュリティレベルを向上させるために、開発組織内で開発者とセキュリティ担当者が連携してDevSecOpsやシフトレフトのための施策を進めていたり、サービス監視や保守をしていたりする現場もある。中には、PSIRT（Product Security Incident Response Team）のような専門組織を設けるなど組織規模で対策を進めているところもあるかもしれない。
海外に目を向ければ、アメリカでは2021年5月にサイバーセキュリティを高めるための大統領令が発せられた。これに対応するのが「NIST IR 8397」で、ソフトウェア検証における最小限の推奨基準が発行された。いつか日本でも、この基準にならっていくことになるかもしれない。ひいてはソフトウェアの調達や購買において影響してくる可能性も考えられる。
なおNIST IR 8397では「Verification of Code（コードの検証）」と表現されているが、これは主に「Application Security Testing（AST）」のことである。記載されている推奨事項としては、設計レベルの課題を発見すること、ハードコードされた認証情報や開発言語に依存する弱点を検知すること、実施すべきテストなどがまとめられている。
これまではソフトウェアで問題が起きなければ、テストの実施状況が問われることはあまりなかったかもしれない。しかし推奨とはいえ、こうしたテスト要件がNISTで定められると、今後はどのようなテストを実施したか情報開示が迫られることもありそうだ。
ただしテストは「すべきこと」ではあるものの、やればやるだけ利益を生み出すものではない。むしろ逆だ。だから効率的にこなしていく必要がある。そこでキーワードとなるのが、「ASPM：Application Security Posture Management（アプリケーションセキュリティ態勢管理）」だ。
