Securing software you built, inherited, or self-host: a senior guide

Last updated: 29 June 2026

A software security review is a structured assessment of an application against recognised standards, run to find the vulnerability classes that actually cause breaches. Whether you built the software, inherited it through an acquisition, or self-host it on your own infrastructure, the method is the same: measure the code and its configuration against a known baseline, then fix what matters first.

Most software now reaches production faster than it is reviewed. It is assembled from open-source components, accelerated by AI coding tools, acquired with a company, or stood up from an open-source project on a server someone in the team manages. Each of those routes is legitimate. None of them, on its own, tells you whether the result is safe to run. A security review is how you find out, and it is the same discipline we apply in a Vibe Code Audit: read the system against a standard, then report what is safe, what must be fixed, and in what order.

This is a senior guide to that review for people who own software and are accountable for it: founders, CTOs, and engineering leaders. It covers what a review is, the vulnerability classes it looks for, how the three starting points (built, inherited, self-hosted) differ, the legal duty behind it in the UK, and how to run one without drowning in noise.

What a software security review actually is

A security review is not a feeling, and it is not a single scanning tool. It is an assessment against a published baseline, so the result is defensible rather than a matter of opinion. Three standards define that baseline, and a credible review draws on them.

The OWASP Application Security Verification Standard (ASVS), version 5.0.0 released in May 2025, is the open standard for what to test in an application's technical security controls. It is written to be used three ways: as a metric for how secure an application is, as guidance for developers building one, and as a list of verification requirements that can be specified during procurement [1]. If you are commissioning a review, ASVS is the thing you can point at and say "test against this".

The NIST Secure Software Development Framework (SSDF, SP 800-218) sets out the practices that reduce vulnerabilities across the whole lifecycle, organised into four groups: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities [2]. It matters here for one practice in particular. SSDF names PW.7, "Review and/or Analyze Human-Readable Code to Identify Vulnerabilities", as a core practice, listed separately from automated testing of executable code [2]. In other words, a federal framework treats a human reading the code as a distinct, necessary step, not an optional extra once the scanners are green. That is the standards basis for the recurring theme of this guide: tools find some things, a senior engineer reading the code finds the rest.

In the UK, the National Cyber Security Centre (NCSC), part of GCHQ, publishes eight principles for secure development and deployment, covering everything from clean and maintainable code to protecting the repository and securing the build and deployment pipeline [3]. They are the local lens on the same idea.

A good review, then, reads your software against these baselines and produces a verdict you can act on. It is the difference between "the tests pass" and "a named engineer has checked this against a recognised standard and signed off what is safe".

The vulnerability classes a review looks for

You cannot review everything at once, and you should not try. A review prioritises the classes of flaw that are both common and damaging. The data-driven spine for this is the OWASP Top 10:2021, built from data across more than 500,000 applications [4]. The same classes recur in real audits, so they are where a review starts.

• Broken access control (the number one category). This covers users being able to act outside their intended permissions: reading another customer's records by changing an ID in a URL (insecure direct object reference), or reaching an admin function without being an admin. OWASP found that 94% of applications tested showed some form of broken access control, with over 318,000 occurrences in its dataset, more than any other category [5]. In our experience it is also the single most common serious finding, because AI tools and junior developers alike write the feature that was asked for ("return the user's orders") without asking which user is allowed to see which orders. It remains the number one category in OWASP's 2025 edition as well [5].
• Injection, including SQL injection and cross-site scripting. Untrusted input that is treated as a command or as markup. OWASP folds cross-site scripting into this category, which covers SQL injection (CWE-89) and XSS (CWE-79) among others [6]. These are not merely historical: on MITRE's CWE Top 25 for 2024, an independent prevalence-and-severity ranking, cross-site scripting ranks number one and SQL injection number three [7].
• Security misconfiguration. Default credentials, verbose error messages, unnecessary features left enabled, missing security headers. OWASP found 90% of applications had some form of misconfiguration [8]. This is the class that scanners and a config review catch quickly, and it is cheap to fix once seen.
• Vulnerable and outdated components. The dependencies you pulled in and stopped tracking. You are exposed the moment you do not know the versions of everything you ship [9]. This is the supply-chain surface, and it is the one that grows on its own while you do nothing.
• Cryptographic failures and authentication failures. Sensitive data sent or stored without proper protection, and weak or broken sign-in: predictable session handling, no rate limiting, passwords stored badly. Both sit high in the Top 10 [4].
• Secrets in the source. API keys, database passwords, and tokens committed into the repository. GitGuardian, a secrets-scanning vendor, reported 23.8 million secrets leaked on public GitHub in 2024, a 25% year-on-year rise [10]. Treat that figure as directional and vendor-measured, but the pattern is one we find in private repositories constantly.

