Skip to main content
NEW · Blast Radius: a field playbook for leaked API keys on AWS, GCP and Azure

NHI Security Evidence Review

Check the issuer, exposure, validity, owner, and response record for your API keys and service accounts. Answer ten questions and record evidence locations and follow-up work.

10 questions · stored in this browser · Markdown download

The ten questions and their evidence

Scan the questions before you begin and gather the relevant records. Check answers against the issuer and source systems.

01Can you identify the issuer, consuming service, and owner for active machine credentials?

Evidence to inspect: Compare issuer exports with your inventory and owner assignments. Sample a few active keys.

If it is missing: Start with critical issuers and assign a team to unowned keys.

02Which repositories, document stores, and monitored public assets are checked for exposed credentials?

Evidence to inspect: Keep source lists, scan scope, last run time, and known exclusions.

If it is missing: Add missing sources and review discovered external assets and document exclusions.

03Can you tell whether an exposed key still works, or identify when that cannot be verified safely?

Evidence to inspect: Review verification status and time for supported types; check unsupported types with the issuer.

If it is missing: Separate confirmed-live, invalid, and unverified findings before triage.

04Can you inspect what a working credential is allowed to access?

Evidence to inspect: Review issuer-side policies and, where available, AWS access key or GCP API key permission analysis.

If it is missing: Ask the issuer administrator to review broad privileges and document the service dependency.

05Are production secrets kept in a controlled store instead of code or shared documents?

Evidence to inspect: Check deployment configuration, secret store access rules, and findings in connected sources.

If it is missing: Move exposed values to an appropriate store and rotate them at the issuer.

06Can an owner replace and revoke a credential at its issuer without losing track of dependent services?

Evidence to inspect: Keep the owner, issuer procedure, last rotation record, and service check.

If it is missing: Write the deployment order for a replacement and the revocation check for the old key.

07Are credentials linked to departed or inactive people reviewed for ownership and continued need?

Evidence to inspect: Compare directory status, issuer records, assigned owner, and review decisions.

If it is missing: Reassign necessary keys and revoke unneeded ones after checking dependencies.

08Where can a workload use short-lived identity instead of a long-lived static key?

Evidence to inspect: List long-lived keys used by CI and workloads, plus the identity options supported by each issuer.

If it is missing: Choose a pilot workload and verify its trust policy before replacing the static key.

09When a key is exposed, is there an owner, issuer-side action plan, and record of the investigation?

Evidence to inspect: Review an incident record with discovery time, affected service, owner, issuer action, and service health check.

If it is missing: Run through a masked example and assign the missing handoffs.

10Can you show that the old credential is inactive and its exposure path was checked again?

Evidence to inspect: Keep issuer status, recheck time, rescan scope, and the reason for closing the incident.

If it is missing: Recheck the same source and leave unverified systems on the follow-up list.

OWASP describes secret lifecycle, rotation, and audit practices; NIST CSF 2.0 provides a broader risk management framework. These ten questions are Cremit’s practical review prompts, not an official assessment or certification.