What you’ll be able to do
- Place ShopCart on a five-node path from workstation to runtime.
- Explain separation of duties as a second human before production, not as a finance-only rule.
- Prefer promoting an immutable, signed artifact over rebuilding per environment without provenance.
- Name one secret that write access and promote access must not share.
One CI token can rebuild what everyone calls trusted
ShopCart’s next risk is not a clever bug in the cart total. It is a token that can rebuild the image production runs. OWASP A03:2025 says you are likely vulnerable when CI/CD is weaker than the systems it builds, and when no separation of duties exists: no single person should write code and promote it all the way to production without another human’s oversight. A green build badge means a pipeline finished. It does not mean the artifact is the one you reviewed.
Maya draws five nodes. Developer workstation and IDE. Code repository. Build server and CI. Artifact registry. Runtime. Each node is a supply-chain surface. A03 also says to track changes to CI settings, repositories, artifact repositories, and container registries, not only to application code.
| Node | Write | Promote |
|---|---|---|
| Workstation / IDE | Edit ShopCart | Cannot publish the production image |
| Code repository | Open a change | Protected branch; a second person approves |
| Build server and CI | Run the defined build | No long-lived production secret in the developer job |
| Artifact registry | Receive one immutable digest | Production pulls that digest; it does not rebuild |
| Runtime | Run the admitted image | Deploy identity is not the author’s git token |
Promote the artifact you built
A03’s harden list for artifacts says to protect integrity with provenance, signing, and time stamps, and to promote artifacts rather than rebuild for each environment. Rebuilding in production from a moving branch can hide drift: the source, the toolchain, or a transitive package may have changed since review. Environment-scoped secrets keep the production publish credential out of the job that only runs tests. Branch protection is the repository half of the same idea.
NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, final February 2022 (document history 3 February 2022), is a high-level practice set and a shared vocabulary for producers and purchasers. Practice PO.5 is “Implement and Maintain Secure Environments for Software Development,” including development, build, test, and distribution environments. This lesson uses that name. It does not dump every task. SP 800-218 Revision 1 (SSDF Version 1.2) is still an initial public draft, dated 17 December 2025, with the public comment period closed. As of 24 September 2026 it is not the final Atlas teaches.
- Write: change the code or the pipeline definition.
- Promote: approve and release an immutable digest to runtime.
- Secret split: git write is not the production deploy token.
- SSDF 1.1 PO.5 names the environments. It is not a product checklist.
Worked split for the merch pipeline
Devon can merge to the ShopCart repository because he wrote the receipt worker. He also holds the token that pushes the image into the production registry, because “it is faster before the merch Friday.” Maya’s correction is small. Devon may write and open the change. Priya, or another person who did not author that change, approves promotion. The production registry credential lives on the promote job, not in Devon’s laptop environment and not in the pull-request job.
Separation of duties is not only a finance control. A03 states it for the software supply chain. Least privilege from F5 is the same rule on identities: the writer identity and the promote identity are different subjects. A framework card can hold the longer SSDF map later. This lesson only needs the split you can point at on the five nodes.
CHECK YOUR JUDGMENT
Devon can merge ShopCart changes and also holds the production registry token, so a green badge publishes the image. Which decision should Maya record?
NEXT FIELD LESSON