Thank you for opening up the latest article in 'The Intelligent Commit' newsletter, my thoughts, research and analysis on Artificial Intelligence and how AI is reshaping the software development lifecycle. I hope you find it insightful, subscribe, and engage.

This is the second in a three-part series about the findings from my master's dissertation on the security of LLM-generated code.

For my Master's research dissertation, I chose a subject that sits directly between my studies and my work in engineering leadership: what happens to software security when more of the code is generated by AI?

AI coding assistants are having a dramatic effect on how developers produce working software. What is less clear is whether the developer's own experience and knowledge - in this case their security expertise - still matters now that an LLM is writing the code. That is what I set out to test, and the answer was a clear yes: a developer who spells out the security requirements gets back noticeably safer code.

Comparing functional and security-aware prompts

Two of the three conditions in my study speak to this directly. Both used the same LLM and the same baseline prompts, and both worked through the same set of 100 tasks, building the same 18 products and end-user applications drawn from public tutorials and videos.

The baseline simulated naive "vibe coding". Its prompts focused on functionality, in the style of those public tutorials aimed at non-programmers building applications with AI - and, just like the tutorials being replicated, they did not mention security or vulnerabilities once.

The security-aware condition kept the same tasks, model and baseline prompts, but appended guidance drawn from the OWASP Top 10 and the MITRE CWE categories relevant to each task. This simulated a developer who understood the likely risks and made those expectations explicit to the LLM.

After producing the applications I scanned the generated code, then reviewed and suppressed false positives before analysing and classifying the vulnerabilities. The difference was significant.

The baseline vibe-coding condition produced 13 vulnerabilities per thousand lines of code. When the developer provided the additional security context, vulnerability density fell by 60%.

The proportion of applications containing at least one critical or high-severity vulnerability fell from 78% to 44%.

And that was not the only significant finding. The proportion of applications containing at least one critical or high-severity vulnerability also fell, from 78% to 44%. For organisations that prioritise remediating critical and high findings - and many do - that is a significant difference.

At this point you may be concerned that your models are writing insecure code at all. I agree, it is quite alarming, isn't it? I did not set out to test or prove that, because it has been heavily researched already - and sadly, yes, it is well established that even the latest frontier models generate insecure code. But without doubt, it is now clear that setting out clear security expectations has a demonstrable positive impact on the code a model produces.

Getting the context right matters

It is tempting to treat prompting as a conversational skill: ask clearly, provide context, refine the answer. For code generation, my study confirmed that the context needs to include the qualities the software must adhere to.

A functional prompt might specify that users can upload a file. A security-aware prompt also constrains file type, size, storage location and filename handling. A request for authentication needs to cover password storage, session behaviour and rate limiting. That extra context comes from secure-development knowledge - just as you would explain it to a junior developer.

A better prompt cannot guarantee secure code, but it can materially improve the odds.

The 60% reduction is encouraging. But while security-aware prompting improved the output, it does not make scanning, testing or code review unnecessary.

It is worth noting that the research community continues to look at this. A twin-prompt study of six web applications found much the same thing - every serious flaw it confirmed sat in the version built from the plain specification, which I covered in Nobody asked for secure code, so nobody got it. A more recent journal paper similarly found that effective prompt engineering reduces vulnerabilities. Yet there is also evidence from another study that adding security guidance to the prompt changed which kinds of flaw appeared without reducing how many there were. What I found in my own research is what I have set out here, but that does not mean the story ends with it.

AI assistance has created another point at which security knowledge affects software. We can leave that knowledge in an individual's head, or we can make it part of the tools and defaults used by the whole team.

The final article in this series examines the next step: moving security review out of prompt guidance and into the architecture of the development workflow itself. If you have not read it yet, the first article covers the finding that gave the series its name.

Thank you for reading my latest article. Please share your experiences and engage with the discussion - I am not always right, but I try to be insightful and thought-provoking.

  • Does anyone on your team write security requirements into their prompts today, or is it left to whoever happens to know?
  • If you reviewed last week's prompts, how many described behaviour only, and how many described the qualities the code had to hold to?
  • Where does that knowledge live in your organisation - in people's heads, in a wiki nobody opens, or in the tooling itself?

Please reach out if you'd like to continue the discussion.