Legacy Haven University

Hardcoded secrets turn source code, images, and pipelines into credential stores. CompTIA SecurityX (CAS-005) treats that as an identity problem and as an attack-surface problem. Domain 3.1 names secrets management as tokens, certificates, passwords, and keys, plus rotation and deletion. Domain 4.2 names embedded secrets as a vulnerability and names secrets management with key rotation as a mitigation.

This article maps those official bullets. It uses HashiCorp Vault only as the named teaching example in the Legacy Haven schedule. The exam document does not list that product.

What the exam calls a secret

A secret is a value that proves identity or unlocks data. CAS-005 3.1 lists four classes:

• Tokens. Short-lived proof of access. An API bearer token is a common form.
• Certificates. Public-key credentials bound to a subject. The private key is the secret.
• Passwords. Shared secrets for people or services.
• Keys. Cryptographic material used to encrypt, sign, or unwrap other secrets.

Rotation replaces a live secret with a new one on a schedule or after suspected exposure.
Deletion removes the old value so it cannot be reused.

If you cannot rotate a secret, you do not manage it. You only store it.

CAS-005 4.2 also lists embedded secrets. That means a secret sitting inside code, a config file, a container image, a pipeline variable, or a ticket. The exam groups that finding with other software defects such as insecure configuration and outdated libraries. The matching mitigation line is secrets management and key rotation, next to least privilege and fail-secure design.

Why “just put it in the repo” fails the objective

A repository, a Terraform file, and a container image all replicate. A secret written into any of them replicates with them.

That breaks three exam ideas at once:

1. 3.1 rotation and deletion. You cannot delete a password that already lives in git history, old images, and backup snapshots.
2. 4.2 embedded secrets. The secret is now part of the artifact, not a controlled identity object.
3. 2.2 / 2.5 CI/CD. The pipeline that should test and deploy now carries production credentials.

Zero Trust language in 2.6 does not help if the workload already holds a long-lived key. Continuous authorization needs a subject that can be checked again. A password pasted into a YAML file is not checked again. It sits there until someone finds it.

Show the failure as a flow, not a slogan:

1. A developer writes an API token into application config.
2. The build system copies that file into an image.
3. The image ships to several clusters.
4. Rotation of the live token does not rewrite the old image tags.
5. Deletion of the token in one console does not erase copies in logs, tickets, and prior commits.

The control the exam wants is not “hide the file.” The control is a secrets system that issues, limits, rotates, and deletes those four object types.

IAM troubleshooting: treat secrets as identity objects

Objective 3.1 is a scenario objective: troubleshoot common issues with IAM components in an enterprise environment.

When a service fails with “invalid token” or “expired certificate,” the senior answer is not “hardcode a new one.” Walk the same lifecycle the blueprint lists.

Identify the subject. 3.1 also cares about subject access control for a user, a process, a device, or a service. Name which one holds the secret.

Name the object type. Token, certificate, password, or key. Each fails differently. A certificate expires on a date. A password gets reused. A token outlives the session that minted it. A key gets copied into an image.

Check rotation. Did anyone replace the value after issue? Is there a recorded interval? 4.2 repeats key rotation under mitigations.

Check deletion. Does the old value still work? If it does, rotation did not finish.

Check privilege. Nearby 3.1 / IAM bullets include privilege identity management and privileged access management (PAM). A build robot that can read every production key is not least privilege.

Check logs. 3.1 lists logging and monitoring next to secrets management. A retrieval with no audit trail is an IAM defect, not just a tooling gap.

Use that checklist on the exam item before you reach for a vendor name.

Where Vault fits — and where the blueprint stops

The today’s title uses HashiCorp Vault as the enterprise example. Official CAS-005 text does not.

What you may state without extra product claims:

• Vault is a secrets manager. Teams use a secrets manager so applications request tokens, certificates, passwords, and keys at run time instead of carrying them in source.
• That pattern supports 3.1 rotation and deletion, 4.2 embedded-secret reduction, 2.5 container and CI/CD work, and 3.6 automation through APIs and infrastructure as code (IaC).

Scaling secrets without embedding them

Enterprise scale, in CAS-005 terms, means many subjects and many objects, not a bigger password file.

One secret, many copies, is the failure mode. Rotation must change the live value and cut off the old one (3.1 deletion + 4.2 key rotation).

Pipelines consume secrets. They should not store them. 2.2 covers CI/CD testing gates. 2.5 names the CI/CD pipeline, Terraform, Ansible, container security, and orchestration. 3.6 names scripting, IaC, and cloud APIs. The secure pattern is: the job authenticates as a service subject, fetches a short-lived secret, uses it, and lets rotation retire it. The job definition itself holds no password.

Certificates belong in the same system as passwords. 3.1 lists certificates beside tokens. 2.6 spends a long stretch on PKI architecture, certificate types, and deployment. A TLS private key left on a build agent is an embedded secret.

Zero Trust still applies to machines. 2.6 asks for continuous authorization, API integration and validation, and subject-object relationships. A workload is a subject. The database, queue, or cloud API is an object. The secret is only the current proof of that relationship. When context changes, issue a new proof. Do not keep a static key that ignores context.

Least function sits next to secrets management in 4.2. A service that needs a read token should not receive a master key. Fail-secure means a missing secret stops the action. It does not fall back to a hardcoded default.

CAS-005 map for this title

Use this map when you study or when you tag the WordPress post.

Domain weights on CAS-005: Governance, Risk, and Compliance 20%; Security Architecture 27%; Security Engineering 31%; Security Operations 22%. Secrets work sits mainly in Engineering (3.1, 3.6) and Operations/attack-surface analysis (4.2), with architecture support from 2.2, 2.5, and 2.6.

Study moves that stay inside the blueprint

1. Take any application config you own. List every token, certificate, password, and key. Mark each one rotated or not. Mark each one deletable or not.
2. Find one embedded secret. Plan the 4.2 mitigation: move the value out of the artifact, issue it at run time, rotate it, delete the old value, and log the retrieval.
3. Write the subject and the object in one sentence. Example: “The payment process (subject) calls the billing API (object) with a token.” That is 2.6 language, not vendor language.
4. Keep product labs in the companion post. The 14:00 title is Lab: Automating Secret Injection into Kubernetes Pods with Vault. This AM piece stays on objects and lifecycle.

The CAS-005 hub for the rest of the SecurityX sequence is the ultimate guide to CompTIA SecurityX (CAS-005).