無料で実施できるセキュリティ診断ツール活用法

2023年に公開された新規CVEは約28,000件に達し¹、Verizon DBIR 2024では侵害の約68%にヒューマン要因が絡むと報告されています²。攻撃面は増え続け、予算は増えない。この非対称に対して、無料で使える診断ツール群は品質とカバレッジの両面で成熟し、商用ペンテストの合間を埋める“常時監視に近い負荷の低い検査”を実現できる段階に来ました。ここではnmap・OWASP ZAP・Trivy・Semgrep・gitleaksを中核に、ゼロライセンス費で継続的なリスク可視化を行う実装と運用を、検出精度や工数、誤検知の扱いまで含めて、一般的な開発現場で再現しやすい形で具体的に示します。

無料診断で何ができて何ができないか

無料ツールであっても、到達可能な範囲は想像以上に広いのが現実です。外部の露出資産の棚卸しからポート・サービスの誤露出検知、HTTPレイヤのミス構成やOWASP Top 10（代表的なWebアプリの脆弱性分類）相当の典型的欠陥の自動テスト⁴、依存パッケージとコンテナイメージの既知脆弱性検査、ソースコード規約違反や既知の脆弱パターンの静的検出（SAST：静的アプリケーションセキュリティテスト）、そしてシークレット漏えいの早期発見まで、開発ライフサイクルの広い面をカバーできます。公的機関の勧告でも、ソフトウェア供給網の健全性を保つうえでSBOM（Software Bill of Materials：ソフトウェア部品表）生成と既知脆弱性スキャンの定常実施が推奨されており³、これらはすべて無償で着手可能です。

一方で、ビジネスロジックに深く根ざした欠陥や認可境界の破り方のようにシナリオ依存性が高い問題、ゼロデイの検出、社会的工学の実地検証は無料ツールだけでは代替できません。無償スキャンは“幅広く早期に”に強く、手作業を含む高度な侵入テストは“深掘りして確実に”に強いと理解し、四半期や半期の商用診断を年数回実施しつつ、その間を無料ツールの継続スキャンで埋めるアーキテクチャが費用対効果の観点で合理的です。

計測粒度と費用感の目安

参考値として、ZAPのベースラインスキャンは中規模SPAに対して8〜12分、Trivyのイメージスキャンはキャッシュ済みで30〜90秒/イメージ、Semgrepは1,000ファイル規模で2〜3分、gitleaksは数万コミットでも数十秒〜数分で完走することが多いです。チームの学習コストは初月に6〜10時間、以後の週次運用は30〜90分/週が目安です（いずれも環境とルールセットに依存）。

外部攻撃面の可視化とネットワーク診断

最初の焦点は外部から見える資産の棚卸しと誤露出の検出です。クラウド移行やマイクロサービス化で、テスト用の開放ポートや古い管理UIが放置される事例は珍しくありません。攻撃者と同じ視点を迅速に持つには、nmapのスクリプトエンジンを活用した軽量の反復スキャンが有効です。例えば本番ドメインに紐づくサブネットのTCP上位ポートを短時間で把握したい場合、次のように実行します。

# 重要ホストの上位ポートをスキャンし、簡易版バージョン検出とTLS検査を加える例
nmap -Pn -sS -sV --version-light --top-ports 2000 \
     --script ssl-enum-ciphers,ssl-cert,http-title \
     -oA out/nmap_top2000_$(date +%F) example.com

この結果から意図しない管理ポートや古いTLSスイート（通信暗号の組み合わせ）の残存が見つかれば、優先度の高い構成変更に直結します。一般に、ステージング用途のダッシュボードが外部へ誤露出し、本番データには未接続ながらもHTTP Basic認証のみで守られている、といったケースが見られます。DNSレコードとWAF配下の経路を見直し、nmapに加えてHTTPタイトル収集とステータスコードの傾向監視を夜間に回すだけでも、平均検知時間を日単位から時間単位へ短縮できた事例が報告されています。

アプリ層の軽量なヘルスチェックとして、HTTPヘッダの安全性を見ることも効果的です。CSP（Content Security Policy）やHSTS（HTTP Strict Transport Security）の未設定はZAPでも検出できますが、外形監視に組み込むならcurlとjqの簡易パイプで回し、差分だけをアラートに上げる運用だと騒音が抑えられます。

# セキュリティ関連ヘッダの存在確認とHSTSのmax-age検証
curl -sI https://www.example.com |
  awk 'BEGIN{IGNORECASE=1} /strict-transport-security|content-security-policy|x-frame-options|x-content-type-options/ {print}'

アプリとコンテナの自動スキャン：ZAP・Trivy・Semgrep・gitleaks

