DevSecOps when security review is a gate, not a step

In much of the public sector work we do, the security team does not sit in the sprint. They are a separate function with a statutory role, a queue and the authority to stop a release. Enthusiasm about shifting left does not change any of that, and treating the gate as an obstacle to route around is how suppliers get themselves quietly dropped from a framework.

The workable position is to accept the gate as a fixed feature of the terrain, then build the pipeline so that arriving at it is uneventful.

The assessment is a review of evidence

A formal security assessment is, in practice, a document review. The assessor checks that a set of artefacts exists, is current, and agrees with itself: an architecture description, data flows, a threat model, a dependency inventory with known vulnerabilities listed, test results, and a record of what was fixed against what was accepted as residual risk and by whom.

Almost all of that can be produced by the build. Generated on every run, the evidence pack is a snapshot of a specific commit rather than a fortnight of somebody assembling screenshots. We have watched a team lose three weeks to that assembly exercise and then find the screenshots came from a build that had since been superseded, which meant doing it again.

Agree what counts as a material change

Teams new to this environment assume every release needs the full assessment, so they batch changes into large quarterly drops, which are exactly the releases most likely to go wrong. In our experience the assumption is usually untested.

A patch that touches no interface, no data flow, no dependency and no privilege boundary generally does not require a full reassessment, and most security functions will put that in writing if someone asks them to define it. On more than one programme, nobody ever had. Getting a written definition of a material change, with worked examples, is an afternoon of work that can be worth a month of schedule every year.

Findings go in the same backlog as everything else

The pattern in struggling programmes is a findings spreadsheet living outside the tracker, owned by nobody in particular, reviewed monthly by people who did not write the code. Items age. The same issue reappears in three consecutive assessments with slightly different wording each time, and eventually gets accepted as risk because arguing about it has become more expensive than the fix.

We import findings into the delivery backlog with the same states, the same estimation and the same review as feature work, and give the security function read access to it. This sounds like a triviality. It is the single change that has most improved audit outcomes on the programmes we run.

Where we got it wrong

Our recurring mistake is automating too early. On one government programme we built an elaborate policy-as-code layer before we understood which controls the assessor actually tested. A good half of it checked things nobody ever looked at, and the controls that carried real weight still needed evidence assembled by hand. It was satisfying engineering and it saved nobody any time.

We now sit through one full assessment cycle before automating anything, take notes on what was examined and in what format, and automate that. The framework document describes what could be asked. The assessor decides what actually is.

Clearance belongs on the critical path

One dependency catches suppliers new to this work more than any other. Personnel clearance has a lead time measured in months, and a staffing plan that assumes an engineer can be swapped in at short notice does not survive contact with a programme where everyone touching the environment must be vetted. Clearance goes on the plan as a dated dependency, next to the assessment slot, and it is one of the reasons rotation in these accounts is planned a year ahead.

A formal security stage exists because someone concluded that a citizen-facing system needs an independent check before it goes live. That judgement is correct, and the programmes that fight it are usually the ones that most needed it. The engineering task is to make the check cheap and repeatable. A dull assessment is a passed assessment.