クラウド型Web脆弱性診断ツール VAddyブログ

- 継続的セキュリティテストへの道 -

トップ > コラム > 翻訳企画：セキュリティテストを開発のパイプラインに追加しよう

翻訳企画：セキュリティテストを開発のパイプラインに追加しよう

コラム 関連技術情報

本記事はGoCDブログに掲載された記事を日本語訳したものです。
“This post was originally published on the GoCD blog.”

この記事は「 It’s not Continuous Delivery if you can’t deploy right now」というシリーズの第二弾です。 今回はセキュリティテストのパイプラインでより一般的なツールをいくつか取り上げようと思います。

私の経験では、自動化されたセキュリティテストがCD（Continuous Delivery）パイプライン上に組み込まれているのをほとんど見たことがありません。

開発者が自信を持って製品をリリースできるようにすることがパイプラインの役割だとするならば、製品のセキュリティについても自信を持てるようなるべきです。全てを取り上げることはできませんが、セキュリティテストの自動化に使われているツールのいくつかを紹介します。

チーム内で書かれたテストをこれらのツールで実行することは、あらゆる開発パイプラインの重要な鍵となるはずです。

自動化はソリューションの一部

セキュリティは全体的な視点で取り組まれなくてはなりません。自動化によって一般的なセキュリティの問題については素早いフィードバックを得ることができますが、優秀なセキュリティテストエンジニアは自動化に向いていないシナリオや方法を考えることができます。

自動化の目的は「low-hanging fruit（容易な問題）」を解決することです。例えば「含んではいけないものまでGitプッシュしていないか？」「古くて脆弱なパッケージを使っていないか？」「会社のルールを破っていないか？ 」といった問題です。

コードをコミットする前に

コードをパイプラインにコミットする前にできること、するべきことはたくさんあります。一般的にCDサーバーはソースコードリポジトリの状態を監視しており、リポジトリの変化に合わせて動作しますが、多くの問題にとってそれは遅すぎるのです。
SSHの鍵や認証トークン、秘密鍵などをコミットしてしまう話はよく耳にします。数年前にはid_rsaの秘密鍵を検索したらGitHubの中だけで600以上ヒットしたという話もありました。

それらが実際にリポジトリに追加される前にチェックするツールの導入を検討しないといけません。 ThoughtWorksは最近Talismanというツールを開発しました。これはGitへのpre-push hookとしてインストールされるので、ソースコードがリポジトリにpushされる前に問題を発見することができます。

静的アプリケーションセキュリティテスト（SAST)

GartnerはSASTを次のように定義しています。
「アプリケーションソースコードやバイトコード、バイナリを分析して、脆弱性となりうる設計やコードを発見するようデザインされた技術の総称。 SASTでは実際には動作していないアプリケーションを隅々まで分析する。」

SASTはユニットテストの範囲を正しく定義するところから始まります。例えば「適切に認証がなされているか？」「不正な認証リクエストを拒否しているか？」「リトライは適切に制限されているか？」「パスワードポリシーは適切に設定されているか？」 などです。


ビルドプロセスのかなり初期の段階で、CDサーバーはセキュリティに特化したソースコードレベルのテストを実行することができます。そしてそれは単純な悪いコードからポリシー違反まで、広い範囲の問題を探すことができます。

Rubyアプリケーション向けには、SASTツールとしてBrakemanとBundler-auditがあります。
Brakemanはアプリケーションのソースコードをスキャンし、様々な種類の警告を出してくれます。 その中でも特に私はポリシーチェックと呼ばれるものを好んでいます。例えばあなたが許可するつもりが無いにも関わらず誰がBasic認証を実装しようとすると、パイプラインステージは失敗（fail）します。
Bundler-auditはまさにその名の通りのツールで、あなたが既知の脆弱性が存在するGemを使っているかどうかチェックします。

Javaアプリケーション用ではSonatypeが印象的です。
Sonatypeが行った一般的なアプリケーションで使われている106のコンポーネントに関する調査によると、平均24個が脆弱性を含んでおり、それらはクリティカルまたはシビアだと評価されています。

動的アプリケーションセキュリティテスト(DAST)

再びGartnerの定義を引用すると、DASTとは「アプリケーションにおける脆弱性の兆候を実行環境において検査する」ツールです。
開発の初期段階ではソースコードに対して実行されるツールは有効ではあるものの、それらのツールは実際のユーザーのようにアプリケーションにはアクセスすることはありません。
BurpやOWASP ZAP, Archni,w3af,Vegaはアプリケーションに実際にアクセスし、SQLiやXSSのような攻撃経路を探します。

編注）VAddyはこのDASTツールに含まれます。

テストは誰が作るべきか？

私はテストは開発者自身が（できればコードを書く前に）作るべきだと考えています。
そうは言っても、平均的なソフトウェア開発者がセキュリティテストが苦手であることに議論の余地は無いでしょう。私たちは開発者がいくつかのバックドアを開けたまま放置することがあることを認識しておく必要があります。

セキュリティ分野は専門家によるテストの作成と実行が好意的に受け入れられる数少ない分野の一つであると信じています。開発チームはセキュリティの専門家を見つけ出し、密に連携するべきです。

CD パイプラインのどこでテストすべきか？

人々がこの質問をするとき、彼らはセキュリティパイプラインやステージがブロックするべきかどうかかどうか、つまりパイプラインが失敗した時に先に進めないようにするべきかどうか決めかねています。 私はブロックすべきだと強く信じていますが、それは同じビルドの中で他のタイプのテストができなくなるというわけではありません。


もし皆さんが利用しているCDサーバーがfan-in/fan-outをサポートしていれば、他のパイプライン（あるいは他の人のパイプライン）とは完全に分離したパイプラインでテストを実行することができます。

下の例では、セキュリティスキャンの進行と同時に受け入れテストを進められるようにしています。そして、それら並行して動いているテストの両方にパスしない限りステージング環境にデプロイできないことが分かります。

image

最後に：「ツールは問題を解決しない」

私はソフトウェア開発ツールのメーカーで15年間働いてきました。その経験から確信を持って言えることは、ツールだけでは問題を解決できないということです。

適切なCDサーバーはあなたの人生をずっとずっと楽にしてくれます。適切なセキュリティツールは問題をより早く見つけてくれます。しかし、どちらも専門性の代わりになるものではありません。

どうやって始めるか？

とにかく始めることです。
まずはどこか一つの分野を取り上げて自動化する。そして次は他の分野を自動化する。
時間はかかりますが、時間の経過とともに自身のアプリケーションのセキュリテイにもっともっと自信を持てるようになるでしょう。

【VAddyチームより】
英語圏ではDevOpsにSecurityを組み込む方法について活発に議論がされておりますが、残念ながら日本ではまだそうした記事は多くありません。
私たちはこうした英語圏の記事を日本語で紹介することで、日本国内でもDevOps + Securityに関する議論を広めたいと考えております。