SAST: 静的コード分析とは何ですか
SAST (静的アプリケーション セキュリティ テスト) を調べる分析手法と、 ソースコードを実行せずに解析し、セキュリティの脆弱性を示すパターンを探します。 実行中のアプリケーションを必要とする動的テストとは異なり、SAST は動作します。 コード上で直接実行できるため、開発の非常に初期段階で問題を特定できます。
SAST は、SQL インジェクション、クロスサイト スクリプティング (XSS)、 バッファ オーバーフロー、ハードコードされた資格情報、安全でない逆シリアル化など。 SASTツール コードのモデル (AST - 抽象構文ツリー) を構築し、セキュリティ ルールを適用します。 問題のあるパターンを特定します。
この記事では、主要な SAST ツールとそのパイプラインへの統合について説明します。 CI/CD と、最も一般的な問題の 1 つである誤検知を管理するための戦略。
何を学ぶか
- SAST の仕組みと DAST および IAST との違い
- CI/CD パイプラインで SonarQube、Semgrep、CodeQL を構成する
- Semgrep のカスタム ルールを作成する
- 誤検知を管理し、発見結果に優先順位を付ける
- SAST を IDE に統合して即座にフィードバックを得る
- 品質ゲートと展開のブロックしきい値
SAST、DAST、IAST: 違い
適切なツールを選択するには、3 つのアプローチの違いを理解することが重要です セキュリティテストの原則:
セキュリティテストアプローチの比較
| 特性 | SAST | ダスト | IAST |
|---|---|---|---|
| 分析 | ソースコード (ホワイトボックス) | 実行中のアプリケーション (ブラックボックス) | エージェントを使用したランタイム (グレーボックス) |
| いつ | 開発中、CI 内で | ステージング/プリプロダクション中 | 機能テスト中 |
| カバレッジ | すべてのコード（到達不能な場合も含む） | HTTP経由で到達可能な部分のみ | テスト中に実行されるコード |
| 誤検知 | 中～高 | ベース | 非常に低い |
| スピード | 速い (分) | 遅い（時間） | それはテスト次第です |
最適なアプローチと使用法 3つとも 補完的な方法: SAST 開発中の迅速なフィードバック、実行時のセキュリティを検証するための DAST、および テスト中の正確な相関関係。
SonarQube: 包括的なコード品質分析
ソナーキューブ そして、400,000 を超える組織で使用されている最も人気のある SAST プラットフォームです。 セキュリティに加えて、コードの品質、コードの匂い、重複、テストカバレッジも分析します。 コミュニティ バージョンはオープンソースで、30 以上のプログラミング言語をカバーしています。
Docker Compose を使用したセットアップ
SonarQube をローカルまたはステージング環境で起動する最速の方法 Docker Compose:
# docker-compose.sonarqube.yml
version: "3.8"
services:
sonarqube:
image: sonarqube:lts-community
container_name: sonarqube
ports:
- "9000:9000"
environment:
- SONAR_JDBC_URL=jdbc:postgresql://db:5432/sonarqube
- SONAR_JDBC_USERNAME=sonar
- SONAR_JDBC_PASSWORD=sonar_password
volumes:
- sonarqube_data:/opt/sonarqube/data
- sonarqube_logs:/opt/sonarqube/logs
- sonarqube_extensions:/opt/sonarqube/extensions
depends_on:
- db
db:
image: postgres:15
container_name: sonarqube-db
environment:
- POSTGRES_USER=sonar
- POSTGRES_PASSWORD=sonar_password
- POSTGRES_DB=sonarqube
volumes:
- postgresql_data:/var/lib/postgresql/data
volumes:
sonarqube_data:
sonarqube_logs:
sonarqube_extensions:
postgresql_data:
GitHub アクションへの統合
GitHub Actions を使用して SonarQube を CI/CD パイプラインに統合すると、以下を実行できるようになります。 プッシュまたはプルリクエストごとに自動的に分析が行われます。
# .github/workflows/sonarqube.yml
name: SonarQube Analysis
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
sonarqube:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: SonarQube Scan
uses: SonarSource/sonarqube-scan-action@v3
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
- name: SonarQube Quality Gate
uses: SonarSource/sonarqube-quality-gate-action@v1
timeout-minutes: 5
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
Semgrep: 軽量でカスタマイズ可能な静的解析
セムグレップ Return Security (現 Semgrep Inc.) によって作成されたオープン ソース SAST ツール これは、カスタム ルールの作成が簡単であるという点で際立っています。 SonarQubeとは異なります これにはサーバーが必要ですが、Semgrep は単純なコマンド ライン ツールとして実行できます。
Semgrep の威力は、次のような記述を可能にするパターン マッチング言語にあります。 見つけたいコードを書くのとほぼ同じように、直感的な方法でセキュリティ ルールを作成できます。
カスタム Semgrep ルールの作成
Python アプリケーションで SQL インジェクションを検出するための Semgrep ルールの例を次に示します。
# .semgrep/sql-injection.yml
rules:
- id: python-sql-injection
patterns:
- pattern: |
cursor.execute($QUERY)
- pattern-not: |
cursor.execute($QUERY, $PARAMS)
- metavariable-pattern:
metavariable: $QUERY
patterns:
- pattern: |
f"..."
message: >
Possibile SQL injection: la query SQL utilizza f-string
invece di parametri preparati. Usa cursor.execute(query, params)
con placeholder %s per prevenire injection.
severity: ERROR
languages: [python]
metadata:
cwe:
- "CWE-89: Improper Neutralization of Special Elements"
owasp:
- "A03:2021 - Injection"
confidence: HIGH
CI/CDの統合
Semgrep は、あらゆる CI/CD パイプラインに簡単に統合できます。セットアップは次のとおりです GitHub アクション:
# .github/workflows/semgrep.yml
name: Semgrep Security Scan
on:
push:
branches: [main]
pull_request:
jobs:
semgrep:
runs-on: ubuntu-latest
container:
image: semgrep/semgrep
steps:
- uses: actions/checkout@v4
- name: Run Semgrep
run: |
semgrep scan \
--config auto \
--config .semgrep/ \
--sarif --output semgrep-results.sarif \
--error \
--severity ERROR
- name: Upload SARIF
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: semgrep-results.sarif
CodeQL: GitHub のセマンティック分析
コードQL コードをデータとして扱う GitHub によって開発された分析エンジン 疑問です。パターンマッチングを使用する Semgrep とは異なり、CodeQL はデータベースを構築します。 リレーショナル コードを使用して、脆弱性を見つけるための複雑なクエリを作成できます。
CodeQL は分析に優れています 汚染の追跡：流れに従う能力 ユーザー入力 (ソース) から機密性の高い操作 (シンク) までのデータ。 途中で消毒されます。
CodeQL: 主な利点
- GitHub 上のパブリック リポジトリは無料
- テイント追跡による詳細なセマンティック分析
- GitHub Security Lab によって拡張および維持されるルール コミュニティ
- GitHub Advanced Security とのネイティブ統合
- QL言語でのカスタムクエリのサポート
誤検知の管理
SAST ツールの最大の問題の 1 つは、 誤検知: 実際には存在しない脆弱性を報告するアラート。誤検知率も 高いとツールに対するチームの信頼が損なわれ、次のような問題が発生します。疲労を警告する、ここで 開発者はすべてのアラートを無視し始めます。
誤検知を減らすための戦略
- ルールのチューニング: アプリケーションのコンテキストに関係のないルールを無効にします。
- 対象を絞った除外: 生成されたファイル、テスト、ベンダーコードを除外します
- ベースライン: ベースラインを確立し、新しい発見のみに焦点を当てます。
- 優先順位付け: 最初に CRITICAL および HIGH 重大度に焦点を当てます
- 抑制コメント: 文書化されたコメントで誤検知をマークします
# Esempio di suppression in codice Python
import hashlib
# Questo uso di MD5 e per checksum, non per sicurezza
# nosemgrep: python-weak-hashing
file_hash = hashlib.md5(file_content).hexdigest() # noqa: S303
# Esempio di suppression per SonarQube
password = get_env("DB_PASSWORD") # NOSONAR - password da env var, non hardcoded
品質ゲート: 導入をブロックする場合
Un クオリティゲート コードが適用する最小の品質および安全性のしきい値を定義します。 解放されるためには従わなければなりません。そしてSASTをツールから変換する仕組み パイプライン内のゲートをブロックするのに役立ちます。
品質ゲート推奨
| メトリック | しきい値 | アクション |
|---|---|---|
| 重大な脆弱性 | 0 | デプロイメントをブロックする |
| 高い脆弱性 | 0 (新しいコード) | デプロイメントをブロックする |
| 中程度の脆弱性 | 最大 5 (新しいコード) | 警告、再検討が必要です |
| セキュリティホットスポット | 100% レビュー済み | 審査されない場合はブロックする |
| コードカバレッジ | 最小 80% (新しいコード) | 警告 |
IDE の SAST: 即時フィードバック
最も効果的なシフトレフトは、SAST 分析を開発者の IDE に直接導入することです。 これにより、コードの作成中に脆弱性を見つけて修正できるようになります。 コミット前であっても。
- ソナーリント: IntelliJ、VS Code、Eclipse 用のプラグイン。ルールを同期するために SonarQube に接続しました
- Semgrep VS コード拡張: エディターで検出結果を直接強調表示します。
- GitHub コパイロット: 状況に応じたセキュリティ修正を提案します
IDE への統合により、フィードバック ループが数分から (CI/CD) 秒に短縮され、 開発者が問題をすぐに修正する可能性が大幅に高まります。
SAST のベスト プラクティス
いくつかのエンタープライズ プロジェクトで SAST を実装した後のベスト プラクティスを次に示します。 私たちは以下をお勧めします:
- ノンブロッキングモードで起動する: 最初の 2 ～ 4 スプリントでは、SAST はデプロイメントをブロックせずにレポートのみを生成します。これにより、チームはツールに慣れることができます
- ベースラインを確立する: 既存の所見の数を記録し、漸進的な削減に焦点を当てます。
- 新しいコードに注目してください: チームが従来の技術的負債に閉じ込められるのを避けるために、新しいコードにのみ厳しいしきい値を適用します。
- コンテキストのカスタム ルール: アプリケーション パターンに固有の Semgrep/CodeQL ルールを作成します
- 調査結果の毎週のレビュー: 週に 1 ～ 2 時間をセキュリティ チャンピオンとの SAST 結果のトリアージに充てます。
- 指標と傾向: MTTR、誤検知率、脆弱性密度を経時的に追跡します。
結論
SAST は、DevSecOps パラダイムにおける防御の最初の層です。の脆弱性を特定する ソースコードを実行する前に保存しておくことで、時間、お金、リスクを節約できます。 成功の鍵は適用範囲と使いやすさのバランスです。ルールが多すぎると生成される アラート疲れ、重大な脆弱性を通過させるものが少なすぎる。
次の記事では、詳しく見ていきます DAST (動的アプリケーションセキュリティテスト)、 実行中のアプリケーションを分析して検出する SAST を自然に補完するもの XSS、CSRF、構成ミスなどのランタイム脆弱性。