A review works through these systematically rather than chasing whatever the latest scan flagged. The point is coverage of the classes that matter, ranked by impact.

Three starting points: built, inherited, self-hosted

The vulnerability classes are the same wherever software comes from. What changes is where the risk concentrates and what evidence you can demand. Three starting points cover almost everyone.

Software you built (including AI-built)

If your team wrote it, including with AI assistance, the review focuses on the code and the choices in it. The AI-assistance part is worth being clear-eyed about, because the evidence is consistent across independent sources. Veracode's 2025 testing across more than 100 models found that 45% of AI-generated code samples failed security tests and introduced an OWASP Top 10 vulnerability [11]. That is a vendor report, so it is corroborated by two peer-reviewed studies: a Stanford team found that developers with an AI assistant "wrote significantly less secure code" and, tellingly, "were more likely to believe they wrote secure code" [12]; and an NYU study found roughly 40% of 1,689 AI-generated programs were vulnerable across high-risk scenarios [13]. AI raises confidence faster than it raises security, which is exactly why a human review gate matters. We cover this in depth in is AI-generated code safe to ship and what a vibe code audit actually finds.

If the software has AI features of its own (a chatbot, an agent, a retrieval system), the review extends to the OWASP Top 10 for LLM Applications, whose number one risk is prompt injection: user input that alters the model's behaviour in unintended ways [14]. We explain that risk in prompt injection explained and the wider list in the OWASP Top 10 for LLM applications.

Software you inherited

When you acquire a company or take over a codebase, you inherit its security debt without having seen it accrue. There is no single standard for "code due diligence", so the strongest approach combines three. Treat the inherited code as an untrusted supply input and assess it the way the NCSC's supply chain guidance describes, with defined stages rather than a glance [15]. Have the human-readable code reviewed before you build on it, which is exactly the SSDF PW.7 practice [2]. And demand the evidence a responsible producer should already have: CISA's Secure by Design guidance expects vendors to embrace transparency, including maintaining an accurate Software Bill of Materials (SBOM) [16]. If the software you are buying cannot tell you what it is made of, that is itself a finding. This is the security half of the wider technical due diligence a buyer should run.

Software you self-host

If you run open-source software (an agent platform, a database, a CMS) on your own infrastructure, you own its configuration and its patching. Two authoritative inputs make this manageable. CIS Benchmarks give consensus-based secure-configuration baselines across more than 25 product families, so you are hardening against an agreed standard rather than guesswork [17]. And rather than trying to patch everything, prioritise using CISA's Known Exploited Vulnerabilities (KEV) catalog, which CISA describes as "the authoritative source of vulnerabilities that have been exploited in the wild" [18]. Patch what attackers are actually using first. The environment around the software (the repository, the build pipeline, the deployment) is covered by the NCSC principles [3]. We go further on this in self-hosting AI agents and running OpenClaw safely.

Why a review matters: the legal duty and the cost

For UK organisations this is not only good practice, it is a legal duty. UK GDPR Article 32 requires controllers and processors to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk", and it explicitly names "a process for regularly testing, assessing and evaluating the effectiveness" of those measures [19]. A regular security review is one of the clearest ways to meet that obligation. The Information Commissioner's Office frames the same requirement as the "security principle" of the UK GDPR [20].

