Engineering
What we mean when we say DevSecOps
The term is overused. Here is the concrete set of practices behind it on our projects.
DevSecOps has become a word people put in proposals. Underneath it is a specific set of practices. These are the ones we mean.
Version control for everything
Application code, infrastructure code, pipeline definitions, and configuration all live in version control with review before merge. Nothing reaches production that was not committed.
Continuous integration
Every change triggers a build and the automated test suite. A red build blocks merging. The suite includes unit tests and, for anything user-facing, end-to-end tests.
Security scanning in the pipeline
- Static analysis of application code
- Dependency scanning against known vulnerabilities
- Secrets detection so credentials never get committed
- Container image scanning
- Infrastructure code scanning for misconfigurations
Findings above an agreed severity fail the build. Exceptions are documented with an owner and an expiry.
Software bill of materials
Each release produces a list of its components, so when a vulnerability is announced the agency can answer "are we affected?" in minutes.
Automated deployment
Deployments are scripted and identical across environments. Production deployments require an approval but no manual steps.
Observability
Logs, metrics, and traces are collected from the first deployment, with alerts that page a human when something breaks.
Reviews and retrospectives
Code review on every change. Periodic retrospectives on incidents and near misses, with changes to the pipeline as a result.
What this costs
Setting it up takes a few weeks on a new project and longer on an existing one. It pays back in fewer incidents, faster releases, and audit evidence that exists as a byproduct of working rather than as a separate chore.