Services · Secure SDLC
We build it and we break it.
One firm, two practices, one backlog. The seam between build and break, removed.
9 days medianfrom a security finding being confirmed to the fix being in production, on joint engagements
The gap
Week forty-one is the expensive way
We build it and we break it. The findings land in our own sprint backlog.
The client had to replace a clinical workflow system their customers depended on, carry NHS Data Security and Protection Toolkit obligations plus a SOC 2 Type II commitment made to a US customer, and do it in under a year. Their previous build, with a different vendor, had been tested in its final month: the test returned four criticals, two of which required an architectural change, and the launch slipped by five months. The brief was explicit — never again — but the proposed remedy, buying a second security vendor to test earlier, reproduces the handover rather than removing it.
The standard arrangement is that a development firm builds your software for forty weeks and a security firm tests it in week forty-one. Everything that test finds is now expensive, because the architecture is set, the team is rolling off, and a finding that requires a design change arrives after the design is load-bearing. Both firms behaved correctly and the outcome is still bad. Our two practices run against each other continuously instead: our testers review the design before it is built, read the code as it is written, and raise findings into the same backlog our engineers work from. The number that matters is the nine days between a finding being confirmed and the fix being live, and it is only possible because there is no handover in the middle.
The obvious objection
Is it a conflict of interest to test your own build?
It would be if the same person did both, so they do not. The pre-release test is led by a tester who has not contributed code, the report comes to you unedited, and a third reviewer signs it. We will also support an independent third-party test and share the threat model with them — our commercial interest in a clean report is exactly why your structural scepticism is correct.
The pre-release test came back with no criticals and my first reaction was to distrust it, because the same firm built the thing. So we paid a third party to test it as well. They found one medium. That is when I stopped arguing about the structure.
The integrated model
Secure SDLC
One firm, two practices, one backlog. The seam between build and break, removed.
The Adversary Loop, as a pipeline
Seven stages, two squads, one backlog. Every stage changes lane, which means every transition is a hand-off inside one team rather than a hand-over between two firms — and the seventh stage returns to the first.
- Security squad
- Dev squad
- Lane change — a hand-off, not a hand-over
Security squadBefore sprint 1
Threat model
Security and engineering in one room with the architecture, before a line of it is built. The cheapest security finding is an architecture decision.
ArtefactRanked control list
Dev squadPer architectural decision
Secure design review
Engineers author the decision record and a security engineer reads it before it is built. Disagreements get resolved in the record, so the reasoning survives the people.
ArtefactSigned decision record
Security squadContinuous
Secure code review
Every pull request touching authentication, authorisation, cryptography or data access gets a security read. Comments in the PR, not a separate report nobody opens.
ArtefactComments on the pull request
Dev squadFrom sprint 1
Pipeline gates
SAST, DAST, SCA and secret scanning in CI, tuned to a signal-to-noise ratio the delivery team actually accepts. Findings become tickets in the same backlog as features.
ArtefactTuned SAST / DAST gate, agreed finding budget
Security squadFinal 4 weeks
Pre-release test
A full penetration test led by someone who wrote none of the code, with the report issued to you unedited. Criticals block the release, and that is agreed in writing beforehand.
ArtefactUnedited pen test report
Dev squadPost-launch
Monitoring
Detections written for the system as built, versioned in the same repository as the system they watch. Not a generic rule pack.
ArtefactDetections in source control
Security squadPost-launch
Retest
Thirty days after launch, then on an agreed cadence. What the retest finds does not go in a backlog of its own — it rewrites stage one.
ArtefactDelta report, and a new threat model
The loop closes. What the retest finds does not open a report of its own — it rewrites stage one, and the next pass through the pipeline is run against the threat model the last pass produced.
Scope
What is included
Threat model at design time
Before the first sprint. The cheapest security finding is an architecture decision, and the most expensive one is the same decision discovered in week forty.
Secure design review at each decision
Our testers review architectural decision records as they are written, not the finished system.
Security in the pipeline
SAST, DAST, SCA and secret scanning tuned to a signal-to-noise ratio the delivery team accepts, with an agreed finding budget.
Continuous testing during the build
Not one test at the end. Testers work against each major feature as it lands, while changing it is still cheap.
Pre-release penetration test
A full test before go-live by a lead tester who did not write the code, with the report issued to you unedited.
Monitoring and retest
Detections written for the system we built, and a retest cadence after launch. The loop does not stop at release.
Who does what
The dev squad and the security squad
Your delivery squad plus a named security engineer at 20–30% allocation, and an independent lead tester for the pre-release test.
Software Development
Products, platforms and business systems built to survive an audit and a handover.
Marcus Reid
Head of Engineering
- AWS Solutions Architect Professional
Priya Raman
Principal Architect
- AWS Solutions Architect Professional
- CKA
Cybersecurity
Testing, assurance, detection and response — by people who also ship production software.
Sofia Marek
Principal Application Security Engineer
- OSWE
- CISSP
- GIAC GWAPT
Imran Haque
Head of Offensive Security
- OSCP
- OSWE
- CREST CRT
- GIAC GXPN
A tech lead, four engineers, a designer, a security engineer at 25%, and an independent lead tester for the pre-release test.
The Adversary Loop
How the loop runs
Threat models shape the build. The build gets attacked. The attack rewrites the threat model.
Phase 1: Threat model
Before sprint 1Security and engineering in one room with the architecture. Output is a threat model and a ranked list of the controls worth building, owned by the engineers.
Phase 2: Secure design review
Per architectural decisionEach decision record gets a security read. Disagreements get resolved in the record, so the reasoning survives the people.
Phase 3: Secure code review
ContinuousSecurity engineers review pull requests touching authentication, authorisation, cryptography and data access. Comments, not a separate report.
Phase 4: Pipeline gates
From sprint 1SAST, DAST, SCA and secret scanning, tuned and gated against the agreed budget. Findings become tickets in the same backlog as features.
Phase 5: Pre-release test
Final 4 weeksFull penetration test by an independent lead tester. Report unedited to you. Criticals block the release.
Phase 6: Monitor and retest
Post-launchDetections for the system as built, a 30-day retest, and a cadence thereafter. The threat model is updated from what the testing found.
Evidence
Findings land in our own sprint backlog
Every finding is timestamped at confirmation and at the deploy that fixed it, both drawn from your own tracker and your own pipeline rather than from ours. The monthly report shows the distribution, not just the median, because the tail is where the interesting cases are.
- 9 days medianfrom a security finding being confirmed to the fix being in production, on joint engagements
- 0 critical, 2 highat the independent pre-release penetration testBoth highs fixed and retested inside 5 days
- 9 daysmedian finding-confirmed to fix-in-productionMeasured from the client’s own tracker and pipeline
We build it and we break it. The findings land in our own sprint backlog.
- Threat model in your repository, authored by the engineers who own the components
- Security review comments in the pull requests, not in a separate document
- Tuned pipeline with an agreed finding budget and the rationale recorded
- Independent pre-release penetration test report, issued unedited
- Detections written for the system as built, in your source control
- Cycle-time evidence: finding confirmed to fix in production, per finding
Compliance
Compliance as a by-product
Secure development policy evidence for SOC 2 CC8.1, ISO 27001 Annex A 8.25 to 8.31, and PCI DSS Requirement 6. Because the evidence is generated by the process rather than assembled for the audit, it tends to survive sampling.
- NIST SSDF (SP 800-218)
- OWASP SAMM 2.0
- OWASP ASVS 4.0
- SLSA v1.0
- Security findings that arrive while they are still cheap to fix
- No week-forty-one surprise that invalidates an architectural decision
- One backlog, one set of priorities, one team accountable
- SOC 2, ISO 27001 and PCI readiness as a by-product of the process
- Measured cycle time from finding to fix, published to you monthly
Proof
A build where the security practice caught something
Clinical workflow vendor, 180 employees
A clinical workflow platform shipped with zero critical findings at its pre-release test — because the security practice had been reading the code for eight months.
- 0 critical, 2 highat the independent pre-release penetration testBoth highs fixed and retested inside 5 days
- 9 daysmedian finding-confirmed to fix-in-productionMeasured from the client’s own tracker and pipeline
- 94%of SOC 2 CC7 and CC8 evidence generated by the processRather than assembled for the audit
The pre-release test came back with no criticals and my first reaction was to distrust it, because the same firm built the thing. So we paid a third party to test it as well. They found one medium. That is when I stopped arguing about the structure.
The technical layer
The three architecture-changing findings from the week-one threat model were: an audit log designed as application-writable rather than append-only, which would have failed a DSPT evidence question about tamper-resistance; a plan to hold the clinical record encryption key in the same AWS account as the application, which collapses the blast radius of an account compromise into a total data breach; and a clinician impersonation feature — genuinely required for support — specified without a second-person authorisation step or a distinct audit event, which is the precise shape of the control an Information Commissioner enquiry asks about first. All three cost roughly a sprint to address in week one. The audit log alone would have been a six-week retrofit in month ten, because by then eleven services would have been writing to it.
Two vendors, or one partner
What changes when the seam is removed
| Compared on | Two vendors | One partner |
|---|---|---|
| Hand-off cost | A full re-learning period, paid twice. The testers meet the architecture for the first time in week forty-one, and the engineers who could answer their questions have rolled off the account. | None to pay. The tester who runs the pre-release test read the first decision record in week two, and has been in the stand-up ever since. |
| Remediation lead time | Weeks. A finding is written into one firm’s report, triaged in a meeting, re-estimated into another firm’s backlog, then scheduled against a roadmap that was agreed before the finding existed. | Nine days median, from a finding being confirmed to the fix being live — measured in your tracker and your pipeline, not ours, and reported monthly as a distribution rather than a headline. |
| Who is accountable when it breaks | Both firms, which in practice means neither. The builder points at the specification, the tester points at the build, and you hold two contracts that each exclude the other’s work. | One contract, one backlog, one named engineering lead. The pre-release test is still signed by a tester who contributed no code, and the report comes to you unedited. |
The nine-day median is drawn from joint engagements where we hold both the confirmation timestamp and the deploy timestamp. Engagements where we cannot see both are excluded rather than estimated.
Selected clients
- Northgate Freight
- Lumen Clinical
- Verity Payments
- Aldercross Group
- Mereway Housing
- Hallstead Retail
- Carrick Analytics
- Pelham Energy
- Severn Mutual
- Orbis Education
Related
What this overlays
Secure code review, CI gates and threat models that engineers will actually maintain.
Cybersecurity
Production systems with authorisation, audit and secrets handled properly from the first commit.
Software Development
Manual, evidence-led testing with criticals reported the hour they are confirmed.
Cybersecurity
Reproducible infrastructure, short-lived pipeline identity, and a rehearsed rollback.
Software Development
Commercials
Shape, timeline and scoping
- Timeline
- Runs for the life of the build. The threat model happens before sprint one.
- Team shape
- Your delivery squad plus a named security engineer at 20–30% allocation, and an independent lead tester for the pre-release test.
- Engagement
- An overlay on any build engagement, or a programme applied to an existing in-house delivery team.
- Scoping
- A named engineer replies within one business day. Scoping call within three. How the four engagement models differ.
Questions
The rest of what buyers ask
The conflict-of-interest question is answered in full further up this page.
- What does this cost compared with building then testing?
- The security allocation is roughly 8 to 12% of the build cost. Against it: the findings arrive when they cost a sprint rather than a redesign, there is no handover and re-learning period, and compliance evidence comes out of the process rather than out of a separate exercise. On the engagements where we have both numbers, integrated has been cheaper in total — but we would rather show you the two case studies than assert it.
- Can you apply this to our in-house team?
- Yes, and it is a common engagement. The security practice embeds with your delivery team, the gates and the backlog are yours, and the goal is that your engineers own the model within two quarters. We bring the testers; you keep the capability.
- What if a critical finding appears a week before launch?
- It blocks the launch, and that is agreed in writing before the engagement starts, so the conversation happens when nobody is under pressure. In practice continuous review means late criticals are rare — the point of the model is to move findings earlier, and the cycle-time number is how you check that it is working.
- Does this replace a penetration test?
- No — it contains one, and adds the continuous work around it. If you only want the point-in-time measurement, buy the test on its own; it is a legitimate purchase. This is for building a system that passes it.
- How do you prove the cycle-time claim?
- Every finding is timestamped at confirmation and at the deploy that fixed it, both drawn from your own tracker and your own pipeline rather than from ours. The monthly report shows the distribution, not just the median, because the tail is where the interesting cases are.
- What compliance evidence does this generate?
- Secure development policy evidence for SOC 2 CC8.1, ISO 27001 Annex A 8.25 to 8.31, and PCI DSS Requirement 6. Because the evidence is generated by the process rather than assembled for the audit, it tends to survive sampling.
Get started
Book a secure-SDLC assessment
A technical conversation with the person who would lead the work — not a qualification script, not a discovery deck. You come away with a written scope, the exclusions stated in the body rather than in an appendix, and a day count that we have not padded.
A named engineer replies within one business day. Scoping call within three.