Software Quality is less than half the story

TL;DR: AI is great at writing functional code. Thoughtful prompting pushes it further — reliability, maintainability, security. But even nailing all nine ISO 25010 quality characteristics addresses only 30% of security controls. The other 70% isn’t in the codebase at all.

Building a functional app #

More people than ever are creating software. If you know your product domain, you can team up with GenAI and start writing code. Whether you’re vibe-coding all the way and never read a line, or whether you meticulously review every change and understand it all - chances are that you’ll create a highly functional app That Works on My Your Machine™️.

Next you want to share or monetise the app. You might consider - is my app sufficient quality to put on the public internet?

Software Quality #

If you’ve read my blog before you’ll know I care about software quality. You might think the next step is to take ISO 25010:2023 as a prompt and get GenAI to fix all of your issues. Give it a go - ask it to interview you and help discover all your Non-Functional Requirements and come up with a plan for addressing them.

Infrastructure #

As you go through the NFRs you realise they feel out of your control. You’ve written the application code but some of the software quality characteristics are not application code; particularly reliability and security.

Who monitors the app 24/7, runs the database, ensures the servers are healthy and can handle the scale. Who secures the firewall, patches the software and access control?

The Realisation #

You start to realise that writing application code is actually a relatively small part of operating high quality software, infrastructure is equally important and that security is a broad subject.

If you look into Cyber (or Information Security) you will see that there are many competing frameworks/standards: Cyber Essentials, ISO 27001, SOC 2 etc. and that they appear to explode in scope to include Physical Environment, People and Organisational.

You will realise that most of these controls aren’t about code at all. They are about firewalls, policies, training, supplier contracts. Things that you cannot fix with a better prompt.

So I ran the numbers. I mapped 77 canonical security controls across eight industry frameworks — Cyber Essentials, ISO 27001, NIST CSF, NIST SSDF, CIS Controls, SOC 2, NCSC CAF, and ISO 42001. Then I classified each control by where it lives: application, infrastructure, or organisational.

The results may surprise you!

30% #

pie title 77 Security Controls by Layer
    "Application: 23 (30%)" : 23
    "Infrastructure: 19 (25%)" : 19
    "Organisational: 35 (45%)" : 35

An AI-assisted, quality-focused codebase covers less than a third of the security picture. The three layers:

• Application: your code, your dependencies, your tests — secure coding, input validation, code review, dependency management, threat modelling
• Infrastructure: platform, network, configuration, endpoints — firewalls, patching, antimalware, encryption, backups
• Organisational: people, governance, legal, operations — policies, training, incident response, supplier management, background checks

What’s NOT in the Prompt #

This is the part that stopped me cold. No prompt fixes these. No code covers them:

What’s missing	Why it matters
Security awareness training	Human factor
Incident response plans	When things go wrong
Supplier due diligence	Third-party risk
Background checks	Insider threat
Physical security	Device theft
Business continuity planning	Keeping the lights on
Risk assessment	Knowing what to protect
Termination procedures	Access revocation
Privacy notice	Saying what you collect
Consent and lawful basis	Permission to process
Data subject rights	Access, correction, deletion
Breach notification	A 72-hour clock

You can tell Claude to write secure code all day long. It won’t help when someone clicks a phishing link. It won’t help when a contractor keeps access after leaving. It won’t help when the S3 bucket is public because someone misconfigured it in the console. And it won’t help when the droplet you deployed to eight months ago is three versions behind on security patches.

Even with gold-standard code, compromises come from phishing, credential theft, misconfiguration, insider threats, and software you didn’t write. The application layer is necessary — but it’s not where most attacks land.

Risk Acceptance #

Nobody does all 77 controls. That’s not the point.

The point is knowing they exist — and consciously deciding which ones you’re accepting risk on. There’s a difference between “we’ve looked at background checks and accepted the risk” and “wait, background checks are a security control?”

If the app never leaves localhost:3000, there’s not much to argue about. No deployment, no infrastructure, no attack surface. Nothing at stake, nothing to protect.

The moment it’s shared, the stakes change:

Stage	What’s at stake
Personal (localhost)	Nothing
Shared (friends, colleagues)	Reputation
Public (users on the internet)	Trust, personal data, legal duties
Commercial (customer data, payments)	Money, contractual liability, career

Note where the legal duties start. UK GDPR attaches the moment you hold real people’s personal data — not the moment you start charging for it. A lawful basis for processing, a privacy notice, subject access requests, a 72-hour breach notification clock: all of that lands on the free side of the line. Privacy is the second-largest group of controls in this whole set, and not one of them is code.

Higher stakes don’t mean you need all 77 controls. They mean you need to consciously decide which risks you’re accepting — rather than accidentally skipping controls you didn’t know existed.

