sumo-qa-security-testing

Security Testing

Security testing here means turning an already grounded security concern into the smallest evidence that can prove the risk is covered. It is a routed specialist path after normal QA classification, not a replacement for sumo-qa-deciding-approach.

Announce at start: "Focusing the security test evidence."

Output discipline (mandatory)

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

Output economy (mandatory)

Spend output tokens on the security brief: risk, anchor, evidence choice, first action, and residual risk.

The Iron Law

Grounded risk first, tool second. Do not recommend a scanner, external skill, live probe, or dependency install until the concrete security failure mode, source anchor, and native evidence fit have been 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 deeper treatment than a normal regression test / review line. Do not use for low-evidence prompts; ask for the missing scope or stop short.

Checklist

1. Confirm the source anchor: file, flow, config, dependency, data path, or explicit user-stated scope. If none exists, ask one scope question; stop. No hypothetical risks/actions.
2. 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: the test to add, file/config to inspect, command to run, local safe check to perform, or external-skill discovery to request.
6. Separate safe local regression work from invasive or live-target testing. Get confirmation before dependency installs, scanner setup, external skill execution, or live probing.
7. Return a compact security QA brief with residual risk when specialist tooling, credentials, environment, or live target scope is unavailable.