The cost of skipping it is well documented. Verizon's 2025 Data Breach Investigations Report, the most widely cited breach-cause dataset, found that breaches involving a third party doubled to 30%, and exploitation of vulnerabilities as an initial access route rose by 34% [21]. IBM's 2025 study put the global average cost of a breach at USD 4.4 million [22]. Both are vendor or vendor-sponsored reports, so treat the exact figures as order-of-magnitude, but the direction is not in doubt: the classes a review catches are the classes that breaches exploit.

How to run a review without drowning in noise

A review that returns a 400-page scanner dump helps no one. The senior approach is to make decisions, not lists. In practice that means four things.

Scope it to the surfaces that carry risk. Authentication, authorisation, data access, payments, secrets handling, and any AI feature. These are where the damaging findings live; presentational code rarely is.

Combine tools with a human read. Automated scanning (SAST, dependency scanning, secret scanning) finds the known patterns cheaply. A senior engineer reading the code finds the logic and authorisation flaws that scanners miss, which is precisely why SSDF separates code review (PW.7) from automated testing [2]. Neither replaces the other.

Rank by impact, then exploitability. A broken access control on customer data outranks a missing header on a marketing page. Use the OWASP categories and the KEV catalog to sort, so the first fixes are the ones that move risk most [5][18].

Produce a verdict, not a complaint list. The deliverable is a decision a named engineer is willing to sign: what is safe to ship now, what must be fixed first ranked by severity, and what should be rebuilt rather than patched. That is the output of our Vibe Code Audit, and it is what makes a review actionable.

A review is not a one-off, either. Article 32's "regularly testing" language is deliberate [19]: software, dependencies, and threats all change, so the review is repeated, not framed and forgotten.

Frequently asked questions

What is a software security review?

It is a structured assessment of an application against recognised standards such as OWASP ASVS, the NIST SSDF, and NCSC guidance, run to identify the vulnerability classes most likely to cause a breach. It combines automated scanning with a senior engineer reading the code, and produces a ranked, actionable verdict rather than a raw tool report.

How is a security review different from a penetration test?

A penetration test attacks the running system from the outside to find exploitable holes. A security review reads the code, configuration, and dependencies against a standard to find weaknesses by class, including ones a pen test would not reach. They are complementary: the review explains why a flaw exists and how widespread the pattern is; the pen test proves a specific one is exploitable.

Does AI-generated code need a security review?

Yes, arguably more than hand-written code. Independent studies found that a large share of AI-generated code contains classic vulnerabilities: Veracode reported 45% of samples introduced an OWASP Top 10 flaw, and academic work from Stanford and NYU reached the same conclusion. AI tools also raise developer confidence, so the output looks finished while carrying the usual flaws. A review is how you separate the two.

How often should we run a security review?

UK GDPR Article 32 requires "regularly testing, assessing and evaluating" your security measures, so a review is recurring rather than one-off. In practice, review before a major release, after a significant change to access control or data handling, when you inherit a codebase, and on a periodic schedule for software in production. The right interval depends on how fast the software and its risk change.

We inherited a codebase in an acquisition. Where do we start?

Treat it as an untrusted supply input. Assess it using the NCSC's supply chain approach, have the human-readable code reviewed before building on it (the SSDF PW.7 practice), and demand a Software Bill of Materials so you know what it is made of. If the seller cannot tell you what the software contains or show evidence of secure development, that gap is itself a material finding.

What does a security review actually deliver?

A clear verdict, not a list of complaints: what is safe to ship now, what must be fixed first ranked by severity, and what should be rebuilt rather than patched, each tied to the standard it relates to. The value is the decision a named senior engineer is willing to sign, so you can act on it with confidence and evidence.

Get a senior review of your software

If you own software you built, inherited, or self-host, and you need to know honestly where it stands, a senior engineer can review it against these standards and put a name to the verdict. Our flagship Vibe Code Audit does exactly that for AI-built and AI-accelerated software, and our Ongoing Support keeps the review going as the software changes. Book an audit and we will tell you what we find.

