Topics in this domain
- Enterprise Architecture and IT Risk
- Change Management Risk
- Assets, Configuration and Dependencies
- Incident and Problem Management Oversight
- Project Governance and IT Risk
- Governing the Secure SDLC
- DevOps, CI/CD and Agile Delivery Risk
- Testing, Release and Deployment Risk
- Data Classification, Ownership and Handling
- Data Lifecycle: Integrity, Retention and Disposal
- Business Continuity Planning and Governance
- Disaster Recovery and Testing Recovery Capability
- Emerging Technology Risk: Cloud, IoT and OT
- AI and Machine Learning Risk
- Setting Risk Boundaries for Innovation
- Core Security Concepts: CIA, IAM, Cryptography and Network Security
- Security Frameworks and Control Standards
- Security Awareness Culture and Measuring Training
- Privacy Governance and Data Protection Principles
- Developing a Data Protection Control Strategy
DevOps, CI/CD and Agile Delivery Risk
Controls move into the workflow
Segregation of duties in DevOps
Protecting the pipeline
- Restrict who can change the pipeline configuration.
- Log and review pipeline changes.
- Protect the secrets and signing keys the pipeline uses.
- Scan code, dependencies and containers automatically.
Example. An attacker who compromised a developer’s account changed a pipeline script to add a backdoor to every build. Requiring approval for pipeline changes and signing build artefacts closed the gap.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| SoD in CI/CD | Peer review and pipeline-only deployment |
| Security in agile | Backlog items and the definition of done |
| GREATEST DevOps risk | Unreviewed changes reaching production, or an unprotected pipeline |
| Keeping security pace with releases | Automated testing in the pipeline |
In short
- Agile and DevOps deliver small changes often; controls must be built into the way teams work.
- Security and control requirements go into the backlog and the definition of done.
- In CI/CD, segregation of duties is enforced by peer review, protected branches and pipeline-only deployment.
- The pipeline itself is a critical asset; changes to it must be restricted and logged.
- Automated testing and scanning keep pace with frequent releases.
Exam traps
- Assuming agile means no documentation or controls.
- Developers self-approving merges and deploying with personal credentials.
- Leaving the pipeline open for anyone to edit.
- Manual security reviews that can't keep up with release frequency.
Slides
Click the slide and use the arrow keys. F toggles full screen.
1 / 7