🛡️ 開発・検査・トリアージを分離したGoogleのSDLC常時セキュリティースキャン

インフラへ載せるコードの各変更を、提出前に機械速度で検査する枠組みを、Google が 2026-09-18 に公開しました。対象はインフラへデプロイする数億行規模のコードです。公式が示す効果量は Google 内部運用の主張であり、公開キットのベンチマークではありません。

この記事では、Changing the game: Using agentic AI to secure infrastructure code が説明する常時スキャン方法論を、構造・データ・公開近似の入口まで整理します。内部運用が正本で、Mantis はその近似と公開入口です。著者は Andrés Lagar-Cavilla（Distinguished Engineer）と Parthasarathy Ranganathan（VP, Engineering Fellow）です。

読者が得られるのは次です。

• 開発・検査・トリアージを別ハーネスにする独立性設計
• 変更単位の事前提出と夜間第二層の二層防御
• 公開 OSS で試すときの CLI、workspace 分離、鮮度ゲート

この記事の全体像。以下、順に解説します。

常時セキュリティースキャンとは

目的は、インフラへ載せるコードの各変更を提出前に検査し、脆弱性がコードベースと本番へ入る前に止めることです。実施主体は Google AI and Infrastructure チームです。公式の効果量は、月あたり数百件の脆弱性がコードベースまたは本番へ到達する前に止まる、という主張です。

産業の従来慣行は、巨大な一回限りのセキュリティースキャンです。そのスキャンは遅く、文脈が薄く、発見時点が提出後に寄ります。本方法論の実行単位は、各コードチェックインの事前提出検査です。検査対象はスタックの全層で、開発者が既に使う提出ツールへ組み込みます。セキュリティは、ルールチェッカーや可読性レビューと同列の継続ルーチンになります。変更単位の方が巨大スキャンより必要文脈が小さく、検査の実効が上がる、と公式は書いています。

防御は二層です。

局所脅威モデルの材料は live codebase metadata です。スキャンエージェントは、パッケージとライブラリを横断する dependence call graph で脅威モデル文脈を拡張します。脅威モデルを継続スキャンの一部にすると、開発者が脅威と依存を継続更新する、と Systems ブログは書いています。更新責任の一次記述は、開発者による継続更新までです。専用の配布サービス名は同記事に出ません。

検査の応答は二段です。

1. 軽量スキャンが指摘を出す。
2. 専門トリアージエージェントが、AST 解析、call-graph 走査、pre-indexed domain safety rules で、攻撃者が到達できる経路かをプログラム的に証明する。

トリアージの公式測度は、適合率（precision）92% 超、完了 1 分未満です。偽陽性率は、局所で精密な脅威モデルを使った一部ケースで 3% まで下がった、と主張します。

修正エージェントは、スキャン結果と generated proofs（脆弱性の行使を示すコード断片）から、内部コーディング標準に沿った修正を組み立てます。提出先は、元の変更リクエストの人間レビューです。

起点ブログは、この取り組みで Mantis を evolve し、局所脅威モデル群と組み合わせたと書いています。内部常時スキャンが正本です。google/mantis は近似と公開入口です。末尾の CTA は、Google Cloud、Gemini Enterprise、Trillium / Ironwood 上の Gemini を「このエージェントパイプラインを支えるプラットフォーム」として挙げます。ハーネス・ルール・コンテキストの分離やトリアージ手順との接続構成までは書いていません。

公式図。Code Check-in から Pre-submit（脅威モデル、検査、トリアージ、修正提案）を経て Human review、Post-submit の夜間層へ続く。出典: Using agentic AI to secure infrastructure code

特徴

• 実行単位は、各コード変更の事前提出検査です。
• 対象は、インフラへデプロイする数億行規模です。
• 公式の効果量は、月あたり数百件の脆弱性をコードベースまたは本番の手前で止める、です。
• 局所脅威モデルは live codebase metadata を使い、パッケージ横断の dependence call graph で文脈を広げます。
• 脅威モデルを継続スキャンへ入れると、開発者が脅威と依存を更新し続ける、と公式が書いています。
• 応答は二段です。軽量スキャンの後に、AST / call-graph / pre-indexed domain safety rules による到達証明が続きます。
• トリアージの公式測度は、適合率（precision）92% 超、完了 1 分未満です。
• 偽陽性率は、一部ケースで 3% まで下がった、と公式が主張します。
• 第二層は、夜間統合テストの事後提出スキャンです。
• 修正エージェントは generated proofs を材料にし、修正を元 CR の人間レビューへ載せます。
• 原則 1 は、開発・スキャン・トリアージのハーネス、規則、文脈の分離です。軽量 AI と決定論的構造検証を対にします。
• 原則 2 は、既存脅威モデルの投入です。最新の脅威モデルは事前提出スキャンの真陽性率を改善し、チームのセキュリティ態勢の最低水準を引き上げます。
• 原則 3 は、モデル選択よりマルチエージェントハーネスが変動を吸収する、という運用判断です。
• 原則 4 は、人間レビュー付きの自動修正で検出から解消までの時間を縮めることです。

