How to Audit Code You Cannot Read: A Founder’s Checklist

Key Takeaways

Six artifacts a non-technical founder can verify without reading a line of code, and how to read a security report without panicking.

• You cannot judge code quality without an engineer. You can judge whether the code produces the evidence a healthy project produces.
• The clean checkout test outranks every opinion. If a stranger cannot run it from the written instructions, nothing else is measurable yet.
• OWASP’s 2025 list put Software Supply Chain Failures at A03, which means your inherited dependencies are now a named top-three risk.
• A scanner’s severity count is not a priority list. Severity describes the vulnerability. Exposure describes your product.
• GitHub states plainly that Dependabot “doesn’t scan archived repositories,” so an abandoned repo reports zero problems by design.

The fastest useful code audit a non-technical founder can run takes about forty minutes and involves no code. You ask for six artifacts, and you note which ones do not exist.

That is not a trick. A project that was built carefully leaves evidence behind: a readable setup document, a test suite, a dependency report, a license list, a deploy anyone can run, and a record of decisions. Missing evidence is itself a finding, and it is a finding you are qualified to make.

Here is the honest frame. You cannot assess whether the code is well written. You can assess whether it is verifiable, whether anyone other than the author can run it, and whether the known risks in it have been looked at. Those three answers decide most of what you need to decide.

Accept what you cannot check, then audit what you can

Separate the two lists before you start. Confusing them is why founders either overpay for an audit or skip one entirely.

Quick Verdict: Do not try to judge the code. Judge the evidence around it, starting with whether a stranger can build and run the project from its own written instructions. Velcod does this as part of web application development, and once you have the findings, deciding whether to harden it or rebuild it is the next question.

Call it THE OUTSIDE AUDIT. You are not reading the code. You are reading what the code produces, and that output is objective in a way an opinion about architecture never is.

You can check this yourself	This needs an engineer
Does it build from a clean checkout	Is the architecture appropriate
Do tests exist, and do they pass	Are the tests meaningful
Is there a dependency vulnerability report	Is a given finding reachable in your code
Are the licenses listed and compatible	Is the data model correct
Can someone other than the author deploy it	Is the code readable to a new hire
Are decisions written down anywhere	Will this scale to your next tier

The left column is not a consolation prize. Every item on it is a yes or no answer, every one of them is cheap to get, and a project failing three of them is in trouble regardless of how elegant the code turns out to be.

Do this: Copy the left column into a document and leave the right column for whoever you hire. You now have an audit scope.

Run the clean checkout test before anything else

One test, about an hour of someone’s time, and it reorders everything that follows.

Hand the repository and its setup document to a competent developer who has never seen the project. Ask them to get it running on their own machine using only what is written down. Do not let them ask the original author a single question.

The result is one of three things. It runs, which is a strong signal. It runs after a few undocumented steps, which is normal and tells you the setup document needs an hour of work. Or it does not run at all, which means nobody can verify anything about this project yet, including the person who wrote it.

That third outcome is more common than founders expect. It usually means the project only ever ran on one machine, which also means nobody has tested the instructions a future hire will depend on.

Do this: Pay a developer for two hours to attempt a cold setup and write down every step that was not in the document. That list is your first deliverable from the next team.

Ask for the six artifacts by name

Specific requests get specific answers. Asking “is the code good” gets you reassurance.

Send the list below as a written request and give a deadline. A team in good shape produces most of it the same day, because these are files that already exist rather than documents someone has to write.

Artifact	What its absence tells you	How you read it
Setup document	Nobody has onboarded anyone	Try the clean checkout test
Test run output	Changes cannot be made safely	Look for a pass count above zero
Dependency vulnerability report	Nobody has looked at known risks	Count the critical and high entries
License list	Legal exposure was never checked	Scan for copyleft licenses
Deploy record	Releases depend on one person	Check who ran the last five
Decision record	The reasoning is gone	Any dated file beats none

The two most informative requests are the deploy record and the decision record. If the last five deployments were all run by the same person, you have a key-person risk whatever the code looks like. If no decisions were ever written down, every architectural argument you have in the next year will start from zero. The same pattern shows up in inherited internal systems such as a custom ERP, where undocumented choices outlive the people who made them.

