Nick Vincent from Pearson shares one of the best real-world devsecops stories I have heard. Pearson was already in the middle of a devops and agile transformation when they recognized security needed to come into the fold. They hired Nick to build a security engineering function from scratch – and what he built is a model worth studying.
The approach started with understanding. Before doing anything, his team mapped out what each development team was building, their tech stack, and their capabilities. Then came threat modeling – not as a one-time exercise but as a continuous practice. This mirrors what I have seen across devops history: the conversation changes everything. Just like TDD is really about changing your architecture through dialogue, threat modeling surfaces the real security concerns and makes them neutral territory for discussion. You point at the board, not at each other.
Scaling was the real challenge. With only eight security engineers supporting over 300 teams, they built a security champions program – nominating a developer in each team to own security there. They created self-service onboarding, operationalized security testing tools as internal services (static analysis, dependency scanning, DAST, RASP), and documented everything in Confluence. Each service had its own functional owner responsible for choosing the right tooling and creating training material.
The metrics story was particularly sharp. Traditional vulnerability stats create false representations – a high-performing team with good processes shows few detections, which looks identical to a team that simply is not scanning. Pearson solved this by combining threat model risk tracking, a security maturity questionnaire (13 questions across three sections, scale of 1-4), and operational vulnerability data. Together these gave context that any single metric alone could not provide.
The engagement model followed three stages: discover and threat-model, implement security measures with coaching, then establish continuous monitoring and incident response. They treated it as a continuous cycle – any new feature or major refactor kicked off fresh threat modeling. The key insight: making security processes dev-first and minimizing the delta of work needed to reach the desired state removed enormous friction with product owners worried about deadlines.
Watch on YouTube – available on the jedi4ever channel
This summary was generated using AI based on the auto-generated transcript.