Sources

1. OWASP Foundation, "Application Security Verification Standard (ASVS) 5.0.0", released 30 May 2025. https://owasp.org/www-project-application-security-verification-standard/
2. NIST, "Secure Software Development Framework (SSDF) Version 1.1", SP 800-218, February 2022 (practice PW.7, "Review and/or Analyze Human-Readable Code"). https://csrc.nist.gov/pubs/sp/800/218/final
3. National Cyber Security Centre, "Secure development and deployment guidance" (eight principles), 2018. https://www.ncsc.gov.uk/collection/developers-collection/principles
4. OWASP Foundation, "OWASP Top 10:2021 - Introduction" (methodology; data from over 500,000 applications), 2021. https://owasp.org/Top10/2021/A00_2021_Introduction/
5. OWASP Foundation, "A01:2021 - Broken Access Control" (94% of applications tested; over 318k occurrences). https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
6. OWASP Foundation, "A03:2021 - Injection" (cross-site scripting now part of this category). https://owasp.org/Top10/2021/A03_2021-Injection/
7. MITRE / CISA, "2024 CWE Top 25 Most Dangerous Software Weaknesses" (CWE-79 ranked #1, CWE-89 ranked #3). https://cwe.mitre.org/top25/archive/2024/2024_top25_list.html
8. OWASP Foundation, "A05:2021 - Security Misconfiguration" (90% of applications). https://owasp.org/Top10/2021/A05_2021-Security_Misconfiguration/
9. OWASP Foundation, "A06:2021 - Vulnerable and Outdated Components". https://owasp.org/Top10/2021/A06_2021-Vulnerable_and_Outdated_Components/
10. GitGuardian, "The State of Secrets Sprawl 2025" (23.8 million secrets leaked on public GitHub in 2024), 11 March 2025. https://blog.gitguardian.com/the-state-of-secrets-sprawl-2025/
11. Veracode, "2025 GenAI Code Security Report" (45% of code samples introduced an OWASP Top 10 vulnerability), 30 July 2025. https://www.veracode.com/blog/genai-code-security-report/
12. Perry, Srivastava, Kumar and Boneh, "Do Users Write More Insecure Code with AI Assistants?", ACM CCS 2023, arXiv:2211.03622. https://arxiv.org/abs/2211.03622
13. Pearce, Ahmad, Tan, Dolan-Gavitt and Karri, "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions", IEEE Symposium on Security and Privacy 2022, arXiv:2108.09293. https://arxiv.org/abs/2108.09293
14. OWASP Gen AI Security Project, "OWASP Top 10 for LLM Applications 2025 - LLM01: Prompt Injection". https://genai.owasp.org/llmrisk/llm01-prompt-injection/
15. National Cyber Security Centre, "How to assess and gain confidence in your supply chain cyber security", 12 October 2022. https://www.ncsc.gov.uk/collection/assess-supply-chain-cyber-security
16. CISA and international partners (including NCSC), "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software", updated October 2023. https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf
17. Center for Internet Security, "CIS Benchmarks" (consensus secure-configuration baselines). https://www.cisecurity.org/cis-benchmarks
18. CISA, "Known Exploited Vulnerabilities Catalog" ("the authoritative source of vulnerabilities that have been exploited in the wild"). https://www.cisa.gov/known-exploited-vulnerabilities-catalog
19. legislation.gov.uk, "UK GDPR, Article 32: Security of processing". https://www.legislation.gov.uk/eur/2016/679/article/32
20. Information Commissioner's Office, "A guide to data security" (the "security principle"). https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/
21. Verizon Business, "2025 Data Breach Investigations Report" (third-party involvement doubled to 30%; vulnerability exploitation up 34%). https://www.verizon.com/business/resources/reports/2025-dbir-data-breach-investigations-report.pdf
22. IBM, "Cost of a Data Breach Report 2025" (global average breach cost USD 4.4 million). https://www.ibm.com/reports/data-breach