Do this: Send the six requests in one email with a date on it. Note what arrives, what is promised, and what nobody mentions.

Read the dependency report without panicking

A long vulnerability list is normal. A long list nobody has triaged is the actual finding.

Dependency scanners report known weaknesses in the packages your product depends on. GitHub’s documentation describes Dependabot alerts as a feature that helps you “find and fix vulnerable dependencies before they become security risks,” and says each alert includes “A link to the affected file,” “Details about the vulnerability and its severity,” and “Information about a fixed version (when available).”

Two cautions change how you read the number. GitHub states that “Dependabot doesn’t scan archived repositories,” so an abandoned project reports a clean slate by design rather than by merit. GitHub also says plainly that “Alerts can’t catch every security issue,” which means a short list is not a certificate.

Call it THE SEVERITY TRAP. Severity is a property of the vulnerability in general. Exposure is a property of your product in particular, and only the second one tells you what to fix this week.

Finding	Why severity alone misleads
Critical in a build-time tool	Never runs in production
Medium in your login path	Sits on the route attackers try first
High in an unused code path	Real, but not reachable from your app
Low in a library handling payments	Your blast radius is money

Context decides the order, and regulated data changes it again. A medium finding in a product handling patient records is not a medium problem, which is why building a HIPAA compliant web application starts from a different baseline than a general consumer app.

Do this: Ask for the report plus one sentence per critical and high finding saying whether it is reachable from your running product. The sentences are the audit.

Check the licenses before you check the architecture

License problems are the cheapest serious risk to find and the most expensive to discover late.

Your product almost certainly includes open source packages, and some open source licenses carry obligations that conflict with selling closed software. Copyleft licenses are the ones to look for, because they can require you to offer your own source code to anyone you distribute to. Network-facing variants extend that to users who merely interact with your service over a network.

The artifact you want here is a software bill of materials. NTIA’s report on the minimum elements of an SBOM, published 12 July 2021, sets out three categories: “Data Fields,” “Automation Support,” and “Practices and Processes,” describing them respectively as “Documenting baseline information about each component that should be tracked,” “Allowing for scaling across the software ecosystem through automatic generation and machine-readability,” and “Defining the operations of SBOM requests, generation and use.”

In plain terms, ask for a machine-generated list of every component and its license. Then have a lawyer look at anything copyleft before you raise money or sign an enterprise contract, because both processes will ask.

Do this: Request a generated component and license list, not a hand-written one. A hand-written list is a claim. A generated one is evidence.

Separate a choice from a defect

This is where founders get the most bad advice, usually from the next developer in the chair.

A new engineer looking at inherited code will find things they would have done differently. That is not the same as finding something wrong. The test is whether the thing causes a problem you can name: a bug, a security exposure, a cost, or a change that is impossible to make safely.

OWASP’s current list is a useful boundary for this conversation. The OWASP Top 10:2025 names A01:2025 Broken Access Control, A02:2025 Security Misconfiguration, and A03:2025 Software Supply Chain Failures as its top three categories, with Injection at A05 and Insecure Design at A06. Those are defects in anyone’s language.

So is anything on the 2025 CWE Top 25, whose page was last updated 15 December 2025 and which ranks CWE-79 cross-site scripting first, CWE-89 SQL injection second, CWE-352 cross-site request forgery third, and CWE-862 missing authorization fourth. A framework choice you dislike is not on either list.

The distinction gets harder with machine-written code, which now makes up a meaningful share of what gets handed over. Code generated quickly can be correct and still carry no reasoning behind it, which is a documentation problem rather than a defect, and it is worth asking about directly on any recent AI app development project.

Do this: For every criticism in your audit report, ask which named problem it causes. Findings that survive that question are the report.

Hire the auditor, then grade the report

An audit is only as useful as the report, and reports vary more than the audits behind them.

Expect a written document with findings ranked by what they would cost you, each one naming the file or component, the risk in plain English, and an estimate to fix. Expect an explicit statement of what was not examined. A report with no stated limits is marketing.

NIST’s Secure Software Development Framework, defined in SP 800-218, describes a set of “fundamental, sound, and secure software development practices” intended to help producers “reduce the number of vulnerabilities in released software.” A good auditor can tell you which of those practices your project does and does not follow, in your language rather than theirs.

