Talk to us about your development pipeline.
A free 30-minute introductory call. Tell us what is on your plate now and what came out of your latest test, and we will say where we would start and what can wait, even if we end up not working together.
Service · Software development
Setting up DevSecOps.
More code passes through than anyone can still read. A check that runs in the pipeline catches the category of errors that can be recognised mechanically, so your people's attention goes to the errors that cannot. We set that up with agreements that stay in place.
What we do here, and where the boundary lies.
In practice, DevSecOps means something simple: the checks you would otherwise run at the end, or not at all, run along as the code is written and delivered. Not a separate security project alongside development, but a number of gates built into the path code already takes. The value lies not in finding issues as such, but in timing: a flaw that surfaces while writing the code is a short conversation; the same flaw after delivery is an incident.
There is a reason this matters more now than it did a few years ago. The pace at which code is produced has grown faster than the pace at which people can review it, and tooling that generates code is optimised for working code rather than secure code. That means more gets through and more known patterns are in it, precisely the category a pipeline check catches and an overloaded reviewer does not.
We set up these checks, but most of the work lies in the agreements around them: what blocks, what warns, and how something gets through when it has to. This ties directly into your component inventory and vulnerability management. If your pipeline runs with an external party, we work together with whoever handles that management.
We set this up as a standalone project or as part of building custom software. For certification, it aligns with ISO 27001-compliant development. External reports come through our vulnerability disclosure policy.
Three types of engagement we take on here.
Switching everything on at once on an existing project produces a pile of alerts nobody will start on. We therefore work in this order, and only move on once the previous step is calm.
Secrets and dependencies
We always start with secrets. That is the most common mistake, the easiest to guard against, and the one nobody can argue with: a key or password in code has no legitimate exception. Next come the dependencies: outdated components with a known vulnerability, matched against your component inventory. Once that category sits at zero and stays there, you have the confidence to tackle the next one.
Block secretsClean up historyDependenciesAutomatic updates
Static analysis and containers
Analysis of the code itself for patterns that can be recognised mechanically: input that ends up unfiltered in a query, unsafe functions, missing checks where they belong. Alongside that, the container and infrastructure layer, where a large share of the reported vulnerabilities sit and where a wrong setting can expose something that should have stayed closed. We weigh alerts by where they are, not just by their score.
Static analysisContainer layerInfrastructure as codeNoise suppression
Gate agreements and the provenance of your build
For each category, we record what blocks and what warns, with a clean exception route that records who signs for what. In addition, securing the build pipeline itself: who may deploy what, where the building blocks come from, and whether you can show for an artefact which code it originated from. The latter is increasingly requested in procurement processes.
During a threat-led test, what matters is not only whether you find something, but when you found it and what you did next. See the app for the detection and response timeline.
Gates per categoryException routeDeployment rightsArtefact provenance
What you have at the end of an engagement.
Working checks in your own pipeline, plus the agreements that determine whether they are still switched on in six months' time.
- Checks in your own pipelineRunning in the build pipeline you already use, with tooling that suits your languages – not a separate environment that sits alongside your process.
- Gate agreements per categoryDocumented what blocks, what warns with a deadline, and what is information only, agreed with the people who work with them.
- An exception route that worksA proper way to let something through once, with who signs and until when – because without that route, the check gets switched off rather than the single case being let through.
- A clean starting pointThe existing findings in the categories you switch on have been cleared up or deliberately recorded, so the gate closes on a list that stands at zero.
- Rights and provenance around the build pipelineWho may deploy what, where building blocks come from, and the ability to trace an artefact back to the code it was built from.
- Handover to your teamWorking sessions in which your developers assess and resolve findings themselves, because a check nobody can explain gets bypassed within a month.
When this sounds familiar.
Four situations where setting up checks in the pipeline delivers more than it costs. If you recognise one, there is likely quick progress to be made.
More code than review
More goes through than anyone can check
The pace has picked up and code review has become the bottleneck, or it has quietly turned into a formality. A mechanical check catches the category of mistakes that can be recognised by pattern, so your people can focus on the rest.
Findings after the fact
The penetration test turns up the same kinds of mistakes every time
You have testing done periodically and it always produces a list of known patterns. That is an expensive way to discover something the pipeline could have caught, and it makes the test less valuable for what it is actually good at.
Proving it to clients
Procurement questionnaires ask for it
Buyers ask in their questionnaires whether you have security checks in your development process and whether you can demonstrate them. Reporting that the checks ran and what they found is exactly what is being asked for.
An earlier attempt that stalled
It is switched on but nobody looks at it
A scanner was switched on at some point, hundreds of warnings are left open and the channel has been muted. That is not a tooling problem but an agreements problem, and that is exactly where we start.
How such a project runs.
1
Introduction and baseline
Which build pipeline is in use, which languages, what is already in place, and what came out of the last test or audit. We also look at people: who currently assesses findings, and what happens when something has to go live urgently. The latter determines whether gates hold.
2
Clearing up before anything is blocked
We switch the first category on in warning mode and clear up what comes out of it, together with your team. Blocking on a pile of open findings guarantees the check gets switched off. Only once the list is at zero does the gate close.
3
Agreeing with the people who work with it
For each category we decide what blocks, what warns and what is merely informational, and how the exception route works. We do this with the developers themselves and not only with those who make the decisions; that is the difference between a process that runs and one that stalls after a month.
4
Expanding in sprints
Category by category, in sprints, always in the same order: warning mode, clean-up, agreement, closing the gate. Secrets first, then dependencies, then static analysis, then the container and infrastructure layer.
5
Reporting and handover
Reporting you can include in a procurement process, a handover to your team, and an agreement on who manages the gates. If you would like us to review it periodically afterwards, that is possible, but it is not a requirement.
Frequently asked questions about DevSecOps.
What development teams, CTOs and security officers ask us before they start.
What does a pipeline check catch, and what does it not?
It catches: keys and passwords that end up in code, known insecure functions, input that reaches a query unfiltered, outdated components with a known vulnerability, and settings that leave open something that should have been closed. It does not catch: flaws in the logic of your access rules. That user A can retrieve user B's data is not a pattern but a consequence of how your rules are written, and no scanner will find that. That is why, alongside the automated check, there should be a short manual review round.
Won't this slow us down?
The checks themselves take minutes during the build, which is negligible. What slows things down is a badly tuned gate: blocking everything on a list of hundreds of open findings. That is precisely why we clear up first and only then close anything, and agree per category what gets stopped. In practice it saves time overall, because fixing afterwards costs more than correcting while writing.
How do we prevent the check from being switched off?
A proper exception route. There comes a point where something has to go through despite a finding: an outage, a deadline, a supplier that hasn't delivered yet. If there's no route for that, the check gets switched off, and then you lose everything instead of just that one case. The route records who signs off and until when the exception applies, so there's something to come back to later.
Do we need extra people for this?
Rarely. The work lies in setting it up and agreeing the rules; after that it takes your team less time than the firefighting it replaces. What is needed is an owner: someone who manages the gates and assesses exceptions. That is usually half a day a month, and it's typically the same person who assesses vulnerabilities, because it's the same judgement.
We use AI tools when developing. Does that make a difference?
Yes, and it strengthens the argument. More code gets through than a team can review, and tooling that generates code optimises for working code, not secure code. That's no reason to stop using it, but it does shift where the control needs to sit: from the reviewer to the pipeline. In addition, there is a category that classic scanners don't cover, such as instructions that arrive from outside and are followed by an AI feature; that requires a separate approach.
Does this also work on older software?
Yes, and the first round is the hardest, because the accumulated backlog becomes visible all at once. We tackle it by working strictly by category and only closing what is clean. With very old systems this often goes hand in hand with a conversation about modernisation or about technical debt, because some findings can't be resolved without touching the structure.
Will this cost us new licences?
Not necessarily. For secrets, dependencies, containers and most static analysis, open tooling is available that fits into your existing build chain, and many platforms have basic functionality built in. Paid products mainly add oversight across many projects and better noise reduction. We start with what you already have and set out any recurring costs for you in advance.
What do we do about the existing backlog?
We keep that separate. New findings are blocked from day one or given a deadline; the existing list gets its own approach, with an order based on impact rather than the published score. That separates the two conversations: the gate is about what comes in from now on, the backlog is about what was already there. Without that separation, one blocks the other.
Can we demonstrate this to a client?
Yes, and that's one of the reasons to do it. We set up reporting so you can show which checks run, how often, and what the outcome was, including the exceptions with their justification. That is exactly what gets asked for in procurement questionnaires and audits, and it's far more convincing than a policy document.
How does this relate to a pentest?
They find different things, and they don't replace each other. The pipeline catches known patterns, continuously and cheaply. A pentest finds what doesn't come out of that: errors in your authorisation logic, chains of small issues that add up to something serious, assumptions that are only wrong in your context. What changes is that your pentest becomes more valuable, because the tester no longer spends their time reporting outdated components.
Who should own this on our side?
Someone from the development team, not someone from outside it. Security controls imposed by a department alongside the team are experienced as an obstacle and disappear as soon as attention lapses. We therefore work with your developers and make the agreements with them. The security officer is the sponsor and reviewer, and that works better than the other way round.