関連技術比較

ユースケース別推奨

系譜の差分

公開近似との対応

構造

登場するのはコンポーネント名と責務です。開発・検査・トリアージは会話履歴を共有しません。局所脅威モデルは共有アーティファクトとして供給します。

システムコンテキスト図

人アクター、対象の枠組み、ソース管理と CI、人間レビューの関係です。

図のセキュリティ専門家経路は、公開キットを使う場合の追加統制です。内部方法論の一次記述は、修正を元の変更リクエストの人間レビューへ載せる工程です。

人アクターと生成アクター

対象フレームワーク

外部システム

コンテナ図

原則 1 をそのまま配置します。開発・検査・トリアージは、それぞれ独立したハーネス・ルール・コンテキストを持ちます。

開発ハーネス

検査ハーネス

トリアージハーネス

局所脅威モデル供給

夜間第二層

修正提案

コンポーネント図

一次ブログが名前を付けた部品はそのまま置きます。配布面が一次に無い部品は、公開近似とラベルします。

検査ハーネス

トリアージハーネス

局所脅威モデル供給

公開近似 受け渡しと隔離

修正提案

一次で言える範囲

トリアージ入力はスキャン結果と AST / コールグラフ / ルール索引です。脅威モデル供給からトリアージハーネスへ会話を張りません。開発側の読み経路は advise 相当です。

脅威モデル更新の責務

更新の置き場所は、局所脅威モデル供給コンテナです。一次ブログが書く更新行為の主体は開発者です。継続スキャンの入力に脅威モデルを置くことで、開発者は脅威と依存を継続更新します。

公開近似では、threat-model skill が供給コンテナ内の再合成役になります。入力は KB の architecture と entities に限定します。スナップショット ID が変わったパスではモデルを再合成します。開発側の参照は advise 経路です。検査側の参照は検査用コンテキストへのアーティファクト供給です。

ルール索引の検査側への受け渡し

公開近似の配布面は structural-index の照会ヘルパーです。索引は HINT として、コールグラフ走査と軽量スキャンの順位付けに使います。ドメイン安全ルールはトリアージ用ルール側の事前索引であり、structural-index とは別系統です。ステージ間で渡すものは発見、構造ヒント、proof、脅威モデルアーティファクトです。会話履歴は渡しません。

データ

エンティティの何が、どういう属性かを示します。属性名は起点ブログの用語、または公開 OSS 契約のキーに限ります。ブログに無いキーは公開近似と注記します。

概念モデル

検査の単位は CodeChange です。軽量検出は LightweightScanFinding、到達判定は TriageVerdict、修正は FixProposal として元の変更に載ります。

CodeChange

TriageVerdict

独立エンティティ

情報モデル

属性のみです。型は概念型です。Zenn の Mermaid 上限に合わせ、図中の型注釈は省略し、属性の根拠表でキーを示します。

図の箱は主要属性に絞っています。threat_actors_and_vectors、discovery_commit、repro_file_path、include_contents など図から省いたキーは、下の根拠表と公開 schema 側に残します。

属性の根拠

構築方法

本節は公開近似（google/mantis OSS + CI）の実装案です。内部常時スキャンの公開 API はありません。ブログの効果量は内部運用の主張であり、本節のコマンドの測度ではありません。キット自体の状態機械、隔離 backend、VERIFIED_SECURE は Google Mantis OSSはAI指摘を増やす道具ではなく再現証拠の品質ゲートである に書いています。以降は、変更単位の事前提出と三役の独立性へ近づける差分だけを扱います。

確認した公開リポは google/mantis、default branch main、ライセンス Apache-2.0 です。GitHub API 上の更新は main の SHA 6f523a39ccb535b4f5411310f31e872fab954e07（committer date 2026-09-18T16:08:12Z）です。stargazers_count は 1608（2026-09-19 取得。ライブ指標）です。

