Fawzooz
عربي

Awakening Security

Request the PDF

Enter your email and we will send you a code; your request is then recorded at once, and once I have reviewed it a link to download your copy reaches your email.

By continuing, your email and progress are kept in your account. Privacy

* The file is for your own reading; sharing follows the terms of use, and commercial use is not permitted.

Reading progress
0 of 34 sections read
27 / 34

Chapter 25

25DevSecOps: Security Automated at Every Stage

1 min read27 of 34Read it in the book · page 144

“If security needs a manual reminder in every release, it will be forgotten in the most rushed one.”

DevSecOps integrates security into the culture and tooling of development and operations, so that scanning and testing become an automatic part of every code change. The goal is not to slow releases down but to make the secure release the easiest path.

The DevSecOps loop: security automated at every stageThe DevSecOps loop: security automated at every stage
The DevSecOps loop: security automated at every stage
Text in this figure

Plan · Threat modelling · Build · SAST · secret scan · Test · DAST · SCA · Release · Signing · SBOM · Deploy · Secure IaC · Operate · Hardened config · Monitor · Logs · alerts · Learn · Incident review · A continuous loop inside the CI/CD pipeline: security is an automated gate, not a manual stop · Figure 32

Security in the Release Pipeline

  • Before merge: Scanning for leaked secrets, static code analysis (SAST) and peer review.
  • At build: Software composition analysis (SCA), generating an SBOM, and scanning container images.
  • At test: Dynamic testing (DAST) on an environment resembling production.
  • At deploy: Scanning infrastructure as code (IaC) to catch misconfigurations before they reach the cloud.
  • In operation: Continuous monitoring, alerts and feedback to the team.

Implementation Principles

  • Start small: One secrets scan beats ten tools switched off after a week because of alert overload.
  • Break the build only for critical issues: A critical vulnerability stops the release; a medium one is logged and tracked.
  • Give the developer context: A message explaining the risk and how to fix it is more useful than a vulnerability number.
  • Measure: Mean time to fix vulnerabilities, and the share of releases that pass every check.

These practices directly serve 27001 controls: secure coding (8.28), security testing in development and acceptance (8.29), separation of environments (8.31), change management (8.32) and configuration management (8.9).

2026 Update

The idea has extended to AI as MLSecOps: scanning downloaded models before use, tracking data and model versions, and automated tests for prompt injection and harmful outputs before every release of an application built on a language model.

Make the secure path the shortest path, and everyone will take it.

Lessons Learned

  1. 1DevSecOps makes security an automatic part of every change.
  2. 2Every stage of the release pipeline has its own appropriate check.
  3. 3Start small, and break the build only for critical issues.
  4. 4MLSecOps extends the idea to models and data.

Tip: use ← → to move between sections.