Coverage
A source code audit reports what it tested for, not only what it found.
While the agents analyze your code, they also walk a methodology checklist: a list of security checks a reviewer would work through on an application like yours. Every check on that list gets an answer in the report, and a finding is only one of the answers it can get.
Why this exists
Before this, a report could show nothing for a whole class of vulnerability without telling you whether anyone had looked. An empty section read the same way in three very different situations: the class was checked and your code is clean, the class does not apply to your application, or the class was never examined at all.
Coverage separates them. The absence of a finding and the absence of a test are now different lines on the page.
The four answers
Each check on the list comes back with one of these:
| Answer | What it means |
|---|---|
| Tested | The audit examined this check against your code. You get a finding, or a clean result. |
| Already covered | Work the audit had already done answers this check. The report names that work so you can read it. |
| Not applicable | Your application has no surface this check applies to. The report gives the reason in a sentence. |
| Needs a running system | Reading code cannot answer this check. The report says so, and records what led to that decision. |
Put plainly: a check is either tested here, tested somewhere the report points you to, out of scope because your application has nothing to test, or out of reach because source alone cannot settle it. Nothing on the list is left blank.
The checklist is always there
Four methodology packs run on every code audit. They cover web applications, mobile applications, infrastructure as code, and compiled binaries.
AISafe does not ask you to choose between them, because real projects are mixed. A mobile client talks to a web backend, the backend deploys through Terraform, and somewhere in the tree there is a compiled component. Picking one pack up front would mean deciding what your application is before reading it, and getting that wrong is how a whole surface goes unexamined.
So every check runs, and the ones that do not fit your application come back as not applicable with a reason. They are answered, not hidden.
What "not applicable" means
It means the audit looked for the surface a check needs and your application does not have it. The report says which surface is missing, in one sentence a person can read, for example that the repository ships no native code for a binary check to examine.
It never means the audit ran short of time, budget, or patience. Those are not answers, and they are not what this label reports.
Checks that code cannot answer
Some checks depend on how a deployed system behaves rather than on what the source says. Reading code cannot settle them, however carefully you read.
The report marks such a check as needing a running system, and records what produced that decision, rather than passing over it in silence. That tells you where a code audit stops. If those checks matter to you, follow the audit with a service that touches a live target: a Black-Box Pentest or a White-Box Pentest.
Regulated regimes are opt-in
When you start an audit you can tick one or more regulated regimes: the General Data Protection Regulation (GDPR), the Health Insurance Portability and Accountability Act (HIPAA), or the Payment Card Industry Data Security Standard (PCI DSS).
Ticking one adds two things at once: that regime's checks, and the recognition ability that makes them answerable. A check that asks where personal data travels arrives together with the ability to recognize personal data in your code. You cannot select one without the other, and there is no reason to want to, because either half alone answers nothing.
Leave all three unticked and the audit still runs the four always-on packs.
What a regulatory pack adds
Ticking GDPR does not turn the run into "a GDPR audit". It adds checks anchored to the technical articles a code audit can speak to:
- security of processing
- erasure of personal data
- integrity and confidentiality
- data protection by design and by default
It deliberately leaves out the obligations answered by a document rather than by code. Staff training, processor contracts, and breach-notification timelines are real duties under the regulation, and a code audit cannot read any of them. Your report will not mention them, and no result in it should be read as covering them.
HIPAA and PCI DSS work the same way. The checks speak to the technical controls that live in your source. The organizational and procedural controls sit outside what reading code can reach, and the audit says nothing about them.
What this is not
An audit is not an assessment of compliance, and AISafe is not an assessor.
What you get is narrower and more useful than that: findings mapped to control frameworks (see Compliance mapping), plus a record of which methodology checks the audit walked and what each one answered. That record is evidence you or your auditor can read, question, and check against the code.
It is not a judgment about your application's standing under any standard, and nothing in it supports one. Deciding that question is your auditor's job, and the coverage record is one of the things they can read while they do it.