SASTによる脆弱性スキャンの重要性
Webアプリケーションや業務システムの安全性を高めるには、リリース直前の確認だけでなく、開発初期から脆弱性を見つけて修正する取り組みが重要です。本記事では、SASTによる脆弱性スキャンの重要性と、弊社取り扱い製品であるCheckmarx社のCheckmarx One、およびDerSecur社のDerScannerを活用した開発プロセスへの組み込み方を紹介します。
目次
起：脆弱性対策は「リリース前だけ」では間に合わない
Webアプリケーションや業務システムは、企業活動を支える重要な基盤です。顧客情報、取引情報、認証情報などを扱うシステムも多く、脆弱性を悪用されると、情報漏えいやサービス停止、企業としての信頼低下につながる可能性があります。
IPAの「安全なウェブサイトの作り方」では、Webアプリケーションで注意すべき脆弱性として、SQLインジェクション、OSコマンド・インジェクション、ディレクトリ・トラバーサル、セッション管理の不備、クロスサイト・スクリプティング、CSRF、アクセス制御や認可制御の欠落などが取り上げられています。
こうした脆弱性は、運用開始後に突然生まれるものばかりではありません。入力値の扱い、認証・認可の処理、エラー表示、外部ライブラリの利用、データベースとの連携方法など、設計や実装の段階で問題が残ることで、リリース後のリスクになります。
もちろん、リリース前の脆弱性診断や運用中の監視も重要です。しかし、開発の後半やリリース直前に脆弱性が見つかると、修正範囲の確認、再テスト、リリース調整などの手戻りが大きくなりがちです。
そのため、近年は「セキュリティ対策を開発の早い段階から組み込む」ことが重要視されています。いわゆるシフトレフトの考え方です。
承：SASTは開発初期にリスクを見つける手段
SASTとは、Static Application Security Testingの略で、日本語では静的アプリケーションセキュリティテストと呼ばれます。アプリケーションを実行する前に、ソースコードを解析し、脆弱性につながる可能性のある実装を検出する手法です。
SASTの大きな特徴は、開発の早い段階で利用しやすいことです。アプリケーションが完成していなくても、コードが存在していれば確認を進められるため、実装中の段階で問題に気づくことができます。
たとえば、SASTでは次のようなリスクの確認に活用できます。
- SQLインジェクションにつながる可能性のある実装
- クロスサイト・スクリプティングにつながる出力処理
- 入力値検証の不足
- 認証・認可処理の不備につながるコード
- ハードコードされたパスワードや認証情報
- 危険な関数や不適切な処理の利用
Checkmarx OneのSASTでは、ソースコードを入力として解析し、ソフトウェアプロジェクトをビルドまたはコンパイルしなくてもスキャンできます。また、開発ライフサイクルの任意の時点でスキャンを実行し、セキュリティレポートを生成できる点もSASTの特長です。
つまりSASTは、完成後に問題を見つけるためだけのものではありません。コードを作成した段階やコミットしたタイミングでスキャンを実行できるため、脆弱性の兆候を早い段階で発見しやすくなります。開発者が実装内容を把握しているうちに修正へ着手できるため、原因調査の時間を短縮し、後工程での手戻りを抑えることにもつながります。
転：手作業のレビューだけでは限界がある
セキュリティを高めるうえで、設計レビューやコードレビューは重要です。しかし、すべてのコードに対して、SQLインジェクション、XSS、認証・認可、秘密情報のハードコード、入力値検証などを人手だけで継続的に確認するのは簡単ではありません。
特に現在の開発現場では、アジャイル開発やDevOps、CI/CDの活用により、短いサイクルで機能追加や修正が行われます。開発者はスピードを求められる一方で、セキュリティの専門的な確認まで十分に行うことが難しい場合があります。
そこで重要になるのが、SASTを開発プロセスに組み込むことです。
たとえば、コードをコミットしたタイミングやビルドのタイミングで自動的にスキャンを実行できれば、セキュリティ確認を特別な作業ではなく、日常的な開発フローの一部にできます。
また、スキャン結果を確認する際には、単に検出件数を見るだけでは不十分です。どの脆弱性から対応すべきか、どの指摘が実際のリスクとして高いのかを判断し、優先順位を付けることが重要です。
そのため、SASTを運用する際は、検出結果を一覧で確認し、重大度や対応状況に応じて整理できる仕組みが重要です。検出された脆弱性をチームで確認し、対応要否を判断しながら優先順位を付けることで、限られた開発リソースの中でも効率的に改善を進めやすくなります。
このように、SASTは「検出して終わり」ではなく、開発チームが修正し、再確認し、継続的に改善するための仕組みとして活用することが大切です。
結：Checkmarx One／DerScannerでSASTを開発プロセスに組み込む
このように、SASTは「検出して終わり」ではなく、開発チームが修正し、再確認し、継続的に改善するための仕組みとして活用することが大切です。
SASTを効果的に運用するには、開発者が使いやすく、既存の開発フローに組み込みやすいツールを選ぶことが重要です。弊社では、SASTを支援する製品としてCheckmarx OneとDerScanner を取り扱っています。
Checkmarx OneによるSAST活用
Checkmarx Oneは、SASTを開発プロセスに組み込み、ソースコードに潜む脆弱性を早期に検出・管理するためのアプリケーションセキュリティプラットフォームです。ソースコードを解析し、ビルドやコンパイルの前段階でもセキュリティ上の問題を確認できるため、開発初期からの脆弱性対策に適しています。
たとえば、次のような流れで活用できます。
- 開発者がコードを作成する
- リポジトリへコミットする
- CI/CDパイプライン上でCheckmarx OneのSASTスキャンを実行する
- 検出された脆弱性を確認する
- 優先度の高い項目から修正する
- 再スキャンして修正状況を確認する
この流れを開発プロセスに組み込むことで、リリース直前にまとめてセキュリティ確認を行うのではなく、日々の開発の中でリスクを見つけやすくなります。
Checkmarx Oneは、Jenkins、GitHub Actions、Azure DevOpsなどのCI/CDツールと連携できます。また、GitLabについてもCLIを利用した連携が案内されており、既存の開発環境を活かしながらSASTスキャンを自動化しやすい点が特長です。
また、Checkmarx OneにはIDE連携の項目も用意されており、Eclipse、JetBrains、Visual Studio、VS Codeなどのプラグインが公式ドキュメント上で確認できます。開発者が普段利用している環境に近い場所でセキュリティ確認を行えるため、セキュリティ対応を開発作業に取り込みやすくなります。
DerScannerによるSAST活用
もう一つの選択肢として、DerScannerもSASTを活用した脆弱性対策に利用できます。DerScannerでは、開発中のソースコードをスキャンし、リリース前に脆弱性につながる可能性のある実装を確認できます。また、CI/CDパイプラインに組み込むことで、セキュリティレビューを継続的に実施しやすくなります。
GitやSubversionのリポジトリを指定したスキャンや、CI/CDツールとの連携にも対応しているため、既存の開発フローに合わせてSASTを取り入れやすい点も特長です。
本記事ではSASTを中心に説明しましたが、DerScannerはSAST以外の診断手法にも対応できるため、将来的に診断範囲を広げたい場合にも検討しやすい製品です。
SASTはセキュリティを開発の一部にするための第一歩
SASTによる脆弱性スキャンは、単に「危険なコードを見つける」ためだけのものではありません。開発者が早い段階でリスクに気づき、修正し、再発を防ぐための取り組みです。
脆弱性対策をリリース直前の確認作業にとどめるのではなく、日々の開発プロセスに組み込むことで、開発スピードを維持しながらセキュリティ品質を高めやすくなります。
Checkmarx OneやDerScannerを活用することで、SASTによる脆弱性スキャンをCI/CDや開発環境に組み込み、継続的なセキュリティ確認を行う体制づくりを支援できます。。
アプリケーションの安全性を高める第一歩として、まずはSASTを開発プロセスに取り入れることから検討してみてはいかがでしょうか。