This article is based on reporting from Infosecurity Magazine covering a talk by security researcher Troy Hunt at the Checkmarx “Shift Left” conference in London.
The Persistent Gap Between Development and Security
Despite years of industry advocacy for “baking in” security from the start, many development teams still treat it as a final-phase activity — something that gets reviewed after the code is written, tested, and nearly ready to ship. The result is predictable: vulnerabilities found late are expensive to fix, disruptive to release schedules, and often negotiated away rather than resolved.
Speaking at the Checkmarx “Shift Left” conference in central London, security researcher Troy Hunt made the case that this pattern is not inevitable — but breaking it requires structural changes to how teams think about, measure, and communicate security.
The Problem with Late-Stage Security Reviews
Hunt pointed out that measuring code security is genuinely difficult. Unlike a failing unit test, a security flaw does not always produce an obvious signal. You can look at code that has already shipped and struggle to determine whether it is safe or subtly broken — until someone exploits it.
What is clear, Hunt argued, is the cost gradient: the later a vulnerability is found, the more expensive it is to address. A flaw caught during design or early development may require a minor code change. The same flaw discovered during a post-release penetration test could require architecture rework, emergency patching, customer notification, and regulatory scrutiny.
Hunt illustrated the problem with a fictional character he called “Vlad” — the security person who arrives at the end of the development cycle bearing bad news about flaws the team no longer has the schedule or budget to properly fix. Vlad is not the villain; Vlad is the symptom of a process that has already failed.
The Standoff Between Developers and Security Teams
A recurring theme in Hunt’s talk was the cultural friction between development and security teams. Security practitioners grow frustrated when developers repeatedly introduce the same classes of vulnerability. Developers feel ambushed when security blocks a release at the last moment. Businesses, caught in the middle, often push for shipping over safety because they do not fully grasp the risk.
Hunt was direct about this: “We have got to be better with the ‘standoffishness’ between developers and security people; we are all trying to achieve the same thing.”
The tension is real, but it is not irresolvable. Both groups share the goal of shipping software that works correctly and does not harm users. The disconnect is usually about process, timing, and communication — not fundamental incompatibility.
What “Shifting Left” Actually Means in Practice
“Shifting left” means moving security activities earlier in the software development lifecycle (SDLC) — ideally starting at the design phase rather than the testing phase. Hunt outlined several concrete practices that support this:
- Developer security training: Developers who understand common vulnerability classes — SQL injection, cross-site scripting, insecure deserialization — are less likely to introduce them in the first place. Training does not need to be deep security expertise; it needs to be enough awareness to recognise dangerous patterns.
- Static code analysis (SAST): Tools that analyse source code without executing it can flag known vulnerability patterns early, ideally integrated directly into the IDE or pull request workflow so feedback is immediate rather than batched into a late-stage report.
- Continuous integration (CI) security gates: Embedding security scans into the CI pipeline means every commit is checked automatically. This normalises security as part of the build process rather than an external audit.
- Dynamic analysis (DAST): Running the application and probing it for vulnerabilities — either through automated scanners or manual testing — catches issues that static analysis misses, such as runtime configuration problems or logic flaws.
- Penetration testing: Hunt was explicit about the value of skilled pentesters. Where automated tools follow known patterns, a good pentester brings creative, adversarial thinking that can surface complex, chained vulnerabilities no scanner would find.
Critically, Hunt framed these not as competing approaches but as complementary layers. No single technique covers everything. Static analysis finds structural flaws; dynamic analysis finds runtime behaviour; penetration testing finds what both miss. Used together, they provide defence in depth for the development process itself.
The Business Reality: Risk, Not Perfection
Hunt acknowledged a practical constraint that security professionals sometimes resist accepting: businesses will ship software that carries some residual risk. The question is not whether to ship imperfect software — it is whether the risks are understood, documented, and mitigated to an acceptable level.
“Businesses don’t understand the nuances of security and want the website to be live, but we know there are vulnerabilities and things may be exploited, so somewhere there has to be compromise,” Hunt said.
This is not a concession to bad practice. It is a recognition that security must operate within business context. The goal of shifting left is not to achieve zero vulnerabilities before any code ships — it is to reduce the attack surface, catch the highest-risk issues early, and establish processes that continuously improve the security posture of a codebase over time.
Key Takeaways for DevOps and Engineering Teams
- Security reviews at the end of the SDLC consistently produce findings that are too late and too expensive to properly remediate.
- Integrating security tooling into CI pipelines (SAST, dependency scanning, secrets detection) is the most scalable way to enforce baseline security hygiene.
- Developer training on secure coding reduces the volume of vulnerabilities introduced, reducing the burden on security teams downstream.
- Dynamic testing and penetration testing remain valuable precisely because they find what automated static analysis cannot.
- The cultural gap between security and development teams is a process problem. Shared metrics, earlier collaboration, and security embedded in definition-of-done criteria all help close it.
- Security involvement should be a continuous activity throughout the development lifecycle, not a gate at the end.
The tools and practices to shift security left exist and are mature. The remaining challenge is predominantly organisational: making security a shared responsibility rather than a specialist’s veto at release time.