Security Testing

Security testing here means turning an already grounded security concern into the smallest evidence that proves the risk is covered.

Output discipline (mandatory)

Inherits the global discipline from using-sumo-qa: grounded risks only, no internal taxonomy labels, no vulnerability checklist or vendor/tool-name dump, and no external setup without confirmation.

Output economy (mandatory)

Spend output on the brief fields below.

The Iron Law

Grounded risk first, tool second. Do not recommend a scanner, external skill, live probe, or dependency install until the concrete failure mode, source anchor, and native evidence fit are checked.

When to Use

Use after sumo-qa-deciding-approach routes an explicit security-testing request here, or after another sumo-qa workflow has named a material security gap that needs more than a normal regression test / review line. Low-evidence prompt: no brief; ask for the scope, stop.

Checklist

1. Confirm the source anchor: file, flow, config, dependency, data path, or explicit user-stated scope. If none exists, note no anchor, ask one scope question; stop. No hypothetical risks/actions.
2. If this skill's context arrived in one bundle call, use its security standards, rules and techniques. Otherwise (another skill's handoff, the Skill tool, the symlinked skill) load sumo_qa_load_standards(classification="security_change"), sumo_qa_load_rules(classification="security_change"), and sumo_qa_load_techniques(). Use repo-map or file reads when available to verify the path.
3. State the grounded failure mode in concrete terms: who/what can do something they should not, which token/secret/input/config can fail, or which security control can regress. For account-recovery or lookup flows, include account enumeration when the request path can reveal user existence.
4. Choose the smallest evidence type that fits: native test, review, static check, dynamic check, config check, dependency check, fuzz/property check, or external tool/skill.
5. Name the first concrete action: test to add, file/config to inspect, command or safe local check to run, or external skill to request.
6. Keep safe local work apart from live or invasive testing. Confirm before dependency installs, scanner setup, external skill execution, or live probing.
7. Return the compact brief below, with residual risk for any missing tooling, credentials, environment, or live scope.

Process Flow

Follow the Checklist in order.

Security QA Brief Shape

• Grounded risk: the specific security failure mode, limited to available evidence.
• Source anchor: file, flow, config, dependency, or user-stated scope.
• Evidence choice: one of test / review / static check / dynamic check / config check / dependency check / fuzz-property check / external tool-skill.
• First action: what to add, run, inspect, or request next.
• Residual risk: what remains unproven because environment, credentials, tooling, or live target scope is absent.

Evidence-Fit Guide

Red Flags

Examples

Good

User: "Security-test the new password reset flow."

Brief: grounded risk is reset token replay or expiry bypass in the password-reset flow, plus account enumeration if the request endpoint can reveal whether an email exists. Source anchor is the reset-token issue/consume and request paths. Evidence choice is native API tests plus state transition testing: issued -> consumed -> expired. First action: add tests that expired, already-used, tampered, and replayed tokens are rejected, and that known-email vs unknown-email reset requests return same status/body. Residual risk: inbox-link delivery and any live-rate-limit behaviour remain unproven without a runnable environment.

Good

Existing review found: "new /documents/{id}/raw endpoint has no owner check."

Brief: grounded risk is any authenticated user reading another user's document. Source anchor is the endpoint and missing guard. Evidence choice is native integration/API negative-path test before any external tooling. First action: add a test where user B requests user A's document and gets Forbidden. Residual risk: broader authorization matrix remains unproven unless roles/tenant rules are supplied.

Bad

"Run OWASP Top 10, ZAP, Burp, Snyk, and a SAST scanner." This dumps categories and vendor/tool names without anchor, stack fit, first action, or setup confirmation.

No anchor

User: "Pen-test our platform." Good: "No source anchor given; which flow, file, or concern should I test?" Bad: leading with a verdict ("Insufficient scope.") instead. With an anchor, never claim one is missing.

Next skill in the chain

If native evidence fits, route to the relevant implementation/review skill with the concrete action. If no native sumo-qa path can cover the grounded risk, route to sumo-qa-suggesting-external-skill with entry_kind: "qa" and the named security surface.