こんにちは。
株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。
ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。
このプロジェクトで過去に検証した「継続的アプリケーションセキュリティ」について共有しようかと思います。
課題の経緯、前提条件
課題の経緯
脆弱性を含めた不具合の発生タイミングについては、発生するタイミングが開発工程の後であればあるほど、開発全体への影響が大きいです。しかしながら特別な対策を行わなければ開発工程の後半ほど不具合が見つかることが多いというのが現実ではないでしょうか。
それはプログラムが動く状態になってからの方がテストしやすいということが最大の理由かと思いますが、テストのタイミングを開発工程のなるべく早い段階、すなわち不具合発生の原因が生まれるタイミングに移す（＝シフトレフト、開発工程を左から右に流れるとイメージして前工程である左側に移すこと）方法が考えられ生み出されています。
（出典：IPA『セキュリティ・バイ・デザイン 導⼊指南書』 p.36）
ラクスでもそれほど多いわけではありませんが、リリース前に不具合が見つかることがあり課題感がありました。 本調査ではテストのシフトレフトについて、有効そうな手法の探索と導入可否の検討を行いました。
なお、上で図を引用したIPAから発行されている『セキュリティ・バイ・デザイン 導⼊指南書』は、このあたりの考え方がまとまっている資料なのでぜひ参考にしてみてください。
期待する導入成果
期待する導入効果としては、開発プロセス全体で不具合対応にかかっているコストを現状よりも小さくすることです。そのために従来開発工程の後半で見つかっていた不具合を少しでも早い段階で検知できる仕組みを期待しています。
ただし、導入することで今までよりも手間がかかるようでは本末転倒1なので、導入後にセキュリティのシフトレフトによるコスト増（ツール費用など）を含めて現状よりも小さくなることが大前提となります。
※なお実際の不具合対応コストはこんなに割合多くないです🙂
シフトレフトや、脆弱性診断ツールに関する概念
- CAS: Continuous Application Security
- 継続的アプリケーションセキュリティ
- CIに組み込むなどして日常的に意識することなくセキュリティ向上策を実施するプラクティス
- SAST: Static Application Security Testing
- IAST: Interactive Application Security Testing
- E2Eテスト中に適用
- 操作と並行して検査する
- 製品としてはSeeker, Contrast Securityなど
- DAST: Dynamic Application Security Testing
- リリース前に適用
- DASTはすでにラクスでも導入していたため今回の調査からは除外
- SCA: Software Composition Analysis
- 利用しているライブラリの既知の脆弱性を検出できる
- SASTツールの機能として組み込まれている場合がある
- RASP: Runtime Application Self-Protection
- アプリケーション実行中に異常を検知する仕組み
- 本稿では直接扱わないが参考として
前提条件
現在のラクスでは実装工程として単体テスト、その後結合テスト工程に脆弱性診断ツールを用いてのテスト（DAST）を行なっています。
DASTツールの見直しについては別途定期的に取り組んでいるため、シフトレフトするとなると検討すべきはSAST, IASTツールになります。今回はSAST, IASTツールの調査とラクスで導入しやすそうなツールの検討を行なっていきます。
また、調査当時はソースコード管理にGitLab CEを利用しており、クラウド版GitHub Enterpriseへの移行を検討していたこともあり、GitLab, GitHubに依存したGitLab SAST, GitHub Code Scannerについては調査対象外にしていました。
実現手法
SASTとIASTの特徴
共通の特徴
- ホワイトボックステスト
- 対応できるのはメジャー言語に限られる
- しかし長期的にメンテナンスする想定のサービスで採用されるような言語は対応しているので実用上は問題なさそう
- コード外由来の脆弱性には対応できない
- ソースコードを対象に捜査するため仕方がない
SAST
- 誤検知が多くなりがち
- フルスキャン可能でカバレッジを100％にしやすい
IAST
SAST/IASTを導入したらDASTが不要になるか
結論から言えば、SAST/IASTを導入してもDASTは不要にならなず、現状DASTツールにかけているコストはなくなりません。 なぜならば、DASTで出来ずSAST/IASTで対応可能な観点のテストがある一方で、SAST/IASTで出来ずDASTでしか出来ない観点のテストもあるためです。
例えばSAST/IASTではソースコードをフルスキャンしてのテストが可能だが、DASTで行うような外部ライブラリや複数のモジュールを結合してのテストは行うことが出来ません。
既存のDASTで無理してカバーしているような部分がある場合（例えば細かな条件違いの正常系経路の網羅など）は該当箇所をSASTおよびIASTに適切に移行することで、トータルのメンテナンスコストは削減できる可能性はあると思います。
どこまでコストをかけられるか
今回の調査を始めるにあたって少し甘かった部分ですが、調査中盤で改めて社内で開発工程後半で不具合が発覚することによる手戻りの工数がどの程度か確認したところ、想定以上に開発品質が良く手戻りが多いサービスでも「2, 3人日程度」ということがわかりました。この時点で高額なツールの導入は割に合いません。むしろ「まだ導入する必要がない」という選択が現実的だと判断できるボリュームです。
セキュリティ関連のツールは総じて高額な事が多く、今回調査したツール類も有償ツールはすべて導入のコストメリットは見いだせませんでした。一方でCommunity Editionなどの無償でのツール提供が行われているものだと機能面で弱く、これも導入メリットが小さいと判断されました。
ツール所感 → 今後に向けて
さて、有償無償問わずツール導入のメリットが薄くなってしまいましたが、こういった状況だとSAST/IASTツールの導入はかなり難しいです。
SAST/IASTツールの製品傾向
- 無償ツールとして利用できるものは機能制限が多い
- 自前運用しようとするとCI環境のマシンリソースを確保する問題が発生する
- 常時稼働するわけではないが、少ないと待ち時間が開発速度の悪化に直結する
- 自前運用しようとするとCI環境のマシンリソースを確保する問題が発生する
- 多くのツールはクラウドサービスとして展開されている
- テスト環境での操作情報を外部に送信しなければならない
- セキュリティが厳しい会社だとこの部分で導入は厳しそう2
- テスト環境での操作情報を外部に送信しなければならない
- 予算が潤沢であれば、機能面でContrast Securityが良さそうに見えました
SCMサービスに付随するサービス GitHub Code Scanner
調査当時もCode Scanningは存在していましたが、当時弊社のソースコード管理はGitLab CEを利用していたため候補から外していました。またGitLab SASTもGitHub移行の検討が始まっていた頃だったため、除外していました。
現在はほぼすべてのソースコードをクラウド版GitHub Enterpriseに移しているのでCode Scanningも候補に入ってきます。 課題として挙げたCI環境のリソースもCode Scanningであれば、（多少のお金の力があれば）なんとかなります。
と思ったら……Code Scannerの利用はプライベートリポジトリ対象だと、GitHub Advanced Securityライセンスが必要で、アクティブコミッター1人あたり月額$49が追加で必要になるので弊社のようにそれなりの規模のチームで開発している場合に導入するのはハードルが高かった……3。
調査の中で分かった導入に向けたハードル
- 既存ソースコードで検出される項目の扱い
- 導入時が一番多く検出される
- 検出されたから修正、とすると「今」必要ではない修正が多発する
- 導入直後に検出された不具合の扱いは事前に定めておかないと混乱のもと
- 導入時が一番多く検出される
- 現状の品質に対して期待できるメリットのコスト対比がまだ低い
最後に
セキュリティのシフトレフト自体は開発プロセスにおける理想であることに違いはないと考えています。
ただし商用サービスを提供する立場としては実現するためにはもう少し普及してコモディティ化（に伴う低価格化）してくれないと導入は正直厳しいというのが現時点での判断です。
一方でライブラリなどをオープンソースで公開する場合など、不具合の影響が広範囲に波及するようなプロダクトに関していえば、GitHubのパブリックリポジトリでのCode Scanningが無料で利用できるため積極的に使っていくべきだと感じました。
