CI/CD & DevSecOps

CI/CD stands for Continuous Integration and Continuous Delivery or Deployment.
Continuous Integration automatically builds and tests changes when developers update the codebase.
Continuous Delivery prepares validated software so it can be released safely when required. Continuous Deployment goes one step further and can move changes to production automatically when all required checks pass.
OWASP makes the same distinction between CI, delivery and deployment in its current CI/CD security guidance.

DevSecOps brings security practices into normal software development and operations instead of treating security as a separate final review.
This can include secure coding rules, automated security testing, dependency scanning, Infrastructure as Code checks, artifact controls and deployment policies.
Microsoft recommends integrating security activities into every development stage rather than relying on one late checkpoint.

We are tooling and cloud agnostic.
We can work with platforms such as GitHub Actions, GitLab CI/CD, Azure DevOps, Jenkins, cloud-native delivery services and other enterprise CI/CD tools.
The tool should fit your repositories, runtime, security requirements and operating model rather than define the delivery process by itself.

It depends on the application and risk.
Typical controls can include static code analysis, dependency and license scanning, secrets detection, container scanning, Infrastructure as Code scanning, dynamic testing and policy checks.
Not every check needs to block every build. We define where each control gives useful feedback and which findings are serious enough to stop a release.
OWASP specifically recommends SAST, DAST, IaC and related scanning inside CI/CD workflows.

Not always.
Low-risk services may be suitable for highly automated deployment. Critical or regulated systems may still require explicit approval before production.
The important point is that approval should sit inside a clear automated workflow rather than depend on an informal manual process.
OWASP recommends manual approval before production in many CI/CD security scenarios, while Microsoft recommends secure, governed deployment workflows with rollback capability.

The software supply chain includes the source code, third-party libraries, build tools, CI/CD systems, artifact repositories and other components used to create and deliver software.
A weakness in any of these can affect the final application.
Useful controls can include dependency scanning, SBOM generation, signed artifacts and build provenance so teams can verify where software came from and how it was built.
NIST explicitly includes SBOMs, provenance and CI/CD pipeline controls in its software supply-chain security guidance.

Provenance records where, when and how a software artifact was created.
Artifact attestations add signed evidence that links the built artifact back to its source and build process.
This can improve trust in the delivery chain, especially when software moves through many tools or teams.
SLSA defines provenance as verifiable information about how an artifact was produced, while GitHub now supports signed artifact attestations and SBOM-related attestations directly in Actions workflows.

We look at delivery flow and quality together.
Useful measures can include deployment frequency, change lead time, failed deployment recovery time, change failure percentage, deployment rework and manual steps in the pipeline.
DORA recommends these measures to understand whether delivery is becoming faster and safer, rather than judging success by the number of tools or pipelines created.