RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

セキュリティのシフトレフト ―SAST/IASTツール活用に向けた検証―

こんにちは。
株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木(@moomooya)です。

ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。

このプロジェクトで過去に検証した「継続的アプリケーションセキュリティ」について共有しようかと思います。

課題の経緯、前提条件

課題の経緯

脆弱性を含めた不具合の発生タイミングについては、発生するタイミングが開発工程の後であればあるほど、開発全体への影響が大きいです。しかしながら特別な対策を行わなければ開発工程の後半ほど不具合が見つかることが多いというのが現実ではないでしょうか。

それはプログラムが動く状態になってからの方がテストしやすいということが最大の理由かと思いますが、テストのタイミングを開発工程のなるべく早い段階、すなわち不具合発生の原因が生まれるタイミングに移す(=シフトレフト、開発工程を左から右に流れるとイメージして前工程である左側に移すこと)方法が考えられ生み出されています。

(出典:IPAセキュリティ・バイ・デザイン 導⼊指南書』 p.36)

ラクスでもそれほど多いわけではありませんが、リリース前に不具合が見つかることがあり課題感がありました。 本調査ではテストのシフトレフトについて、有効そうな手法の探索と導入可否の検討を行いました。

なお、上で図を引用したIPAから発行されている『セキュリティ・バイ・デザイン 導⼊指南書』は、このあたりの考え方がまとまっている資料なのでぜひ参考にしてみてください。

www.ipa.go.jp

期待する導入成果

期待する導入効果としては、開発プロセス全体で不具合対応にかかっているコストを現状よりも小さくすることです。そのために従来開発工程の後半で見つかっていた不具合を少しでも早い段階で検知できる仕組みを期待しています。

ただし、導入することで今までよりも手間がかかるようでは本末転倒1なので、導入後にセキュリティのシフトレフトによるコスト増(ツール費用など)を含めて現状よりも小さくなることが大前提となります。

※なお実際の不具合対応コストはこんなに割合多くないです🙂

シフトレフトや、脆弱性診断ツールに関する概念

  • CAS: Continuous Application Security
    • 継続的アプリケーションセキュリティ
    • CIに組み込むなどして日常的に意識することなくセキュリティ向上策を実施するプラクティス
  • SAST: Static Application Security Testing
    • 実装中に適用
      • 設計にも適用できるという話もあるが現実的には実装中での適用になると思われる
    • コード診断を行い、Linterのように動作する
    • 製品としてはSonarQubeがあったり、GitHubやGitLabにも組み込まれている
  • IAST: Interactive Application Security Testing
  • 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

  • 誤検知は少ない
  • 機能操作に伴ってカバレッジが高まるため、カバレッジを高めるのは大変
    • カバレッジ100%を目指すためには、すべての処理分岐を網羅するようなアプリケーション操作が必要

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環境のマシンリソースを確保する問題が発生する
      • 常時稼働するわけではないが、少ないと待ち時間が開発速度の悪化に直結する
  • 多くのツールはクラウドサービスとして展開されている
    • テスト環境での操作情報を外部に送信しなければならない
      • セキュリティが厳しい会社だとこの部分で導入は厳しそう2
  • 予算が潤沢であれば、機能面でContrast Securityが良さそうに見えました

www.contrastsecurity.com

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

docs.github.com

調査の中で分かった導入に向けたハードル

  • 既存ソースコードで検出される項目の扱い
    • 導入時が一番多く検出される
      • 検出されたから修正、とすると「今」必要ではない修正が多発する
      • 導入直後に検出された不具合の扱いは事前に定めておかないと混乱のもと
  • 現状の品質に対して期待できるメリットのコスト対比がまだ低い

最後に

セキュリティのシフトレフト自体は開発プロセスにおける理想であることに違いはないと考えています。

ただし商用サービスを提供する立場としては実現するためにはもう少し普及してコモディティ化(に伴う低価格化)してくれないと導入は正直厳しいというのが現時点での判断です。

一方でライブラリなどをオープンソースで公開する場合など、不具合の影響が広範囲に波及するようなプロダクトに関していえば、GitHubのパブリックリポジトリでのCode Scanningが無料で利用できるため積極的に使っていくべきだと感じました。


  1. いわゆるオーバーエンジニアリングになってコスト増を招いてしまうことは、ビジネスとしてサービス開発を行っている以上は避けるべき。
  2. そしてセキュリティのシフトレフトに興味を持つ会社は比較的セキュリティ意識が高いはず……。
  3. パブリックリポジトリであれば無料で導入できるようなので、公開しているライブラリなどにはぜひ導入したいですね。
Copyright © RAKUS Co., Ltd. All rights reserved.