The jump from localhost to deployment is where the infrastructure layer kicks in. That can be manual — click-ops in a cloud console, hoping the security groups are locked down — or automated with infrastructure as code (Terraform, Helm, CI/CD). Either way, it’s a different discipline. The AI wrote the app. It didn’t write the deployment.

And even with IaC for everything, you’re now a platform engineer as well as a product developer. Different skills, different concerns, different controls.

Building secure platforms is hard and is not an afterthought once you’ve built your application. If you don’t have a dedicated platform team, buy rather than build — a PaaS like Vercel or Render transfers a huge chunk of your infrastructure controls to a mature, full-time provider. That’s not avoiding security; it’s transferring risk to someone better equipped to handle it.

The Framework Landscape #

Maybe this is just my selection of frameworks? Maybe I picked ones that happen to be infrastructure-heavy?

So I broke it down. Different frameworks emphasise different layers — some are code-focused, some are governance-focused, some are infrastructure-focused. Here’s how each of the eight frameworks breaks down:

Framework	Controls	App	Infra	Org	Focus
NIST SSDF	16	88%	6%	6%	Secure software development
CIS Controls	36	47%	39%	14%	Technical hygiene
NCSC CAF	30	43%	33%	23%	Critical infrastructure
ISO 42001	13	38%	8%	54%	AI systems governance
ISO 27001	65	31%	29%	40%	Comprehensive ISMS
NIST CSF	41	22%	46%	32%	Risk management framework
SOC 2	50	20%	22%	58%	Trust services criteria
Cyber Essentials	12	0%	100%	0%	UK baseline certification

Look at the spread. NIST SSDF — the Secure Software Development Framework — is 88% application-focused. If I’m building software and want code-level guidance, that’s where it lives. It’s literally in the name.

But NIST SSDF is the outlier. Most frameworks aren’t about code.

Cyber Essentials is 100% infrastructure — firewalls, patching, secure configuration, endpoint protection. The UK government’s baseline certification for organisations doesn’t require writing a single line of code. You could pass Cyber Essentials with an off-the-shelf WordPress site, as long as your infrastructure is locked down.

SOC 2 is 58% organisational — policies, governance, and operational controls for service providers. It cares about how you run your business, not how you write your code.

ISO 27001 — the comprehensive one, the gold standard for information security management — reaches more of these controls than any other framework here, 65 of the 77, and still puts under a third of them in the application layer.

The point isn’t that one framework is right. It’s that the broadest three here — ISO 27001, SOC 2 and NIST CSF, the ones trying to cover a whole organisation — put 31%, 20% and 22% into the application layer. The frameworks that score higher are the narrow ones: SSDF is a secure-development standard, and Cyber Essentials covers five technical themes. Breadth and code-focus pull against each other.

One caveat on the maths: counting controls measures breadth, not effort or risk. “Secure coding practices” is one control. So is “background checks”. They aren’t equivalent in cost, complexity, or how much they reduce your exposure. The 30% is a map of where the controls live — not a budget for where to spend your time.

One specific worth naming. Cyber Essentials’ user access control theme is counted as infrastructure rather than application, because it certifies how an organisation administers accounts rather than how developers write auth code — that single decision is what produces the 0%.

The Path Forward #

flowchart TB
    app["<b>Layer 1: Application — 30%</b><br/>Secure coding · Dependency management<br/>Security testing · Code review"]
    infra["<b>Layer 2: Infrastructure — 25%</b><br/>Firewalls & network · Patch management<br/>Secure configuration · Endpoint protection"]
    org["<b>Layer 3: Organisational — 45%</b><br/>Policies & governance · People & training<br/>Supplier management · Incident response"]
    app --> infra --> org

• Layer 1 — Application: Quality code is essential. This is where AI-assisted development lives. Secure coding practices, dependency management, testing, code review. Necessary — but layer one.
• Layer 2 — Infrastructure: Firewalls, patching, secure configuration, antimalware. Without this, code quality is almost irrelevant.
• Layer 3 — Organisational: Policies, training, incident response, supplier management, governance. The human and process layer that wraps everything else.

The Landing #

AI gets you functional.

Quality-conscious prompting gets you further.

Neither gets you secure.

High-quality software is necessary. It’s not sufficient. The codebase is less than a third of the security picture — and for baseline security, it might not even be the first third to focus on.

When someone asks you to “review the code and confirm it’s secure,” the code was never the whole question.

---

Two interactive tools sit behind this analysis. Software Quality Meets Cyber Security maps 77 canonical controls across eight frameworks to ISO 25010 quality characteristics. Security Controls by Layer compares how each framework splits across application, infrastructure and organisational controls.