※ 2020/5/22 一部加筆
SASTとIterativeな開発の相性の悪さ
若干煽り気味なタイトルですが、チーム内で話していてなぜセキュリティ静的コード解析（Static Application Security Testing: SAST）と言ったセキュリティアプローチがDevOpsで回りにくいのかが言語化できた。
そもそも静的コード解析というアプローチによるセキュリティ担保は基本的に「教科書的なウォーターフォール型」において有効で、 理由としては「人月・工数」のみで考えられた「誰でもその作業ができ、セキュリティの知識がなくても良い」みたいな作業者の能力を考慮しないアプローチが基本だからである。 そう言ったアプローチだと「SASTのアラート全部直してくれな！そしたらセキュアだから！」という形に落とし込むことにより、 問題をある程度封じ込めれると。 ただ、これをDevOps、というよりイテレーティブな開発（Scrum, Agile 系統）に落とし込むと、日々の開発のたびに発生するLintといったアラート地獄と向き合うこととなり、 その結果エンジニアがサボったり（ちょっと悪意のある言い方）して回らなくなる。 そもそも最初の導入で大量のエラーが出てげんなりしてやらないと思う。
また、ビジネスを加速させるAgile系統のアプローチで、初期からSASTを導入するといったこともあまり考えにくい。 なんせこれらの手法でいきなりそれなりにヘヴィーな品質管理手法を、未リリースのプロダクトに適用する会社は少ないはずだから。 （5/22 加筆: もちろん品質部門などが適切にあり、全てのプロダクトが適切な品質レベルになるように力学が働くような規模になった会社は別である。） つまり、初期からの導入ができて、セキュリティ担保・品質担保がかなり優先度高く動くウォーターフォール型の所などで導入される。 その対局（とまではいかないかもしれない）Agile系統では根っからの思想が違うため、うまく適用し辛いように思える訳である。
そもそもDevOps, Agile, Scrumなどでは、ウォーターフォールのように一回開発し切ったら終わりではないし、 何度も同じ箇所を別の要件で改修していくということになる。つまりその度に新たなエラーが発生する可能性があるわけで、 日々それらのアラートと戦うのは大変疲弊する。
ではうまくチューニングしていけば良い訳なんだが、 うまく回そうとする場合、その脆弱性が外部から悪用可能かどうかと言ったThreat Moedlingとかの評価が必要になったり、 それなりに高度なセキュリティの知識が必要となってくる。 （もちろんこれは結構オーバースペックなケースが多い） そもそも「そんなリスク評価する前に直せ」と言った話になるかもしれない。
つまり、ある程度確実にアウトで、誰でもわかるアウトを検出する程度であれば有効だが高度になってくるとハンドリングしにくいと考えられる。
なので「eval()は絶対使わせない」といったレベルは非常に有用で、これより発展的なことは知識が必須となる。
筆者自身は書いたことがないがReactであれば名前からみてわかる通り dangerouslysetinnerhtml みたいな dangerous と書かれるくらい問題があるメソッドとかをブラックリストとして扱うとか。
結論、これまでのセキュリティアプローチが今の開発フローとマッチしておらず、とは言えリスクを認識しているため、 リスク低減策として実施され、失敗した話が何度も出てくる。 これはDevOpsが悪い・ウォーターフォールが悪いといった話ではなく、その開発手法において包括的で、毎回安全なフレームワークがAglie開発などにおいては、まだ枯れきっていないという点が問題なだけ。
そして何より銀の弾丸はない。 極論を言えばエンジニアが全員スーパーマンなら開発手法とかどれでも良いという話になる。
別の考えで、診断ベンダーにSASTを使ったホワイトボックステストのアプローチを行ってもらうという方法があるかもしれない。 ただ、正直診断ベンダーで高度な開発できる人がどの程度いるのかと思うと、居ないのではと思う。 そのため、余計にSASTをうまく扱うのは難しすぎるという気持ちになる・・・。（もちろん有用なケースも十分あるし、ベンダーの中にも有能な人はいる） 上記の理由としては、近年の開発において、登場人物が多くなりすぎているというのがある。 関数型のエッセンスを含んだ言語、SPA、Vue, React, Angular, Rxなんちゃら、各言語の特性、インフラであればTerraform、Docker、k8s、クラウド、マイクロサービスの知識。とにかく登場人物が多い。 ベンダーや診断員がそういったアーキテクチャと「コーディング」というアプローチで毎日触れ合っているわけがなく、ホワイトボックステストもどこまで有用に働くのやら・・・。 （もちろん、彼らはプロフェッショナルで、外部診断において比類なき力を発揮してくれる）
話を戻すと、このSASTをホワイトボックステストに役立てるアプローチで、ベンダーを使うのはあまりうまくいかなそうに思える。 そもそもサービスのドメイン知識がないと結局中途半端なレビューになりかねない。
DASTとIterativeな開発の相性の悪さ
中途半端な問題検出力という話であれば、SASTからかなり脱線するが自動のセキュリティ動的スキャン（Dynamic Application Security Test: DAST)も結構DevOpsと相性が良いように見えて、すこぶる悪いと思ってる。
これらのアプローチはSPAとか、アウトプットのフォーマットを全て同一な形式にしていくと、ほとんど有用ではなくなるはず。 例えばJSONでのみフロントとやりとりし、バックのDBとの連携は一律プレースホルダーを利用する形式（例えば安全なORMを必ず使う）と、 SQLIやXSSは基本根絶できる。 なんせアプリ側はJSONを送るだけなので、Scriptが入ろうがブラウザはJSONと判断する。あとはモダンなテンプレートエンジンを使っておけば変書き方をしなければ概ねXSSを根絶できる。気にするのは Templte Injectionなどの特殊例のみとなる。
さらにCSPを織り交ぜて万一に備えると、DASTの検知できるところは、かなり高度なパターンか、ビジネスロジック起因の脆弱性のみになる。 でもDASTで最も苦手とするのはビジネスロジックの脆弱性のため、有用に働かない。機械にコンテキストを理解する能力を求められない。 「このパーミッションのユーザではこのデータは見えてはいけない」を機械がチューニングなしに検知できるわけがない。
また、高度なパターン（ex. Unsafe Deserializeとか、突発CTFが開始されるようなケース)を市販ツールが未チューニングで検出してくれると思えない。 できることはあくまで、「Input と Outputを見て、Grepする」だけ。
逆に言うとそれらを期待しないスキャンと言うのはある程度有効だと考えられる。 つまり「ダイナミックな部分を削ぎ落とした（ある意味でスタティックな）スキャン」である。 例えばサブディレクトリの総当たりみたいなツール（ex. dirb222) は効果があるように思える。 OSINTも結果を評価する能力があれば有効に働く。
ただ今度はそういったスキャンの問題点が今度は出てくる。 例えば「テスト時間がどんどんと伸びて行く」「何を持ってテストをfailとするか」といった部分である。
これらのフォーマットは総当たりベースであるケースが多く、テスト時間がバカにならない。 しかもスキャンする対象をサブドメイン全てにすると、リリースの度に回すといったことができなくなるわけである。 その上、テスト結果（つまりレポート）を見る能力者の腕によりけりとなり、品質にムラが出る。
結局のところDASTのアプローチを効果的にやろうとすると絶対に人の手が介在する必要がある。 （※ただ、ここまでのDASTの話で前提となってるのは、セキュアになっているモダンWebアプリケーション上の話である。依然生PHPなどを使ってる場合、NiktoとかBurp, OWASP ZAPのような自動スキャンっでも十分効果はある）
これらのことからわかるのが、最も費用対効果がよく、DevSecOpsをやる手法としては、以下から手をつけることであることがわかる。
- 現場エンジニアのセキュリティレベルを上げること
- 開発者がコピペコードを書こうが、全て安全な形式で処理されるようにする（ベースラインアプローチ）
もう一度書くが、このDASTの話は「セキュアになっているモダンWebアプリケーションの話が前提」である。 ここで言うモダンWebアプリケーションとは、全てのページレンダリングにエスケープ処理が自動で入ってきたり、リポジトリ層での処理は安全なクエリが発行されるような状態にしているアプリをさしている。
最後に
Twitterに書き殴ったものを軽く清書したのでそのまま投稿する。 書きなぐりをした後の文章なので多少読みズラいかも。
5/22追記
「結局何が言いたいのかわからん」「危ないコードが出荷されるよりマシでは」「専任を立てれば良い」と言ったご意見を頂いたので、
改めて自分で読み直したところ、確かに結論に対しての根拠が雑 ＆ つながってないと思ったのでSASTの部分を補足します。
（DASTはまあわかるかなと思うので加筆しないです）
まず本記事の補足・言いたかったことは以下です。
- SASTをうまく回せてるケースもある（が、安易に入れると失敗する）
- SASTを広いスコープに適用する場合、組織風土やデベロッパーなどに対するネゴシエーションが大量に発生しするため非常に大変
- 初期チューニングはセキュリティの知識がしっかりとないと難しく、それを開発組織全てが持っていることは稀（逆にいうとそれを専任する人がいれば回せる）
- アラートがならないようにアノテーションをつけまくってくなどやり方はあると思うが、それらの初期チューニングで疲弊するケースがある（ここは製品の性質による）
- アラートを消しまくり、かなり綺麗になれば日々の修正アラートを直すだけになり、それほど辛く無くなっていく
- SASTを導入する場合、その導入するスコープに関わるエンジニアの殆どに一定の教育がいる（当たり前ですが）
と、「安易に入れるな、気合を持って頑張る気概があればやれる」ということが言いたかったわけです。
ただ、こう言った手段を取るよりも先に 「ベースラインを上げるためのアプローチを取る（どう書こうが安全になる環境）」「開発者全てのセキュリティ教育（ハードニング・ガイドラインなど）」を整備していくことの方が、 コスパがいいだろうとも思っています。
そしてそれでも漏れ出るエッジケースを、バグバウンティやその他の手法（SASTでそれを検知できるならもちろんSASTも含みます）で、 バグ取りをしていくのが筋が良い気がしています。
どうしてもエッジケースの場合、外部診断をしようと漏れることがあります。 これは診断をしているとわかりますが、特殊なケースなどに関しては診断士の腕という変数を足しても出てこない時は出てきません。
これらのSASTを含めたアプローチに関しては、別の記事でも書いたようにNetflixのDevSecOpsの試みに関する記事で失敗してるっぽそうな雰囲気がわかるかもしれません（あくまで推測ですが）。
あの規模の会社でSASTをうまくワークさせるのはなかなか骨でしょう。
（ただ、いまだにSASTを回している状態ではあると思うので、きっとうまく動いてる部分もあるのでしょう。）
これである程度補足はできましたが、 Agile, Scrum とSASTの相性が悪い にはまだ補足や観点が足らないのでその点を書き足していきます。
障壁となる要素は以下だと思っています。
- 開発側では短いサイクルの中で一定のタスクを消化することを求められるため、差込で発生するSASTのアラート対応に追われる（ここをやりきれなくてDisableや、レポートするだけになるケースがある）
- SASTのアラートを評価・直すというオーナーシップを持つ人間が内部にいない（セキュリティ担当などがいれば回る。が、組織規模に合わせてスケールさせるのが難しい）
このような要素により、開発側は脆弱性を直すためのモチベーションを働かせることが、難しくなる傾向にあると思います。
なんせ脆弱性を直したところで評価がされないわけですし、開発者に矜持がなければ見て見ぬふりをしてしまうかもしれません。
（もちろんSLAなど内部ルールを定めることで、どうにかできます。）
逆に小さい組織でSASTを使い、専任を立ててしまえば最初のチューニング以降は回していくことはある程度容易かもしれません。 ただ、その場合はある程度のセキュリティ知識＆コードをかける人間などが必要になるかもしれません。
余談になりますが、このアプローチは会社の成長とともにスケールさせ辛いと思います。 昔どこかで見た「社内のセキュリティ人材は1%あたりが平均」（※要出典）と言った内容をもとに考えると、 コードがかけてセキュリティに詳しい人間はあまり多くないため、全開発部署に配置するのは難しいかもしれません。
しかし、会社が大きくなればなるほどセキュリティの重要性は上がり、より横断的に防御をしたいと言った考えに大抵は近づいていくはずです。 そうなってくると、全部署にセキュリティ人材を配置し、オーナーシップを持たせて動かしていく必要があります。 そのため、どこかでリソース確保が難しくなるかもしれません。
ただ、これから先はそう言ったセキュリティ人材がどんどんと製品チームに繋がっていけるようなモデルが良いと
つい最近発表されたGoogle SRE本３弾 Building Secure & Reliable Systems の一部に書かれていたりします。
書かれている場所は、序文に当たる Foreword by Royal Hansen という筆者の考えが書かれている章です。
かなり端折って、かなーーーーり意訳しますが、以下のようなことが書かれています。
SREとセキュリティは同じような傾向にある。 彼らは一般的なデベロッパーと違って専門家であり、製品チームに統合されているというよりも、サイロ化されていることが多い。 SREは、チームにコネクトする実装モデルを作成しました。これはセキュリティコミュニティが取るべき次のステップであると思っています。
是非原文を読んでください。すごい本です。
Google - Site Reliability Engineering
話をまとめ丸と、 SASTがダメと言うことではなく、多層防御の考えの通り、複数のアプローチを重ね合わせるのは非常に大切です。 適切な建て付けであったり、ツールの恩恵を受けるのはここまでと決めて使っていけば、ツールに踊らされたりと言ったことはなくなるかもしれません。 ただ、この辺りをうまく話し合っていない＆躓く原因がどこにあるかをわかっていないまま、SASTを導入しているケースをたまに聞きます。 そのため、ちゃんとした話し合いや、何をリスクと考えるのか、より効果的な施策はないかなど、考えた上で導入をすると良いと思います。
と、言語化して書き終わってわかりましたが、論理がとても飛躍していました。反省です。 また「SASTとDevOpsなどの相性が悪い」という根拠にはちょっと弱いように思えてきました。すみません。
この辺りの課題感をGithubが去年くらいに買収した静的コード解析 (CodeQL)が、どう解決していくのか興味津々なので、 Githubには頑張って欲しいです。
終わり