Webアプリの動的検査（DAST：実行中のアプリを対象にしたテスト）にはOWASP ZAPが堅実です。まずはクロール中心のベースラインをCIに組み込み、ビルド完了後に短時間で主要な誤設定とヘッダ問題、反射型の明白な欠陥を拾います。Docker公式イメージのスクリプトは学習コストが低く、URLを渡すだけで最低限の安全網が張れます⁷。さらに、ZAPはOWASP Top 10（2021）クラスの代表的な問題の検出を支援するガイドとルール群が整備されています⁴。

# ZAP Baseline Scan（軽量クロール）をCIから実行
docker run --rm -v $(pwd):/zap/wrk -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://app.example.com -r zap-report.html -x zap-report.xml \
  -m 5 -d -I --hook=/zap/wrk/zap-hook.py || true

スキャンの自動化を一歩進め、認証済み領域や特定のユーザロールでの振る舞いを検証するならAPI経由でテストシナリオを流します。依存の少ないリクエスト制御でも十分実用的です。

# ZAPをAPIで自動制御して、特定URL群を事前にスパイダー→アクティブスキャン
import time
from python_owasp_zap_v2.4 import ZAPv2

ZAP_ADDR = 'http://localhost:8090'
TARGET = 'https://app.example.com'
zap = ZAPv2(apikey='${ZAP_API_KEY}', proxies={'http': ZAP_ADDR, 'https': ZAP_ADDR})

zap.urlopen(TARGET)
zap.spider.scan(TARGET)
while int(zap.spider.status()) < 100:
    time.sleep(1)
scan_id = zap.ascan.scan(TARGET)
while int(zap.ascan.status(scan_id)) < 100:
    time.sleep(2)
alerts = zap.alert.alerts()
exit(1 if any(a for a in alerts if a.get('risk') in ('High','Medium')) else 0)

ソフトウェア供給網の安全性はTrivyが土台になります。OSパッケージとアプリ依存、さらにはSBOMの生成まで一気通貫に扱えるため、ベースイメージ変更や依存更新のリスクを定常的に把握できます⁵。

# コンテナイメージとSBOMの同時生成。CIキャッシュでDB更新コストを抑制
trivy image --timeout 5m --severity CRITICAL,HIGH --ignore-unfixed \
  --format table --output trivy.txt ghcr.io/acme/app:commit-sha
trivy sbom --format spdx-json --output sbom.spdx.json ghcr.io/acme/app:commit-sha

ソースコードの既知パターン検出はSemgrepが扱いやすく、ルールの可読性と拡張性が高いのが利点です⁸。CIでは重大度に閾値を設け、開発速度を殺さない運用にします。小さく始め、プロジェクト固有の誤検知抑制ルールを段階的に整備すると安定します。

# SemgrepでHigh以上をゲート。独自ルールはrules/配下に随時追加
semgrep ci --config p/owasp-top-ten --config rules/ --severity=ERROR --timeout=180 || {
  echo "Semgrep gate failed"; exit 1; }

シークレットの混入は被害規模の割に検知が遅れがちです。gitleaksをpre-receiveもしくはCIに入れ、履歴も含めて走らせると漏れの早期捕捉に効きます⁶。クラウドキーの形式は変わるため、定期的なシグネチャ更新と誤検知抑制の辞書整備を並走させます。

gitleaks detect --no-banner --redact --report-format sarif --report-path gitleaks.sarif || {
  echo "Secrets found"; exit 1; }

CI/CDへの統合と運用デザイン：誤検知、SLO、ROI

単発の手動スキャンは導入障壁が低い反面、継続性に欠けます。現実的な落とし所は、プルリク作成時にSASTとシークレット検査を走らせ、マージ後にDASTとイメージスキャンを非同期で回し、日次で外部資産の露出確認を行う流れです。開発速度を損なわない鍵は、重大度でゲートを分けること、差分に集中すること、タイムボックスを設定することの三点に集約されます。例えばSemgrepはHigh以上のみブロックし、MediumはSLI（サービスレベル指標）として観測に留める。ZAPはベースラインを毎コミットではなくmainブランチへマージ時に限定し、週次でフルスキャンを回す⁷。TrivyはPRで差分イメージを走らせ、定期的に全リポジトリのベースイメージ棚卸しを行う⁵、といった運用が現実解です。

CIでの失敗条件はスクリプトで明示します。失敗で開発を止めるのはHigh以上のみ、Mediumはメトリクス蓄積とし、一定期間内にバックログとして解消されなければエスカレーションする、という“二段階制”が摩擦を減らします。以下は閾値を一箇所に集約し、ツール横断で一貫性を保つ例です。

#!/usr/bin/env bash
set -euo pipefail
THRESHOLD=high   # high|medium|low

parse_and_gate() {
  local file=$1
  local severities=$(jq -r '.runs[].results[].level' "$file" | sort | uniq)
  if [[ "$THRESHOLD" == "high" && "$severities" =~ critical|high ]]; then
    echo "Gate: HIGH triggered"; exit 1
  fi
}

