Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
Use when you want deterministic evidence for a review - which already-installed scanners may be run against the checkout, their exact read-only invocations, how to triage their output, and what must never be run or installed
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Scanners are fast, deterministic and noisy. They find candidates you might skim past; they also report hundreds of things this review excludes. They never decide the verdict — every hit goes through the false-positive gate like any other candidate, and a clean scan is not a clean review.
Core principle: use what is already installed, in a mode that only reads, on the files this diff changed. Never install anything; never run anything from the project.
get_pipeline_status — a secret scan, SAST or dependency-audit job may already have reported on this exact commit; its output is in the job result.list_component_checks — which security checks exist for the component and whether CI gates on them.Do not re-run what CI already ran on this commit; triage its output instead. When semgrep, osv-scanner, github-security or snyk tools are in your tool list, those MCP servers are connected — security-mcp-scanners covers them; the CLIs below are the fallback.
command -v semgrep gitleaks trufflehog osv-scanner govulncheck gosec bandit pip-audit zizmor checkov trivy. Missing → skip it; it is a coverage note, not a reason to fail the review.pip install, pipx run, uvx, npx, npm i -g, go install, go run …@latest, brew install, docker run of a scanner image.npm install/ci, no build, no go generate, no make, no CodeQL database creation for compiled languages (it runs the build) — read CI's CodeQL results instead.--fix, --autofix, npm audit fix, osv-scanner fix, no scanner baseline written into the repo.out=/tmp/tt-<task key>/scan; mkdir -p "$out". Pass timeout_seconds for slow tools..semgrepignore, .gitleaks.toml, .gitleaksignore, nosec/# nosemgrep comment or .trivyignore added or widened in this diff is itself something to review.base=$(git merge-base HEAD origin/HEAD 2>/dev/null || git merge-base HEAD origin/main)
changed=$(git diff --name-only --diff-filter=AM "$base")
| Tool | Purpose | Read-only invocation | Caveat |
|---|---|---|---|
| semgrep | SAST, many languages | semgrep scan --metrics=off --config p/default --json -o "$out/semgrep.json" $changed | --config auto needs metrics — don't; avoid --baseline-commit, it manipulates the git working tree; registry configs need network, a repo .semgrep.yml works offline |
| gitleaks | secrets in the diff's commits | gitleaks git --log-opts="$base..HEAD" --redact --no-banner --report-format json --report-path "$out/gitleaks.json" . | older v8: gitleaks detect --log-opts=…; working tree only: gitleaks dir <path> / detect --no-git --source <path> |
| trufflehog | secrets, broader detectors | trufflehog git file://. --since-commit "$base" --no-update --no-verification --json | verification calls the provider with the found credential — leave that to CI; --no-update stops self-update |
| osv-scanner | advisories for lockfiles | v2: osv-scanner scan source -L <lockfile> --format json; v1: osv-scanner --lockfile=<lockfile> --format json | reports MAL- malicious packages too; never fix |
| govulncheck | Go advisories with reachability | GOTOOLCHAIN=local GOFLAGS=-mod=readonly govulncheck -json ./... | loads packages via go list (may fill the module cache, never runs project code); GOTOOLCHAIN=local stops a toolchain line fetching another Go |
| gosec | Go SAST | gosec -quiet -fmt=json -out="$out/gosec.json" ./... | high noise on G104/G115 — triage hard |
| bandit | Python SAST | bandit -q -f json -o "$out/bandit.json" <changed .py files> | flags every subprocess import; only trace hits on + lines |
| npm / pnpm audit | JS advisories | npm audit --package-lock-only --json · pnpm audit --json | reads the lockfile only; no install, no scripts |
| pip-audit | Python advisories | pip-audit --no-deps --disable-pip -r requirements.txt -f json | without both flags it builds a venv and installs the requirements, running their setup code; needs pinned requirements |
| zizmor | GitHub Actions | zizmor --offline --format json .github/workflows/ | --offline skips GitHub API audits |
| checkov | Terraform, k8s, Dockerfiles | checkov -d <dir> --compact --quiet -o json | never enable external module download |
| trivy | IaC misconfig, secrets, lockfiles | trivy config <dir> · trivy fs --scanners vuln,secret,misconfig <dir> | check trivy --version first: v0.69.4 is the malicious release from the March 2026 compromise (CVE-2026-33634) — do not run it, and say so in your run summary |
For each hit:
+ lines, or on unchanged lines the diff newly routes input into. Drop the rest — pre-existing findings are not this review.pip-audit -r without --no-deps --disable-pip, or npx some-scanner "just this once".Semgrep CLI · gitleaks · TruffleHog · osv-scanner · govulncheck · pip-audit · zizmor · Checkov · Trivy · CVE-2026-33634
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping
日本語の概要は準備中です。原文の説明を表示しています。
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
日本語の概要は準備中です。原文の説明を表示しています。
Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task
日本語の概要は準備中です。原文の説明を表示しています。
How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.
日本語の概要は準備中です。原文の説明を表示しています。
Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation
日本語の概要は準備中です。原文の説明を表示しています。