Review secret handling without opening values

Map exposure paths and the process for invalidating old credentials after replacement.

When to use this guide

Use this when public artifacts or support attachments coexist with credentials used by several services.

Record secret-handling paths and the verified replacement and invalidation scope without storing values.

1 / 3
Start with non-secret identifiers
Read purpose, owner, environment, and consumers from the existing inventory without collecting values.
Evidence to retain
Non-secret identifiers mapped to their consumers.
2 / 3
Trace distributed material
Review checks on build output and diagnostic attachment generation as well as the repository.
Evidence to retain
Artifact identities, checked scope, and unexamined paths.
3 / 3
Separate replacement from invalidation
Review consumer updates and rejection of old keys separately using response history or authorized test records.
Evidence to retain
The consumers updated and the systems where old-key invalidation was verified.

A team publishes build artifacts and sends diagnostic attachments to support.

Review the file inventory and generation paths without opening secret values.

Replacement issuance, consumer updates, and old-key invalidation are tracked separately.

Compare non-secret credential inventory identifiers with the response history.

Public T-Connect source code contained a data-server access key. Toyota disclosed potential exposure; third-party access was not confirmed.

Credentials stolen in the earlier Okta incident were missed during rotation. They enabled access to self-hosted Atlassian systems and source code.

Selected examples. Each record retains its evidence status, unknowns, and sources.

Secret: A value granting access, such as an API key or authentication token. Review records should identify it without containing the value.; Can you identify its purpose, target, and owner without opening its value?; Open the related inspection rule →
Revocation: Making an old credential or session unusable at the accepting system. Verify this separately from issuing a replacement.; What evidence shows that the old credential is rejected after replacement?; Open the related inspection rule →
Asset: A service, store, or administrative identity included in the review. Record its owner and purpose as well as its name.; Which environment and owner does this asset belong to?; Open the related inspection rule →

Do not copy discovered secret values into notes, prompts, or public reports.
Replacement or revocation of active credentials is outside this read-only review.

A working new credential and a rejected old credential are separate observations.

References and review dates

OWASP: Secrets Management Cheat Sheet ↗
2.7 Secret Lifecycle; 2.7.3 Revocation
OWASP: CI/CD Security Cheat Sheet ↗
Pipeline and Execution Environment; Least Privilege; Managing Third-Party Code

Learning review 2026-11-12 · Catalog review 2026-11-09

Share these two rules and examples without expanding the scope. Checks without evidence remain unverified.

Check what was actually deployed
Connect the running version with the external code executed on its way to deployment.
Follow login and the session after it
Review MFA coverage separately from the mechanisms that stop an authenticated session.
Review exposure and data that remains
Review storage exposure together with the handling of retired environments and data copies.
Keep user and organization data separated
Connect resource authorization with the boundaries controlling reuse of generated responses.
Trace input into queries and file processing
Follow inputs from entry points to SQL construction and file storage or processing.
Separate the blast radius from recovery
Connect reachable resources with containment and restoration records.
Set AI boundaries before delegating a task
Review destinations, action authorization, and traceable records at the execution boundary.