本記事はDevOps.comに掲載された記事を許可を得て日本語訳したものです。
“This post was originally published on the DevOps.com.”

DevOpsを採用する組織はもっとセキュリティに注意を払うべきであると、Threat Inteligenceの創設者Ty Millerは提案しています。

「ここ5年ぐらいのAnonymousやLulzSecのようなハッカー集団の活動をきっかけに、ITセキュリティに対する主要なアプローチは変化してきており、アプリケーションのライフサイクルへの統合が強くなってきました。」Ty Miller氏

開発の初期段階でセキュリティに注意が払われなければ、リリースまでに設計や開発の手戻りがおこる可能性が高くなります。それは最初からセキュリティが考慮された場合に比べて100倍ものコストがかかることもあります。

そもそもDevOpsとはコードを頻繁にリリースするために採用されるものなので、開発の開始から終了までの全てのプロセスにセキュリティが組み込まれることが重要です。アプリケーションの完成からリリースまでの短い間に、大掛かりなセキュリティテストをする時間はありません。

「開発者がセキュリティエキスパートであることは少なく、また社内のセキュリティ担当者はアプリケーションセキュリティのスペシャリストでは無いことが普通です。このことがセキュリティギャップを生む一つの要因です。」Ty Miller氏

Ty Miller氏は次のことを提案しています。

ライブラリを利用する:
毎回車輪の再発明をせずに既存の有名で質の高いライブラリを再利用すれば、ソフトウェアに新たな脆弱性を作りこんでしまうリスクを減らせます。

プラットフォームのセキュリティ:
「ITチームは社内のシステム（on-premises system）から防御システムやその他のセキュリティコンポーネントを外そうなんてことは思わないでしょう。しかし、クラウド上での開発では、そうしたセキュリティ対策は無視されがちなのです。それはセキュリティ対策は拡張性に乏しいと考えられているからです。柔軟性のためにセキュリティが犠牲になる傾向があります。また、組織はしばしば、SaaS製品が大規模なデータ漏洩を起こし得るにもかかわらず、セキュアだと仮定しています。最近の調査によると、約90%のSaaS製品はエンタープライズにとって十分なセキュリティを提供していません」Ty Miller氏

自動化されたビルド:
あらかじめセキュリティ対策が施されたテンプレートを元に自動ビルドするシステムは、うっかり何かを見落としてしまうことや人的ミスの発生リスクを減らす手助けとなります。 新サーバーがセキュアな設定で起動すると信頼できれば、開発チームは自身の書くコードに集中できます。

自動化されたセキュリティテスト:
頻繁なリリースと伝統的なセキュリティテスト（大きなリリースの直前にセキュリティテストの専門家が実施するテスト）とは相容れません。Ty Miller氏に言わせると「それは邪魔以外の何物でもありません」。
ではいつセキュリティテストをするのか。前回のテストの後に変更された箇所を全て正確に把握し、適切にテストすることができますか？
「自動化されたセキュリティテストはDevOpsプロセスに組み込まれるべきです」とTy Miller氏はアドバイスしています。

「Fortify,AppScan,そしてBurp Suiteは非常に評判の高いツールです」とTy Miller氏。彼はそれらのツールについて次のように述べています。

「コードレビューツールであるHPのFortify は非常に高価（年間$120,000にもなることも）ですが、とても良いツールです。他のツールと同様に誤検知(問題が無い箇所に対して問題と警告を出す)することもありますが。」

「IBMのAppScanはwebアプリケーションやモバイルアプリケーション開発に役立ちます。年間のコストは約$30,000。非常に優れた機能と便利なGUIを持っていますが、ワークフローに乗せるには多くの設定とメンテナンスが必要です。」

「PortSwiggerのBurp SuiteはWebアプリケーション向けの半自動検査ツールです。一人あたり$300と比較的安く、実質的に世界中の多くのセキュリティテスターが使っています。有名な商用ツールほど賢くないかもしれませんが、非常に正確なスキャナーです。」

「しかしながら、自動化されたテストは万能薬ではありません。自動化されたスキャンは約20%の脆弱性しか見つけられないかもしれないけれど、それは人間が見つけられるものより20%少ないだけです。そしてツールによる検査結果には誤検知を多くを含む傾向があるので、検査結果を解析するためのエキスパートが必要です。経験のないユーザーだと、多くの時間を無駄にすることがあります。」とMiller氏は警告しています。

たとえば、アクセスコントロールの不備を自動的に見つけることは困難です。
URLの中の数字を変えてみると、その顧客用のレポートの別ページが表示されるのか、別の顧客のレポートが表示されてしまうのか。
ある特定のレポートが公開された状態なのか非公開なのか。
セキュリティテスターはアプリケーションを理解しているので、それがセキュリティの問題なのかどうかを簡単に見分けることができます。しかし、自動ツールが管理できるのは、それが問題かもしれないと警告をだすことがせいぜいです。

開発段階から製品段階までのプロセス全体をカバーする方法を定義できている組織は、セキュリティをコードやインフラの中の基本的な機能として実装します。そして自動化されたセキュリティツールを使い、定期的な侵入検査とレビューを統合します。そしてそうした組織は「他の組織より明らかに先を進むことになります」とTy Miller氏は述べています。

【VAddyチームより】
Ty Miller氏が指摘する通り、自動化されたセキュリティテストは完璧では無く、我々のVAddyも例外ではありません。しかしながら、新機能や修正版が頻繁にリリースされるようなビジネス環境においては、VAddyのような自動化されたセキュリティテストツールを導入して、製品のセキュリティレベルを底上げすることは十分に意味があると考えています。

この記事にある通り、セキュリティ対策を自動化し開発サイクルに統合することは重要ですが、既存のツールを使いこなし自動化するには、やはり専門知識やノウハウが必要になります。Webアプリケーションのセキュリティテストで一番重要なことは、アプリケーションの動作を把握してツールがうまくそれを再現しながら検査することです。そうしないと、例えばCSRFトークンの期限切れで正常な画面遷移では無い状態で検査していることになり、無意味な検査となってしまいます。

VAddyはCI連携が可能で、専門知識やノウハウを必要とせず簡単に開発プロセスにセキュリティテストが組み込めます。これを実現するために我々は機械学習の機能を使ってユーザのWebアプリケーションの動きを把握できるようにしており、この点がVAddyのユニークで強みとなる点です。

検査するための設定項目を無くし簡単に導入できれば、開発者がビジネスロジックの開発に注力できるため、我々は常にそれを意識してサービスを運営しています。