What it means
Automation secret management keeps passwords, tokens, keys, and certificates out of code and logs while delivering them only to authorized jobs at execution time.
Why it matters
Secrets embedded in repositories, images, environment output, or pipeline variables are easy to copy and difficult to revoke completely.
Practical focus
- Define the system boundary, accountable owner, approved purpose, material risks, and decision authority for Automation Secret Management
- Use a managed secret store, short-lived credentials, workload identity, access policies, rotation, masking, scanning, and emergency revocation.
- Collect and protect this evidence: secret inventories, access policies, retrieval logs, rotation history, scanner results, revocation tests, and incident records.
- Exercise this failure scenario as a planned test: a build prints an API token into logs that are retained broadly and copied to a support ticket.
Common mistakes
- Using the label Automation Secret Management without defining the exact systems, data, people, decisions, and time period in scope
- Treating a policy statement or tool demonstration as proof that Automation Secret Management operates consistently in production
- Failing to retain secret inventories, access policies, retrieval logs, rotation history, scanner results, revocation tests, and incident records in a form that lets an independent reviewer reconstruct decisions and changes
- Testing only the normal path and never rehearsing what happens when a build prints an API token into logs that are retained broadly and copied to a support ticket.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: