アプリケーションであれAPIであれ、伝統的なアプリケーションであれモダンなアプリケーションであれAIアプリケーションであれ、プログラマビリティはセキュリティ問題に対処するためのセキュリティ・ツールボックスの重要なツールであります。
アプリケーションやAPIを安全に保つ方法の一つは、顧客やパートナーに公開する前に、脆弱性や正しさをテストすることです。アプリケーションやAPIをテストするための一般的なテクニックは、ファズテストです。
ファズ・テストでは、数値の代わりに予期しない文字列、特殊文字、長すぎる、短すぎるなどの入力を送り、APIやアプリケーションの応答を確認する。堅牢な実装は、これらの入力を無効なものとして拒否することで処理する。しかし、入力処理のテストと同じくらい重要なのは、入力処理を実行するコードのテストです。
言い換えれば、アプリケーションやAPIのロジックが無効な入力を拒否するだけでは不十分で、無効な入力をチェックするロジックも堅牢でなければなりません。
さて、アプリケーション・セキュリティの世界ではよくあることですが、誰かが予期しない、あるいは、考慮されな かった入力を考案するでしょう。私たちは、入力サニタイズの実装のかなりの数が単に悪いものであることを無視し、それらがすべて堅牢で、不正な入力の99%を捕らえることができるかのように装うことにします。
ユートピア的な仮定であっても、誰も考慮しなかった1%は常に存在する。それがゼロデイ脆弱性が生まれる方法のひとつです。
技術スタックの欠陥の結果であることもある。ウェブサーバー、アプリサーバー、GraphQLサーバーかもしれない。データソースへのコネクターにあるかもしれない。例えば、生成AIのユースケースとして人気が高まっている検索拡張世代(RAG)をサポートするために使用されるベクターデータベースのようなものです。あるいは、ProbllamaのようなAI推論の脆弱性の登場かもしれません。より広範なアプリケーション・アーキテクチャの中に新たな階層が加わるということは、結局のところ、新たな脆弱性を意味します。
これらはインターネット上でパニックを引き起こす脆弱性である。Apache Killer(2011年)、HeartBleed(2014年)、SpectreとMeltdown(2018年)、そしてLog4Shell(2021年)です。
これらは予期せぬ脆弱性だった。開発者、SecOps、DevSecOps、QAがこれらを予測することは期待できなかった。本当にできなかったのです。
開発者やセキュリティ専門家の先見の明のなさとは関係なく、ゼロデイ脆弱性が現れたら、何かをしなければなりません。特に、ある組織が問題のテクノロジーを運用しているために脆弱性を抱えている場合はなおさらだ。それこそがリスクを 脅威に押し上げるものであり、脅威は無力化する必要があります。
そこで、アプリケーション・サービスのプログラマビリティがチャットに入ってくります。
アプリケーション・サービスのプログラマビリティは目新しいものではありません。組織はインターネットの初期からプログラマビリティを利用して、さまざまなソリューションを実装してきました。
データ・パスにおけるプログラマビリティの最も一般的な用途は以下の通りであります:
私たちは、社内データから、これらが一般的であることを知っています。私たちの顧客の70%以上が、多種多様なソリューションのために日々プログラマビリティを利用しています。その中には、セキュリティに重点を置いているお客様もいらっしゃいます。
そのため、我々が市場全般を調査したところ、APIセキュリティにとって重要な技術的能力のトップにプログラマビリティが挙げられていたことは驚きではなかった。
プログラマビリティをサポートするAPIセキュリティ・ソリューションの汎用性は事実上無限であります。F5がこの機能のパイオニアであることは確かだが、これはアプリケーション・サービス全般にとって市場の定番となっています。アプリケーション・サービス、特にアプリケーションとAPIのセキュリティに特化したサービスで、コア機能の一部としてプログラマビリティを提供していないものはほとんどない。
それは、プログラマビリティがゼロデイ脅威を軽減し、組織がシステムのかなりの割合に影響を与えるパッチプランをより計画的に設計するための基礎となるからです。
プログラマビリティは、まあ、何でもできる。しかし、セキュリティ、特にAPIのセキュリティの領域では、それは単に 「あったらいいな 」ではありません。なくてはならないものなのです。
APIに関するより詳細な洞察については、当社の「アプリケーション戦略の現状」レポートをご覧ください: APIセキュリティ」