必須パラメータ

前提条件

• 隔離された作業ホストを用意します。README は本番システム・機微データ・内部網へ接続した機械での実行を禁じます。
• Python 3.14 以上を用意します。reference/install.sh が sys.version_info >= (3, 14) をゲートします。
• python3-venv を用意します。
• 動的再現を使う場合は Docker / Podman + gVisor、/dev/kvm の microsandbox、または隔離 VPC の GCE を用意します。
• ネイティブ Windows は install.sh が終了コード 1 で止めます。WSL2 を使います。

インストール手段 1: ADK 参照ハーネス

git clone https://github.com/google/mantis.git
cd mantis
cd reference && ./install.sh
source .venv/bin/activate
gcloud auth application-default login
python3 scripts/configure.py --auto
python3 scripts/configure.py --test --probe

• install.sh は .venv を作り、pip install --require-hashes -r requirements.txt でハッシュ固定依存を入れます。子シェルの activate は呼び出し元へ残らないので、以降の python3 直呼びの前に source .venv/bin/activate するか、.venv/bin/python3 を使います。
• run.sh は起動のたびに .venv を有効化します。
• reference/mantis-env.sh に export MANTIS_HOME=<clone ルート> を書きます。
• シェル起動時に source "$MANTIS_HOME/reference/mantis-env.sh" します。

インストール手段 2: スキル CLI

README_AGENTS.md の記載コマンドです。

npx skills add google/mantis

2026-09-19 に https://www.skills.sh/google/mantis を開くと、ページ見出しは google/mantis、表示は 21 skills です。この経路はエージェントの skill ディレクトリへ SKILL.md を配ります。ADK の .venv と ./run.sh は手段 1 が別途必要です。

バージョン確認

cd reference
source .venv/bin/activate
python3 --version
python3 scripts/configure.py --show
python3 scripts/configure.py --test --probe
./run.sh /path/to/code --dry-run

• --dry-run は計画を印字してモデル実行前に戻ります。
• 運用記録には git -C /path/to/mantis rev-parse HEAD を残します。

サンドボックスの初回選択

事前提出の軽量段は static-only で始めます（実装案）。トリアージ後の再現は gvisor または microsandbox へ切り替えます（実装案）。

利用方法

公開 CLI の入口から、変更単位の事前提出相当、トリアージ相当、脅威モデル更新、開発側コンテキストまでを順に示します。

公開 CLI の入口

キャンペーン起動の入口は reference/run.sh です。launch.py の argparse に載るフラグだけを公式操作として使います。--sync は README_AGENTS のスナップショット契約（オーケストレータ専用）です。launch.py の argparse にはありません。

cd reference
./run.sh path/to/code
./run.sh path/to/code --focus "look for IDOR"
./run.sh path/to/code --no-budget --parallel 32
./run.sh path/to/code --sandbox static-only --model gemini-3.7-flash
./run.sh path/to/code --dry-run

事前提出相当（変更単位）

起点ブログの事前提出は「各コードチェックインをリアルタイムに評価する」です。公開物はリポジトリ全体キャンペーンが既定です。公開近似では、スキャン対象パスはリポジトリ（またはファイル）のまま渡し、差分パスは --focus の自然言語に埋め込みます。--focus は planner への指示であり、非変更ファイルの読み取りを禁止する allowlist ではありません。

次の JSON は同梱 reference/workflow.json の既定キーではありません。main.py が config["scan_mode"] と config["sarif_output"] を読むオーバーレイで、置く場所は workflow.local.json です。SARIF はキーがあるときだけ core.sarif.write_sarif が出力します。

{
  "config": {
    "scan_mode": "file-by-file",
    "sandbox": { "type": "static-only", "options": {} },
    "sarif_output": "workspace/mantis.sarif"
  }
}

source "$MANTIS_HOME/reference/mantis-env.sh"
cd "$MANTIS_HOME/reference"
CHANGED="$(git -C /path/to/app diff --name-only origin/main...HEAD | tr '\n' ' ')"
./run.sh /path/to/app \
  --sandbox static-only \
  --focus "pre-submit review of changed paths: ${CHANGED}" \
  --max-time 15m \
  --token-budget 2M \
  --db /var/mantis/presubmit/knowledge.db

トリアージ相当

