こんにちは！セキュリティチームで日々、泥臭いインシデント対応や脆弱性診断を行っているエンジニアです。
今回は、新人のIT担当者や「セキュリティはなんだか難しそう……」と一歩引いてしまっている開発者の皆さんに向けて、APIのセキュリティ診断、それも「自動化」の技術について分かりやすくお話ししていきたいと思います。
「APIの脆弱性診断って、専門家が特殊なツールでカチャカチャやるものじゃないの？」と思われるかもしれませんが、実は今の開発現場では、家を建てるときに自動で耐震テストをするように、システムの設計図（OpenAPI定義書）を使って自動でセキュリティチェックを行うのが常識になりつつあります。
小難しい専門用語が出てきても「一歩ずつ対策を学んでいきましょう！」という気持ちで優しく解説していきますので、ぜひ最後までお付き合いくださいね。
—
1. 家の鍵に例える「APIの脆弱性」と「設計図チェック」の重要性
まず、私たちが普段作っている「API」とは何なのか、身近なものに例えて考えてみましょう。
皆さんの自宅には玄関の鍵がありますよね。泥棒は、窓の鍵が閉め忘れていないか、合鍵が適当に隠されていないかを探して侵入しようとします。
WebアプリケーションやAPIにおける「脆弱性（セキュリティの穴）」も、まさにこれと同じです。
- APIの仕組み：家の中に自由に出入りできる「宅配ボックス」のようなものです。
- 脆弱性：その宅配ボックスの暗証番号が「1234」になっていたり、誰でも勝手に開けられる状態になっていることです。
開発の現場では、家が完成した後に「泥棒が入れるかテストしよう！」と慌てることがよくあります。しかし、家が建ってから欠陥が見つかると、直すのにもの凄くお金と時間がかかりますよね。
そこで登場するのが、「設計図（OpenAPI定義書）の段階、あるいはビルドの段階で自動的にセキュリティテストを行う手法」です。これなら、泥棒が入れる隙（脆弱性）が生まれる前に、設計ミスをピシャリと見つけ出すことができます。
—
2. OpenAPI定義書を使った「DAST（動的アプリケーションセキュリティテスト）」の自動化
ここで、「DAST（ダスト）」という言葉が出てきます。難しそうに聞こえますが、要するに「実際に動いているアプリに対して、外側から攻撃っぽいうそっこ攻撃をしてみて、穴がないか調べるテスト」のことです。
昔のDASTツールは、「人間が手動で画面をポチポチ操作して教え込む」必要があり、非常に面倒でした。しかし、今の時代はOpenAPI（旧Swagger）の定義書という、いわば「APIの設計図」をツールに読み込ませるだけで、自動的に数百・数千通りの攻撃パターンのテストを作って実行してくれるのです。
なぜOpenAPI定義書が強力なのか？
OpenAPI定義書には、「このAPIのURLには、こういう数字や文字（パラメータ）を入れないとエラーになりますよ」というルールが細かく書かれています。
セキュリティ自動化ツール（例えば、OWASP ZAPや各種APIセキュリティスキャナーなど）は、この設計図を読み込むことで、次のようなことを自動で理解します。
1. 「おっ、このURLにはユーザーIDを数字で入れるんだな」
2. 「じゃあ、ここに数字じゃなくて、変な文字列や巨大なデータを入れてもエラー落ちしないか試してみよう」
3. 「もし、裏側のデータベースが見えちゃうような返事が返ってきたら、それは脆弱性（穴）だ！」
人間がやると数日かかる作業を、わずか数分で終わらせてくれる最高の相棒というわけです。
—
3. CI/CDパイプラインへの統合（GitHub Actionsの実装例）
さて、ここからが本番です。「設計図から自動でテストができる」と分かっても、それを毎回エンジニアが手動で実行していたら忘れてしまいますよね。
だからこそ、コードをGitHubにプッシュした瞬間や、本番に出す前のビルドの仕組み（CI/CDパイプライン）の中に、このセキュリティテストを組み込んでしまいましょう。
今回は、開発現場でよく使われる GitHub Actions を使った具体的な設定サンプルをご紹介します。難しく見えますが、日本語のコメントを付けましたので、一つずつ見ていきましょう。
name: 自動APIセキュリティ診断 (DAST)
# GitHubにコードがプッシュされた時や、プルリクエストが作成された時に動きます
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
api-security-scan:
runs-on: ubuntu-latest
steps:
# 1. リポジトリのソースコードをサーバーにダウンロードする
- name: コードのチェックアウト
uses: actions/checkout@v4
# 2. テスト対象のAPIサーバーを一時的にローカルで起動する（Dockerなどを使用）
- name: テスト用APIサーバーの起動
run: |
docker compose up -d
# サーバーが完全に立ち上がるまで少し待つ
sleep 10
# 3. OpenAPI定義書（openapi.yaml）を使って、OWASP ZAPでAPIスキャンを実行する
- name: OWASP ZAP APIスキャンの実行
uses: zaproxy/action-api-scan@v0.4.1
with:
# OpenAPI定義書のファイルパスを指定
target: 'http://localhost:8080/openapi.yaml'
# スキャン結果のレポート形式を指定（必要に応じてHTML等で保存可能）
format: 'json'
fail_action: true # 脆弱性が見つかった場合はパイプラインを失敗（赤色）させる
# 4. テストが終わったらAPIサーバーを片付ける
- name: テスト用サーバーの停止
if: always()
run: docker compose downこの設定ファイルをプロジェクトの .github/workflows/ ディレクトリに置いておくだけで、開発者がうっかりセキュリティの穴があるコードを書いても、GitHubが「ちょっと待った！」と自動で止めてくれるようになります。
—
4. 現場のセキュリティ担当からの一言
セキュリティの自動化を進めるとき、現場でよくある失敗が「厳しくしすぎて、エラーばかりが出て開発が止まってしまう」というケースです。これでは開発チームとセキュリティチームが険悪になってしまいますよね。
最初は、見つかった脆弱性をいきなり「エラー（ビルド失敗）」にするのではなく、まずは「警告（アラート）」として通知する設定から始めるのが、現場をうまく回すコツです。少しずつチーム全体でセキュリティの意識を高め、チームの味方になるような自動化を目指していきましょう。
一歩ずつ、確実に安全なシステムを作っていけば大丈夫です。一緒に頑張りましょう！
コメント