Price it before you commission it. A focused audit on a small codebase is days of work, not weeks, and an auditor who cannot scope it after seeing the repository is telling you something. Our case studies include the findings we started from, because the report is the part that gets reused.

Do this: Ask for a sample redacted report before you hire. If none exists, ask what the deliverable will contain, in writing.

What this will not tell you

The outside audit is a filter, not a verdict. It catches the problems that leave traces.

It does not tell you whether the code is maintainable. That needs a developer to read it and form a judgment, and judgments vary between competent people. The six artifacts tell you whether such a judgment is even possible yet.

It also does not prove the product is secure. GitHub says it directly about its own tooling: “Alerts can’t catch every security issue.” A clean dependency report means the known problems in known packages were checked, which is a narrower claim than safety.

And it will not tell you the cost to finish. That needs scope, and scope needs a decision about what you are building next, which no audit can make for you. Anyone quoting a build price off an audit report alone is guessing.

The forty-minute version

Six questions, in this order. None of them requires you to read code.

• Can a developer who has never seen this project run it from the written instructions?
• Do tests exist, and what does a test run actually print?
• Is there a dependency vulnerability report, and has anyone triaged it?
• Is there a generated list of components and their licenses?
• Who ran the last five deployments, and could anyone else?
• Is there a single dated document explaining why anything was built the way it was?

Ask all six in writing. The pattern of what arrives, what gets promised, and what nobody mentions is most of your answer, and this is the same list we start from before any web app build we inherit.

Where we fit

We audit inherited codebases and we also build, which means we are the wrong people to ask whether a rebuild is necessary without a second opinion.

What we can do honestly is the outside audit, delivered as a written report with findings ranked by cost, each one naming the component and the named problem it causes, plus an explicit list of what we did not examine. You keep the report whether or not we do the work that follows.

This is not always worth buying. If the build is small and the original developer is available and cooperative, a conversation and a clean checkout test will tell you most of it for free. If you are mid-acquisition, you want an independent auditor with no interest in the build contract.

If you want the six artifacts chased down and graded this week, book a call with us and send whatever repository access you have.

Frequently Asked Questions

How much does a code audit cost?

Scope drives it more than codebase size. A focused outside audit covering build verification, dependencies, licenses and deploy risk is usually days of work rather than weeks. A full architectural and line-level review is a different purchase. Ask any auditor to quote the two separately so you can buy the cheaper one first.

Can I audit code without a technical background?

You can audit the evidence, not the code. Six artifacts tell you whether the project is verifiable: a setup document, a test run, a dependency report, a license list, a deploy record and a decision record. Missing artifacts are findings you are qualified to make. Judging code quality still needs an engineer.

What is the difference between a code audit and technical due diligence?

A code audit examines the software itself. Technical due diligence is broader and usually runs during an investment or acquisition, covering the team, the processes, the infrastructure and the roadmap alongside the code. The checklist here is the software half, and it is the half that most reports treat too briefly.

Should I use an automated tool instead of hiring someone?

Use both, in that order. Automated scanners produce the dependency report and the license list cheaply and well, and you should ask for their raw output. What they cannot do is tell you whether a finding is reachable in your product, which is the judgment you are paying a person for.

How do I know if the audit report is any good?

It names files or components, ranks findings by what they would cost you, and states what was not examined. It separates defects from preferences. If every finding is a framework the auditor would have chosen differently, you bought an opinion. Ask for a redacted sample before you commission the work.

Resources

• OWASP Top 10:2025, OWASP Foundation. The current ten categories, including Software Supply Chain Failures at A03, used here as the boundary between a defect and a preference.
• 2025 CWE Top 25 Most Dangerous Software Weaknesses, MITRE. The ranked weakness list, page last updated 15 December 2025, used for the same boundary.
• Dependabot alerts, GitHub Docs. What an alert contains, the fact that archived repositories are not scanned, and the explicit limit that alerts cannot catch every issue.
• NTIA Releases Minimum Elements for a Software Bill of Materials, National Telecommunications and Information Administration, 12 July 2021. The three minimum element categories behind the component and license request.
• Secure Software Development Framework, NIST. SSDF version 1.1 as defined in SP 800-218, used as the practice set a good auditor can grade you against.