起点ブログのトリアージは AST、call-graph、pre-indexed domain safety rules で到達可能性をプログラム的に証明します。公開 OSS で一次確認できる近似は次の 2 段です。

1. /mantis-structural-index が workspace/kb/structural_index/catalog.sqlite を作り、workspace/helpers/query_structural_index.py が HINT-only のクエリ契約になります。
2. /mantis-critic が finding の本番実行可能性を更新します。

pre-indexed domain safety rules という設定キーは公開 CLI にありません。

# workspace/helpers/query_structural_index.py の公開契約
# 操作名は SKILL.md。CLI サブコマンド名はリポに固定配布されていない。
def resolve_symbol(name, language=None, file=None, namespace=None):
    ...


def find_callers(symbol_id, limit=100, offset=0):
    ...


def find_callees(symbol_id, limit=100, offset=0):
    ...


def get_function_boundary(file, line):
    ...


def get_coverage(file=None):
    ...

/mantis-review --state_root /var/mantis/presubmit --snapshot_root /var/mantis/presubmit/snap
/mantis-critic --state_root /var/mantis/presubmit --snapshot_id <SNAPSHOT_ID>

空の callers は HINT です。consumers は grep と和集合を取ります。

脅威モデル更新

OSS 契約では /mantis-threat-model はソースを読みません。読むのは workspace/kb/architecture.md と workspace/kb/entities/*.md です。出力は workspace/kb/THREAT_MODEL.md です。先頭行は KB_SNAPSHOT: <CUR> です。

/mantis-architecture
/mantis-threat-model --state_root /var/mantis/presubmit --snapshot_id "<SNAPSHOT_ID>"

実装案の更新責任は次です。

• CI: /mantis-architecture の後に /mantis-threat-model を同じ検査 workspace で回します。
• 開発者: 検査結果を読んだあと、人間が KB エンティティを直します。次回パスがモデルを再合成します。
• /mantis-advise は脅威モデルを読む経路であり、THREAT_MODEL.md を書く経路ではありません。

開発側コンテキスト

検査キャンペーンの会話を引き継がず、knowledge.db だけを読みます。呼び出しは相対パス禁止です。

source "$MANTIS_HOME/reference/mantis-env.sh"
"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/scripts/advise.py" --file src/auth.py
"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/scripts/advise.py" --file src/auth.py --json
"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/scripts/advise.py" --remediate <finding_id>

--remediate は knowledge.db から改修計画を照会します。パッチ適用ではありません。開発エージェントの rule pack は advise スキルだけを載せます（実装案、原則 1）。

原則 1 の操作化

同じ session_id を 3 役割で再利用する運用は、原則 1 の操作化から外します。

GitHub Actions（実装案）

次の YAML は実装案です。google/mantis リポに公式 workflow は見当たらず、./run.sh に無いフラグは書いていません。

# 実装案。公式同梱 workflow ではない。
# 意図の一次: https://cloud.google.com/blog/topics/systems/using-ai-agents-to-secure-google-infrastructure
name: mantis-presubmit-approx
on:
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
    env:
      MANTIS_HOME: ${{ github.workspace }}/mantis
      MANTIS_STATE: ${{ github.workspace }}/.mantis-presubmit
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          path: app
      - uses: actions/checkout@v4
        with:
          repository: google/mantis
          path: mantis
          # 2026-09-19 時点の main。ライブ HEAD ではない。
          ref: 6f523a39ccb535b4f5411310f31e872fab954e07
      - uses: actions/setup-python@v5
        with:
          python-version: "3.14"
      - name: install-harness
        working-directory: mantis/reference
        run: ./install.sh
      - name: configure-static-only
        working-directory: mantis/reference
        run: |
          source .venv/bin/activate
          python3 scripts/configure.py --sandbox static-only --auto
      - name: presubmit-scan
        working-directory: mantis/reference
        env:
          GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
        run: |
          set -euo pipefail
          source ./mantis-env.sh
          mkdir -p "$MANTIS_STATE"
          CHANGED=$(git -C "$GITHUB_WORKSPACE/app" diff --name-only "${{ github.event.pull_request.base.sha }}...${{ github.sha }}" | paste -sd, -)
          ./run.sh "$GITHUB_WORKSPACE/app" \
            --sandbox static-only \
            --model gemini-3.7-flash \
            --focus "pre-submit: changed files ${CHANGED}" \
            --max-time 20m \
            --token-budget 2M \
            --db "$MANTIS_STATE/knowledge.db"

よく使うオプション（launch.py 実在）

運用

稼働の主対象は、数億行規模のインフラコードへ載せる各変更の継続検査です。セキュリティを、ルールチェッカや可読性レビューと同じ日常工程にします。公開入口は Mantis OSS です。稼働設計の正本は内部の常時スキャンです。

稼働の位置づけ

• 主対象は、数億行規模のインフラコードへ載せる各変更の継続検査です。
• セキュリティを、ルールチェッカや可読性レビューと同じ日常工程にします。
• 公開入口は Mantis OSS です。稼働設計の正本は内部の常時スキャンです。

二層防御の役割分担

事前提出のレイテンシ目標

チェックイン経路の検査は、開発を止めない応答速度が前提です。1 分未満は軽量スキャン全体ではなく、専門トリアージエージェントの完了時間です。

# 公開近似。内部 presubmit ゲートそのものではない。
"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/scripts/launch.py" /path/to/repo --preflight-only
"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/scripts/configure.py" --test --probe

夜間第二層

# 複数ファイルにまたがる欠陥向け。事前提出の代替ではない。
# scan_mode は workflow.local.json か python3 main.py 直呼び（launch.py argparse 外）。
"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/main.py" /path/to/repo \
  --scan-mode cross-functional --yes

修正を元の変更リクエストへ載せる

修正エージェントは、スキャン結果と generated proofs から修正を組み立てます。提出先は新規チケットの洪水ではなく、元の変更リクエストの人間レビューです。OSS の /mantis-patch は独立したパッチ検証ループです。内部の「元 CR へ載せる」配線は未公開です。

"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/scripts/advise.py" --file src/auth.py
"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/scripts/advise.py" --remediate "<finding_id>"

--remediate は改修計画の照会です。内部の「元 CR へ載せる」配線の代替ではありません。

脅威モデル鮮度

内部の鮮度 SLA は未公開です。公開の機械契約は OSS にあります。

KB_SNAPSHOT: abc123def
> STALE: Threat model NOT re-evaluated this pass; carried unchanged from snapshot abc123def.

python3 -c "import pathlib,re; p=pathlib.Path('workspace/kb/THREAT_MODEL.md'); t=p.read_text(); m=re.match(r'^KB_SNAPSHOT:\s*(.+)$', t.splitlines()[0]); print(m.group(1) if m else 'MISSING')"

検査と開発のコンテキスト分離

開発エージェント、スキャンエージェント、トリアージエージェントは、harnesses / rules / context を分けて動かします。脅威モデル成果物は検査へ渡します。開発チャットの生ログは検査へ渡しません。ADK 参照ハーネスはステージごとに include_contents="none" です。

{
  "id": "researcher",
  "type": "agent",
  "include_contents": "none",
  "tools": [
    "read_file",
    "write_file",
    "list_files",
    "get_summary",
    "get_threat_model",
    "get_plan",
    "report_findings",
    "get_findings"
  ]
}

実ファイルの researcher ノードに include_contents は無く、graph_loader.py が未指定時に "none" を注入します。上はロード後の実効設定を再構成した例です。

状態確認と再開

"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/scripts/launch.py" /path/to/repo --resume "<run_id>"
"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/main.py" /path/to/repo --resume "<run_id>"
"$MANTIS_HOME/reference/.venv/bin/python3" "$MANTIS_HOME/reference/scripts/advise.py" --file src/auth.py --json

再開の公式入口は launch.py / run.sh です。main.py も --resume を受け付けます。

--resume は成果物を引き継ぎ、予算はゼロから始まります。

スケール操作の公開近似

"$MANTIS_HOME/reference/run.sh" /path/to/repo --no-budget --parallel 32
"$MANTIS_HOME/reference/run.sh" /path/to/repo \
  --max-time 2h --token-budget 10M --max-steps 500 --max-node-visits 50

ベストプラクティス

方法論の 4 原則を、公開近似の操作へ落とします。

原則 1: Keep systems separate

• 開発・スキャン・トリアージを、別ハーネス・別規則・別コンテキストで動かします。
• 同一会話履歴で「書いたコードを自分で検査」させません。
• 検査エージェントへ渡すのは成果物（脅威モデル、索引、finding JSON）です。
• OSS では開発側を /mantis-advise、検査側を researcher / review / critic に分けます。
• パッチ合成は検査判定と職務分離します。

軽量 AI と決定論的構造検証を組にする

第一段は軽いモデルで候補を出します。第二段は AST・コールグラフ・事前索引規則で到達を証明します。構造索引は HINT です。grep との和集合を監査集合にします。

1. grep で候補の床を作る
2. resolve_symbol から find_callers で順位を付ける
3. 和集合を監査する

原則 2: 脅威モデルは検査へ渡す

• 既存の局所脅威モデルをスキャン／トリアージへ渡します。
• 最新の脅威モデルは事前提出スキャンの真陽性率を改善し、チームのセキュリティ態勢の最低水準を引き上げます。
• 開発チャットの雑談は検査コンテキストへ入れません。
• Getting started の人間 curated 知識（直さないバグの定義）は検査コンテキストへ入れます。

原則 3: モデル選択よりマルチエージェントハーネス

• モデル入替の変動は、ステージ契約と決定論ハーネスで吸収します。
• スキルを対話セッションの記憶に頼らず、JSON / SQLite のディスク契約でつなぎます。
• critic / reproduce / sandbox 実行は、オーケストレータが強制します。

原則 4: 人間レビュー付きの自動修正

• 修正エージェントは proofs 付きの小さな diff を作ります。
• 提出先は元 CR です。
• 人間レビューを残します。
• OSS で VERIFIED_SECURE を出す条件は、未パッチ到達証拠、パッチ後ビルド成功、benign control、攻撃失敗、変異 3 件以上の再攻撃失敗です。

事前提出を止めない偽陽性制御

• 事前提出ゲートは、トリアージ済みの到達可能経路だけを開発者へ返します。
• 低リスク・hardening 項目は偽陽性へ混ぜず、キャリブレーションで別帯域にします。
• 最初から全リポジトリを全開にせず、小さなスキャン、人間サンプルレビュー、規則更新の順にします。

脅威モデル鮮度をゲートにする

• pinned 運転では、KB_SNAPSHOT と SNAPSHOT_ID の一致を critic の一括判定条件にします。
• コードが大きく動いたパスでは STALE のまま流さず、/mantis-threat-model を再導出します。
• Intent: SAMPLE_OR_TEST_ONLY は 5 項チェックリストがすべて真のときだけ書きます。sync 後は継承しません。

注意点

数値の帰属、ドキュメントと実装の差、資料間の食い違い、未確認事項をここに集約します。

数値と公開範囲の上限

ドキュメントと実装の乖離

資料間の食い違い

未確認事項

トラブルシューティング

利用者が稼働中に見る症状だけを書きます。ゲートはトリアージ済みの到達可能経路に限ります。索引は HINT としてだけ使い、grep との和集合を監査集合にします。開発会話を検査コンテキストへ渡しません。

事前提出が開発を止める

夜間だけ欠陥が出る

脅威モデルと索引の誤用

コンテキスト同調と再開

まとめ

• Google の常時スキャン方法論は、各チェックインの事前提出検査を第一層、夜間統合を第二層にします。
• 核はモデル単体ではなく、開発・検査・トリアージのハーネス・ルール・コンテキストを共有しない独立性です。
• 軽量スキャンの疑いを、AST・コールグラフ・事前索引ルールで到達証明してから開発者へ返します。
• 修正は新規チケットではなく、元の変更リクエストの人間レビューへ載せます。
• 公開入口は Mantis OSS です。内部の効果量（月数百件、FP 3%、適合率（precision）92% 超、トリアージ 1 分未満）は内部運用の主張であり、公開キットの SLO にはしません。
• 試すときは workspace を 3 分割し、脅威モデル成果物だけを検査へ渡し、索引は HINT として grep と和集合を取ります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

一次（本フレームワーク）

• Changing the game: Using agentic AI to secure infrastructure code

系譜

• Cloud CISO Perspectives: How Google Cloud Security uses AI internally
• Getting started with Mantis, our open-source bug finding-and-fixing harness

関連ツール公式

• google/mantis
• README.md
• README_AGENTS.md
• schema.json
• mantis-threat-model/SKILL.md
• mantis-structural-index/SKILL.md
• mantis-advise/SKILL.md
• mantis-critic/SKILL.md
• reference/scripts/launch.py
• skills.sh google/mantis

プロバイダ / 製品

• Vulnerability management with AI
• Now in preview: Find and fix software vulnerabilities with CodeMender