DevSecOps pipelines for government software

Reference article · 2 min read

A delivery pipeline automates the path from a code change to a deployed release, with testing and security checks at each stage. For government software, it also produces the evidence that oversight bodies ask for about how systems are built.

Stages

Commit. Code is pushed to version control. Pre-commit checks catch formatting problems and secrets.
Build. The application and its container image or package are built reproducibly.
Test. Unit, integration, and end-to-end tests run automatically. Failures stop the pipeline.
Scan. Static analysis, dependency vulnerability scanning, container image scanning, and infrastructure code scanning. Findings above a threshold stop the pipeline; exceptions are documented.
Package. Artifacts are versioned and stored, with a software bill of materials.
Deploy to test. Automated deployment to a test environment, with smoke tests.
Approve. A human approves promotion to production, with the pipeline's evidence attached.
Deploy to production. The same automation, with monitoring and a rollback path.

Evidence produced

Test results, scan results, the bill of materials, approval records, and deployment logs, all tied to a specific version. This is what auditors and security reviewers want, and it is generated by working rather than assembled afterward.

Government-specific considerations

Pipelines may need to run in environments that meet the data's security requirements
Approved container base images and dependency sources may be required
Separation of duties between developers and production deployers may be mandated
Records retention applies to pipeline artifacts on some programs

Tooling

Any mainstream platform, such as GitHub Actions, GitLab CI, Azure DevOps, or Jenkins, can implement this. The practices matter more than the tool.

Starting on an existing project

Add version control and a build first. Then tests, then scanning, then automated deployment. Each step reduces risk on its own.