Source note: This article is based on the Awesome QA Skills Secrets-Exposure Review prompt and Skill. The Best Practices section gathers the source’s evidence, authorization, and closure requirements into a checklist; project policy remains authoritative.
A secret can leak without ever appearing in source control. Configuration snapshots, debug logs, crash reports, build output, and copied environment files all create different exposure paths.
Why this Skill is needed
The Secrets-Exposure Review Skill builds an evidence-bounded view of where secrets live, how they flow, what logs expose, which configuration boundaries matter, and whether rotation evidence exists.
What the Skill does
The review should make the next safe check obvious without increasing exposure.
Use this Skill to review a service or pipeline with redacted material. It identifies exposure concerns and validation actions; it does not log in, call real APIs, read credentials, or declare a system secure.
A good finding names the secret class, location or flow, exposure trigger, evidence state, impact, priority, owner, close condition, and isolated validation method.
Use it when a credential moves from local development to CI, a logging change is proposed, a security incident needs a bounded review, or rotation readiness is unclear.
What it does not do
The Secrets-Exposure Review Skill can organize evidence and next actions for a suspected credential-exposure path. It does not replace:
- Confirmation of rules, scope, and risk by the accountable domain owner.
- A real environment, account, dataset, log, or run record; static analysis does not become runtime evidence by itself.
- Authorization for release, compliance, production actions, or residual-risk acceptance.
- A Human decision when supplied sources conflict.
What it checks
The value of this Skill is not another keyword list. It connects each focus area to an observable input, a judgment, and a way to close the loop. Start with a small matrix based on the source Skill’s output contract:
| Focus | Question before analysis | Handoff output |
|---|---|---|
| Candidate exposure path | Where a secret may be stored, flow, or be emitted | Redacted source and evidence state |
| Flow finding | How the secret moves through configuration or runtime | Trigger and boundary |
| Rotation readiness | What proves safe replacement and rollback | Runbook, owner, or gap |
| Validation action | Safe isolated check that reduces uncertainty | No real credential access |
If a row has only a conventional expectation and no source or validation method, keep it open instead of turning it into a pass.
Audit inputs before you start
Before reviewing a suspected exposure path, classify the input into six evidence states. A gap is not automatically a failure, but it must not disappear inside the conclusion.
| State | Meaning | How this Skill should handle it |
|---|---|---|
| known | Directly supported by the supplied material | Keep the source, version, and time with the judgment |
| missing | Needed for this pass but not supplied | Name the smallest evidence action and limit the conclusion |
| conflicting | Sources disagree | Show both sources and route the conflict to an owner |
| stale | Present but outside the relevant version or time window | Mark freshness; old evidence is not current proof |
| out_of_scope | Related but excluded from this pass | Keep the boundary explicit |
| assumptions | Temporarily adopted to continue analysis | State how and when the assumption will be checked |
Keep the input version, scope, environment, evidence locations, and accountable owner together. Without a run record, deliver analysis, design, or a validation plan—not an execution pass.
From problem to structured Finding
Connect the source, scope, evidence state, analysis, owner, action, close condition, and validation before writing the conclusion. The case below keeps this Skill’s identifier and domain context.
Keep the decision layers separate
For a suspected Authorization header in CI logs, do not compress four different judgments into “recommended to pass”:
| Layer | How to write it | Application here |
|---|---|---|
| Fact | What the supplied material directly shows | Cite the source, version, input, or run record for the focus |
| Evidence-backed Inference | What several facts support together | Show the inference chain and retain uncertainty |
| Recommendation | The smallest next action | Name the evidence, review, execution, or regression path |
| Human Decision | What an accountable person must decide | Leave scope, risk acceptance, resources, and release meaning to the owner |
A complete case
This case follows Input, Analysis, Finding, Decision, and Validation. When material is incomplete, keep missing, conflicting, or assumptions visible instead of turning them into a pass.
Input
| Material | What to provide | What to do when it is missing |
|---|---|---|
| Scope and version | Service, repository, pipeline, environment, and change revision | Mark unknown boundaries |
| Redacted material | Config templates, log samples, deployment manifests, and secret references | Never attach real values |
| Secret flow | Creation, injection, use, logging, error handling, and revocation path | Separate facts from assumptions |
| Rotation evidence | Owner, cadence, dependency impact, dry-run, and rollback material | Keep readiness unassessed without proof |
Use a request like this:
Use the secrets-exposure-review Skill.
Task: Review whether a payment service can expose API credentials through CI logs, exception traces, or deployment configuration during a logging change.
Inputs: [redacted manifests, log samples, pipeline steps, secret references, rotation runbook]
Scope: [staging and CI, no real credentials]
Constraints: [do not call APIs or read secret values]
Separate known exposure evidence, assumptions, candidate validation, impact, owner, close condition, and security decision boundary.Analysis
Use the input, matrix, and evidence state to form the judgment before writing the Finding; keep missing material as a gap.
Finding
Focused example: Review a logging change without copying credentials
A new exception logger records request headers in CI failure output. The Skill should flag the possible authorization-header exposure, ask whether headers are masked before persistence, and propose a synthetic-token test in an isolated pipeline. It should not ask for a production token or call the payment provider.
Record the candidate as SER-01. The table follows this hypothetical case; credential validity, log retention, and impact still need evidence.
| Field | Example record |
|---|---|
| Object and source | Authorization request header in CI failure output; record the pipeline revision, log location, and time without copying the header value |
| Candidate class and fingerprint | Credential candidate; retain only a redaction marker or safe fingerprint. A pattern match does not prove that a credential is real or valid |
| Trigger and exposure scope | An exception path writes request headers to output; log access, retention, and copying are still unknown |
| Evidence state | The scenario says the logger writes request headers; the value, use, and access scope remain missing / unassessed |
| Next action | Confirm and contain the log exposure first; the credential owner decides whether revocation or rotation is needed, then checks old-value invalidation and historical copies |
| Safe validation | Use a synthetic token in an isolated pipeline to check masking and failure output; retain the config revision, raw test output, and cleanup record without touching real credentials |
Deleting log text does not invalidate a credential or prove that exposure is closed. Revocation, rotation, and handling of historical copies remain decisions for the credential owner based on exposure evidence.
The review classifies supplied redacted evidence and proposes safe validation. It cannot prove absence of secrets, exploit success, remediation completion, or a security pass.
Example finding: turn one problem into a handoff
The field example below shows the recording pattern; it is not an execution result.
If the supplied material cannot establish whether CI failure logs retain the Authorization header, write the finding like this. It does not invent the missing rule or turn missing evidence into a failure.
| Field | Example wording |
|---|---|
| Source and scope | Record the related requirement, pipeline revision, CI environment, and log-retention rule |
| Finding | The material does not establish whether the header is masked before logging or who can view the logs |
| Evidence state | missing / assumptions; use conflicting when sources disagree |
| Impact and priority | Name the affected user, journey, or delivery decision without inflating severity |
| Owner and Human decision | Ask the product, engineering, security, or test owner to confirm the rule and trade-off |
| Action and close condition | Add the smallest missing evidence; close only when source, judgment, and owner can be reviewed |
| Validation | Name one repeatable check, query, or run and retain the raw artifact |
The point is to let the next person walk from the finding back to the source and run an action that can change the decision.
Decision
The accountable owner confirms the decision question and risk trade-off; the Skill does not make that choice.
Validation
Before closing the finding, run the stated validation and retain the raw artifact. Without an execution record, the status remains unverified.
How a Finding enters the next stage
Handoff output
| Output field | Why it exists | Example status |
|---|---|---|
| Candidate exposure path | Where a secret may be stored, flow, or be emitted | Redacted source and evidence state |
| Flow finding | How the secret moves through configuration or runtime | Trigger and boundary |
| Rotation readiness | What proves safe replacement and rollback | Runbook, owner, or gap |
| Validation action | Safe isolated check that reduces uncertainty | No real credential access |
Every conclusion should point to a source, evidence state, and next action. If evidence is missing, use pending, blocked, unassessed, or NOT_SCORED instead of filling the gap with confidence.
Next-stage route
At minimum, hand off the source, evidence state, owner, close condition, and validation action; the next-stage conclusion remains bounded by the evidence state.
How to prepare better input
Provide redacted config, log samples, pipeline steps, secret reference names, environment boundaries, rotation owner, and the intended validation environment. Keep real values outside the prompt and repository.
A useful handoff includes input versions, scope, time window, evidence index, assumptions, Human decision boundary, and the smallest validation action.
Working with other Skills
- Security Requirement Review: https://inaodeng.com/en/qaskills/security-requirement-review/ — checks whether protection objectives are testable.
- Session-Security Testing: https://inaodeng.com/en/qaskills/session-security-testing/ — adds session-token lifecycle and revocation boundaries when credentials are session-bound.
- Observability Design Review: https://inaodeng.com/en/qaskills/observability-design-review/ — checks whether logging and traces preserve safe boundaries.
Best practices
- Start with exposure paths that could have high impact or be hard to detect, especially those involving sensitive data or elevated permissions. Set the service, environment, version, and time window first.
- Use only redacted material or synthetic credentials and follow least privilege. For candidate validation, use an isolated environment and reversible test data; the review does not log in to systems, call real APIs, or read real credentials.
- Record direct facts, evidence-based inferences, recommendations, and Human decisions separately. Mark missing, conflicting, stale, and assumed inputs.
- Keep a reviewable source, exposure trigger, impact, owner, close condition, and safe validation method for each finding. Do not call a check passed without run evidence.
- Before handoff, check that the artifacts contain no real credentials. Name who retains and removes evidence and who owns any rotation decision.
Common traps
- Searching for literal values and concluding the system is safe when derived or logged forms remain.
- Treating a rotation document as proof that every consumer can reload the new secret.
- Requesting real credentials to make the review complete.
Install and invoke
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/secrets-exposure-reviewInstallation and troubleshooting:
- README: https://github.com/naodeng/awesome-qa-skills/blob/main/README_EN.md
- FAQ: https://github.com/naodeng/awesome-qa-skills/blob/main/FAQ_EN.md
- Installation guide: https://github.com/naodeng/awesome-qa-skills/blob/main/scripts/INSTALL_SKILLS_EN.md
Use the secrets-exposure-review Skill.
Include objective, scope, versions, evidence paths, constraints, and decision boundary.
Audit inputs first, preserve evidence states, and finish with owner, close condition, and validation method.FAQ
Can I paste a real token for a more accurate review?
No. Use redacted values or synthetic tokens. Real credentials increase exposure and are outside this Skill’s contract.
Does a clean static scan prove rotation is ready?
No. Rotation also needs consumer reload, revocation, rollback, and evidence from a safe validation path.
The Skill is most useful when attached to one redacted project artifact and kept with its source evidence. Start narrow, validate the uncertain part, and expand only when evidence supports it.
References
Static plans, file presence, and dry runs keep their evidence state. They do not become runtime proof, an all-passed claim, or release approval.
- Secrets-Exposure Review prompt (execution contract): https://github.com/naodeng/awesome-qa-skills/blob/main/skills/en/testing-types/secrets-exposure-review/prompts/secrets-exposure-review.md
- Secrets-Exposure Review Skill: https://github.com/naodeng/awesome-qa-skills/blob/main/skills/en/testing-types/secrets-exposure-review/SKILL.md
- Secrets-Exposure Review Skill source: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/secrets-exposure-review
- Secrets-Exposure Review details: https://inaodeng.com/en/qaskills/secrets-exposure-review/
- Awesome QA Skills on GitHub: https://github.com/naodeng/awesome-qa-skills