Digital services · Secure software delivery
Finding security issues while they are still inexpensive to fix
A DevSecOps programme integrating automated analysis, dynamic testing, release gates, ownership, remediation and retesting.
65%
of findings caught before formal testing
72%
fewer critical production findings
95%
automated coverage
7 days
remediation (from 18)
In brief
A digital services organisation ran most security testing late in the release lifecycle, causing rework and conflict between deadlines and remediation. ClimsTech integrated security checks into the delivery process and defined risk-based release gates, ownership, time-bound exceptions and retesting — making security part of delivery evidence rather than an external late-stage gate.
Working constraints
- Multiple application teams
- Existing CI/CD pipelines
- Different technology stacks
- Need for risk-based policy
- False-positive management
- Manual penetration testing still required
- Production deadlines
The problem
What was actually going wrong
Security was a separate late-stage activity rather than part of normal engineering. This increased rework, reduced predictability, and made release decisions inconsistent.
What discovery surfaced
- 1Security coverage differed significantly by application.
- 2Findings were not always assigned to clear owners.
- 3Release-blocking criteria were inconsistent.
- 4Exceptions lacked expiry or follow-up.
- 5Automated tools were not connected to delivery evidence.
- 6Retesting was manual and delayed.
The engineering
What we built and changed
1Static analysis
SAST was introduced during pull-request and build stages.
2Dynamic testing
DAST ran against suitable test environments.
3Manual testing alignment
Penetration testing and vulnerability assessment were aligned to major releases and risk-sensitive changes.
4Release policy
Severity, exploitability, context, and exception process determined whether a release could proceed.
5Ownership and retesting
Findings were assigned, tracked, remediated, and retested.
Security became part of delivery evidence and engineering ownership rather than an external late-stage gate.
The architecture
Before and after
- Late-stage security testing
- No consistent finding ownership
- Inconsistent release-blocking criteria
- Exceptions without expiry
- Disconnected automated tools
- Manual, delayed retesting
- Code commit
- Static analysis (SAST)
- Build and unit tests
- Dynamic analysis (DAST)
- Risk-based release gate
- Remediation and retesting
- Production
Judgement calls
Decisions that shaped the outcome
Why not block every finding?
Risk differs by severity, exploitability, and application context. A risk-based policy avoids both unsafe release and unnecessary delay.
Why retain manual testing?
Automated tools provide repeatable coverage but cannot fully assess business logic and complex attack paths.
Why define exception expiry?
Permanent exceptions become hidden risk. Time-bound exceptions preserve accountability.
Verified outcomes
What changed for the business
- 65% of findings identified earlier
- Critical production findings reduced by 72%
- Automated coverage increased from 18% to 95%
- Security-related delays reduced by 41%
- Remediation time reduced from 18 to 7 days
- More than 1,400 checks executed monthly
- Release exception visibility reached 100%
What this engagement proves
Shift-left security works when tools, policy, ownership and release decisions are designed together.
Field notes on this class of problem
All field notesSecuring the CI/CD supply chain: DevSecOps that doesn't slow you down
Your pipeline is attack surface — controls that run inline, not gates teams skip.
17 min read
SecurityHardening Kubernetes: The Controls That Actually Close Gaps
The hardening controls with the highest signal-to-effort ratio, in order.
20 min read
DevOps & deliveryFrom scripts to pipelines: a CI/CD maturity model
You don't need the most advanced pipeline — you need the next rung up.
21 min read