DevOps and platform engineers should learn to secure the pipeline itself: who can change it, what credentials it holds, what it pulls in, and how its artifacts are verified. The OWASP Top 10 CI/CD Security Risks gives a ready outline, from flow control to logging and visibility.
Why this audience is different
Application developers write code that runs inside a boundary. Platform engineers build the boundary and the machinery that ships code through it. A weak pipeline can undo careful application security, because whoever controls a build can control what ships.
Yet most developer security training stops at the code. Platform engineers get left with a vague "be careful with secrets".
The OWASP CI/CD list as a syllabus
The OWASP Top 10 CI/CD Security Risks names these categories:
| Id | Risk | Teaching question |
|---|---|---|
| CICD-SEC-1 | Insufficient Flow Control Mechanisms | Can one person push code to production unreviewed? |
| CICD-SEC-2 | Inadequate Identity and Access Management | Who has access, and is it still needed? |
| CICD-SEC-3 | Dependency Chain Abuse | What does the build fetch, and from where? |
| CICD-SEC-4 | Poisoned Pipeline Execution | Can a pull request change what the pipeline runs? |
| CICD-SEC-5 | Insufficient PBAC | What can each pipeline job reach? |
| CICD-SEC-6 | Insufficient Credential Hygiene | Where do credentials live and how long? |
| CICD-SEC-7 | Insecure System Configuration | Are the build systems themselves hardened? |
| CICD-SEC-8 | Ungoverned Usage of 3rd Party Services | Which outside services touch the pipeline? |
| CICD-SEC-9 | Improper Artifact Integrity Validation | How do we know what we deployed is what we built? |
| CICD-SEC-10 | Insufficient Logging and Visibility | Could we reconstruct what a pipeline did? |
The right column is mine, not OWASP's. Questions teach better than labels.
A four session plan
- Control and identity (SEC-1, 2, 5): review rules, least privilege per job, access reviews.
- Inputs (SEC-3, 4, 8): dependency sources, pull request triggered jobs, outside services.
- Credentials and config (SEC-6, 7): short lived credentials, where secrets are stored, hardening runners.
- Outputs and evidence (SEC-9, 10): artifact verification, logs that answer questions.
Exercises
- Draw your own pipeline on a whiteboard and mark every place a credential appears. Count them.
- Walk through what a malicious pull request from a fork could trigger in your setup.
- Pick one deployed artifact and trace it back to the exact commit and build. Note where the trail breaks.
- Ask each engineer to name the one pipeline permission they would remove first.
Make it a team habit, not a course
Pipelines change weekly. A one time class dates fast. Add a short security note to your change process for pipeline edits and review it as a team after incidents or near misses. The DevOps guidance from OWASP also stresses adding checks gradually and noting that CI/CD tools expand the attack surface and need their own controls.
Where Safeguard fits
Safeguard provides dependency scanning, policies and gates that can block a pull request on defined conditions, and compliance evidence automation. Those give platform teams concrete material for the exercises above. Try a free scan at gold.safeguard.sh/scan. Safeguard does not offer training courses.
Quick check
Is pipeline security part of developer training or its own topic?
Its own topic for the people who build and run pipelines. Application developers need an overview, platform engineers need depth.
How often should this training be refreshed?
Revisit it whenever the pipeline changes materially, and after any incident that touched build or deploy systems.
Sources
- OWASP Top 10 CI/CD Security Risks: owasp.org/www-project-top-10-ci-cd-security-risks
- OWASP DevSecOps Guideline: owasp.org/www-project-devsecops-guideline
Last reviewed: 19 October 2026.
