secrets-exposure-review

Secrets Exposure Review (Chinese Version)

When to Use

You need to design security testing or review preparation around sensitive information locations, flows, log exposure, configuration boundaries, and rotation evidence.
You need to deliver a reviewable initial version when materials are incomplete, and clearly state assumptions, gaps, and Human decisions.
You need to distinguish static security evidence, planned validation, and executed actions.

The default output is Markdown, organized by security risk, evidence, and priority.
When the user requests tables, CSV, JSON, or ticket formats, preserve the same finding fields and evidence status.
Before output enters an automated process, first confirm the schema, enum values, and required fields.

First read prompts/secrets-exposure-review.md and execute the input audit, coverage checklist, and output contract.
Extract scope, environment, version, roles, data, dependencies, limitations, and available evidence.
Build reviewable scenarios around sensitive information locations, flows, log exposure, configuration boundaries, and rotation evidence, distinguishing known facts, inferences, and candidate validations.
For each item, record impact, priority, responsible role, closure conditions, and validation method.
When information is insufficient, deliver a limited initial version; do not write risk assumptions as vulnerability confirmation or security pass.

Each execution must read prompts/secrets-exposure-review.md.
When evaluation is needed, read evals/eval.yaml and the matching evals/cases/.
Only read references/, examples/, scripts/, or output-formats.md when the directory exists and the task requires it.

Based on authorized materials, inventory code, configuration, CI, logs, artifacts, and historical locations, recording candidate paths/line numbers, categories, and redacted fingerprints; do not copy values or read real credentials yourself.
Deliver a redacted location and lifecycle risk table; risk levels are based on exposure/usage evidence, and candidate validity remains unknown.
When forming domain candidates, you must read and follow the domain operations and determination process of prompts/secrets-exposure-review.md , preserving legitimate comparisons, evidence gaps, and validation actions item by item.

Only analyze sensitive information locations, flows, log exposure, configuration boundaries, and rotation evidence; do not log in to systems, call real APIs, or read credentials.
Do not fabricate vulnerabilities, successful attacks, completed fixes, scan coverage, or security pass conclusions.
When evidence is missing, mark as pending confirmation, blocked, or unassessed, and provide an isolated validation method.
Risk acceptance, exception authorization, and release decisions must be left to Human.

Completed the known, missing, conflicting, stale, out_of_scope, and assumptions audit.
Covered secrets exposure, trigger conditions, expected focus points, and evidence status.
Separated facts, inferences, recommendations, information gaps, and Human decisions.
Did not write static findings or dry-runs as real attacks, absence of vulnerabilities, or release approval.

Treating a generalized security review or API contract check as a complete substitute for a secrets exposure review.
List only attack names, without writing the scope of applicability, evidence, expected results, and closure conditions.
When information is insufficient, directly determine that it is safe, or read real credentials for the sake of completeness.

Start from high-impact, hard-to-detect, privilege-sensitive, or data-sensitive paths.
Use sanitized materials, least privilege, isolated environments, and rollback-capable validation recommendations.
Enable another engineer to review each security conclusion based on its source and boundaries.