# 例: ZAPとgitleaksのSARIFを統合して評価
jq -s '{runs: (.[0].runs + .[1].runs)}' zap.sarif gitleaks.sarif > combined.sarif
parse_and_gate combined.sarif

SLO（サービスレベル目標）は検出から修正までのリードタイムと、ノイズ比率の二点を据えます。運用初期は誤検知が多いのが普通です。三週間ほど観測期間を設け、チームで“False Positiveカタログ”を合意形成し、ルールや除外ファイル、ベースラインの調整を進めると、スプリント三つ分でノイズが大きく減るケースが一般的です。ビジネス価値の観点では、無償ツールの組み合わせにより、外部委託の脆弱性診断の合間に生じる無検査期間をほぼ解消し、平均検知時間を週単位から日〜時間単位に圧縮できる点が大きいです。商用診断が1回あたり数百万円規模であるケースも踏まえると、ゼロライセンス費・軽微な運用工数で早期発見を積み上げることのROIは説明しやすいはずです。さらに、SASTとDASTの違いや脅威モデリングの実践と紐づけて、欠陥の“作り込み予防”に投資をシフトすれば、開発の手戻り削減にも波及します。

ケース：3ヶ月での定着化と成果（モデルケース）

中規模SaaSチームを想定したモデルケースとして、週次のメトリクスに“Highの新規検出数”“修正までの中央値”“誤検知率”の三つをダッシュボード化します。初月はZAPとSemgrepでHighがおおむね10〜20件見つかり、二次判定の結果2〜5件が誤検知、残りを2〜3週間で解消。二ヶ月目以降はHighの新規が0〜2件/週に低下し、ルール調整で誤検知率も約半減。検出から修正までの中央値は約2週間→1週間未満に短縮、といった推移が再現しやすい一例です。あわせてTrivyのSBOMを資産台帳に取り込み、基盤チームのベースイメージ更新頻度を月次から隔週へ引き上げると、脆弱性の滞留削減に寄与しやすくなります⁵。

導入の落とし穴と品質を上げるコツ

無料ツールは導入が簡単な反面、雑に入れるとノイズが増え、やがて止まります。品質を底上げするコツは、対象を絞って始めること、差分駆動で回すこと、そして“他の監視と同じ運用原則で扱うこと”です。ZAPはクロール範囲が広いほど時間が跳ねるため、サイトマップもしくは優先度の高いシナリオURLを事前に投げ、タイムボックスを厳格にします⁷。Semgrepはルールの増やし過ぎが禁物で、まずはp/owasp-top-tenに独自ルールを一つずつ重ね、誤検知の抑止はテストコードと生成物を対象外にするだけでも大きく効きます⁸。TrivyはDB更新のキャッシュが効果的で、CIの依存キャッシュを有効化するだけでスキャン時間が**20–40%**短縮されるケースが見られます⁵。gitleaksはリポジトリの履歴全走査が重いとき、直近差分をPRで、全履歴は日次のオフピークに回す二段構えにすると開発体験を損ないません⁶。さらに、kube-benchやkube-hunterも補助輪として組み込めますが、最初から全部盛りにせず、チームの処理能力に合わせてスコープを段階的に広げるのが現実的です。

# kube-benchの例（CIS Kubernetes Benchmarkに基づくノード評価）
docker run --rm -v /etc:/etc:ro -v /var:/var:ro -v /usr/bin:/usr/bin:ro \
  --pid=host aquasec/kube-bench:latest --version 1.29 --json > kube-bench.json

最後に、成果の可視化を忘れないことが定着の鍵です。ダッシュボードには“検出→修正のリードタイム”“Highのトレンド”“繰り返し検出されるルールのTop”を置き、プロダクトレビューのアジェンダに月次で組み込みます。検出の騒音を減らし、修正の速度を上げる取り組みがビジネスのスピードと両立していることを、定量で共有し続けてください。これはセキュリティチームだけの指標ではなく、エンジニアリング組織全体の生産性メトリクスに組み込む価値があります。

まとめ

無料ツールだけで完璧な防御はできませんが、現実の事故は“既知の欠陥の放置”が引き金になることが多いのも事実です。nmapで外部露出を見える化し、ZAPでアプリの誤設定を素早く拾い⁷⁴、Trivyで依存とイメージの既知脆弱性を抑え⁵、Semgrepとgitleaksで作り込みを早期に止める⁸⁶。この四点をCIに組み込むだけで、平均検知時間と滞留リスクは目に見えて下がります。あなたの組織では、今週どこに一番短い実験を差し込めるでしょうか。小さく始め、三週間の観測でノイズを整え、三ヶ月で安定運用へ。まずは最重要サービス一つを選び、今日のビルドに軽量スキャンを差し込むところから始めてください。成果が見えれば、次はスコープを広げ、レビューとメトリクスで継続性を担保していきましょう。