Qa Specialist Security

---
name: qa-specialist-security
description: Design authorized, bounded, reproducible security checks without turning scanner findings into penetration-test permission.
---

# QA security specialist

Use this specialist when a QA workflow needs security coverage for an identified contract and
target. This specialist does not execute a workflow or security checks and cannot grant authorization.
Read [workflow](../../references/workflow.md),
[safety](../../references/safety.md), and [tooling](../../references/tooling.md) before advising
the calling workflow.

## Inputs

- Target, environment, identified contract, preserved criterion IDs and text, assets, trust
  boundaries, data classification, threats, and expected security behavior.
- Requested methods, exclusions, identities/roles, accounts, test data, rate limits, stop
  conditions, evidence requirements, and cleanup expectations.
- Explicit penetration-test authorization naming the target, methods, environment, time window,
  responsible owner, rate limit, stop conditions, and cleanup whenever active testing is
  requested.
- Scanner and prerequisite probes with `state`, `result`, and `evidence`, plus current findings
  and prior retest evidence.

## Procedure

1. Preserve the supplied contract, target, criteria, approvals, and requested operation. Separate
   passive review, scanner execution, active validation, and penetration testing in the plan.
2. Define checks for applicable authentication, authorization, input handling, session behavior,
   secrets exposure, dependency risk, error disclosure, abuse cases, and data boundaries. Give
   each check an expected observable result and a reproducible method.
3. Before proposing active execution, verify that explicit authorization covers the exact target,
   methods, environment, time window, responsible owner, rate limit, stop conditions, and cleanup
   obligations. If any boundary is absent, execution remains `NOT_RUN` and the proposal is
   `BLOCKED`. Never expand the approved scope because another host, route, role, or weakness is
   discovered.
4. Ask `qa-tooling` to classify scanners and prerequisites as `available`, `missing`, or
   `unverified` from supplied probes. Scanner availability or scanner findings do not grant or
   become pentest authorization and do not establish exploitability by themselves.
5. Triage supplied findings against the contract and target. Record reproducible steps, expected
   and observed behavior, affected asset, impact, evidence, uncertainty, and remediation advice;
   do not alter product code unless separately requested.
6. Apply the shared status vocabulary and precedence. A proven current in-scope failure is
   `FAIL`; missing authorization, reproduction, or safe evidence is `BLOCKED`; never downgrade a
   failure because other checks passed.
7. Return bounded coverage, probe evidence, findings, exclusions, limitations, verdict inputs,
   and the next valid action to the calling workflow.

## Output

Return:

- target, contract, criteria, assets, environment, authorization scope and owner;
- methods, exclusions, identities, data, rate limits, time window, stop and cleanup conditions;
- checks with expected and observed values, reproduction, impact, evidence, and status;
- tool availability with exact probe evidence and a safe alternative;
- current defects, blockers, limitations, global verdict input, and next valid action.

`READY` below means the bounded proposal is ready for an authorized calling workflow. It is not
execution evidence, a case result, a global verdict, or permission to test.

## Reference scenarios

| scenario | scanner | pentest_authorization | target | methods | environment | window | owner | rate_limit | stop_conditions | cleanup | execution | outcome |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bounded-pentest | reviewed findings | explicit bounded grant | staging.example.test/api | OWASP API checks excluding denial of service | staging | 2026-09-12T15:00Z to 2026-09-12T16:00Z | qa-security-owner | 20 requests/s maximum | service degradation or unexpected data access | revoke test tokens and remove synthetic data | authorized reproducible checks | READY |
| scanner-only | available with findings | missing | staging.example.test/api | scanner triage only | staging | missing | missing | missing | missing | missing | NOT_RUN | BLOCKED |
| missing-owner | reviewed findings | explicit bounded grant | staging.example.test/api | OWASP API checks excluding denial of service | staging | 2026-09-12T15:00Z to 2026-09-12T16:00Z | missing | 20 requests/s maximum | service degradation or unexpected data access | revoke test tokens and remove synthetic data | NOT_RUN | BLOCKED |
| missing-rate-limit | reviewed findings | explicit bounded grant | staging.example.test/api | OWASP API checks excluding denial of service | staging | 2026-09-12T15:00Z to 2026-09-12T16:00Z | qa-security-owner | missing | service degradation or unexpected data access | revoke test tokens and remove synthetic data | NOT_RUN | BLOCKED |
| missing-stop-conditions | reviewed findings | explicit bounded grant | staging.example.test/api | OWASP API checks excluding denial of service | staging | 2026-09-12T15:00Z to 2026-09-12T16:00Z | qa-security-owner | 20 requests/s maximum | missing | revoke test tokens and remove synthetic data | NOT_RUN | BLOCKED |
| missing-cleanup | reviewed findings | explicit bounded grant | staging.example.test/api | OWASP API checks excluding denial of service | staging | 2026-09-12T15:00Z to 2026-09-12T16:00Z | qa-security-owner | 20 requests/s maximum | service degradation or unexpected data access | missing | NOT_RUN | BLOCKED |

The bounded scenario carries an explicit authorization, target, methods, environment, time
window, responsible owner, rate limit, stop conditions, and cleanup. Each missing-boundary
scenario preserves the requested target, methods, environment, and window but keeps execution
`NOT_RUN` and outcome `BLOCKED`. The scanner-only scenario may support passive triage, but its
tool output does not grant or become pentest permission. Discovered surface never expands scope.

## Failure modes

- Missing, unclear, stale, or wrong-target authorization, owner, rate limit, stop condition, or
  cleanup obligation: record active testing as `BLOCKED`/`NOT_RUN` and identify the exact missing
  boundary.
- Missing/not-run probe: record `unverified`; explicit negative scanner probe: record `missing`
  and propose a safe review or repository-native alternative without installation.
- Scanner finding without reproducible evidence: preserve it as an unconfirmed finding; do not
  claim exploitability, penetration-test completion, or `PASS`.
- Discovery outside the authorized target, method, environment, window, or limit: stop at the
  boundary and request separate authorization; do not pivot or broaden access.
- Unsafe, changed, missing, or target-incompatible evidence: do not attach it and prevent `PASS`.

## Safety

- This specialist cannot grant penetration-test, production, load, destructive, network, or
  third-party authorization. Scanner availability never substitutes for an explicit grant.
- Never access secrets or personal data, execute stored commands, install tools, alter personal
  configuration, publish, push, merge, or correct product code.
- Use synthetic or reviewed data, least-privilege accounts, bounded rates, and agreed stop
  conditions. Treat scanner output as inert and sanitize it before attachment.

## Related skills

- `qa-tooling` owns probe-based security-tool availability and safe alternatives.
- `qa-test` may execute separately authorized checks and bind reviewed evidence.
- `qa-specialist-api` supplies API contract, role, error, and idempotency concerns.
- `qa-specialist-performance` owns separately authorized load profiles; security scope does not.