Release record
Illustration- What is inside
- Built from
- Scans
- Code
- Dependencies
- Image
- Secrets
- Signed
- Approved by
- Live since
DevSecOps Pipelines: Every change checked before it ships
We build pipelines that test and scan every change, sign what passes, and wait for a second person before production.
Where a bad release gets stopped
- Commit: A key or token in the code is stopped at the push.
- Build: Built from the reviewed commit, every dependency pinned to a known version.
- Scan: A library or image with a flaw above your threshold stops here.
- Sign: What passes is signed and carries a list of what is inside.
- Approve: A second person approves production. The one who started the release cannot.
- Release: Where the platform checks signatures, only signed builds start, and a bad release rolls back.
Release
Where the platform checks signatures, only signed builds start, and a bad release rolls back.
Scanned, signed and approved by a second person, then live.
Release
Where the platform checks signatures, only signed builds start, and a bad release rolls back.
Scanned, signed and approved by a second person, then live.
Commit
A key or token in the code is stopped at the push.
Refused at the push, before it reaches a build.
Scan
A library or image with a flaw above your threshold stops here.
Stopped at the scan and sent back with the finding.
Approve
A second person approves production. The one who started the release cannot.
Sent back until someone else on the team approves it.
Release
Where the platform checks signatures, only signed builds start, and a bad release rolls back.
Refused at release where signatures are checked, because it has none.
Release
Where the platform checks signatures, only signed builds start, and a bad release rolls back.
Rolled back to the last good release, and the team is told.
What each release carries
Each release keeps this record in your registry and your audit log, for an auditor or a customer’s security team to read.
The tools, on each cloud
- Pipeline
- AWS CodePipeline and AWS CodeBuild
- Scans
- Amazon Inspector, in the pipeline and on pull requests
- Signed and checked
- Amazon ECR signing with AWS Signer
- Pipeline sign-in
- IAM roles through OpenID Connect
On GitHub, GitLab or Azure DevOps, wherever your code lives. The pipeline signs in with short-lived tokens, so no long-lived cloud key is stored in it.
Customer work
- Managed Services
CodeBuild pipelines run build, lint, unit tests and SonarQube checks on every merge.
31 ms at p95Order serviceShwapnoRetail chain, online store, BangladeshRead the story: Shwapno (opens in a new tab) - Migration & Modernization
Builds and releases automated with GitHub Actions and Azure Pipelines.
A smoother booking processBus booking platformBus travelRead the story: Bus booking platform (opens in a new tab)
Where you will meet it
Questions
Do we have to move our code?
No. We build on GitHub, GitLab or Azure DevOps, whichever you use, and the pipeline lives in your repository.
Will a scan block every release?
Only findings above the level you agree, by severity. The rest are reported and ranked for your team.
Can each release list what is inside it?
Yes. Each build can produce a software bill of materials in CycloneDX or SPDX, kept with the release and its signature.
Does this replace a penetration test?
No. The pipeline checks code, dependencies and images on every change. A penetration test is a separate engagement.