Coverage
A source code audit report lists the security checks the audit performed, as well as the vulnerabilities it found.
While the agents analyze your code, they also work through a methodology checklist: a list of security checks a reviewer would perform on an application like yours. The report gives an answer for every check on that list, and a finding is only one of the answers a check can get.
Why this exists
Before coverage existed, a report could show nothing for a whole class of vulnerability without telling you whether anyone had looked for it. An empty section looked the same 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 lets you tell these situations apart. The report now shows the absence of a finding and the absence of a test as different lines.
The five answers
Your report has a Testing Methodology section. It has one row per check, and each row shows the answer that check got. A row can show one of these five answers.
| Answer | What it means |
|---|---|
| Tested | At least one audit task examined your code for this check. Any findings appear in the findings section. |
| Analyzed | The audit's code reading and architecture mapping answered this check. That work runs on every assessment. |
| Not applicable | Your codebase does not contain the surface this check targets. |
| Requires runtime | The check needs a running application, which a source code audit does not start. |
| Not completed | The audit did not settle this check. The report makes no claim about it. |
In other words, each check was either examined directly, answered by the code reading the audit always does, out of scope because your application has nothing for it to test, out of reach because source code alone cannot settle it, or reported as unanswered. No check on the list is left blank.
The section starts with the totals for all five answers, so you can see the overall result before you read individual rows.
When "Not completed" appears
Two situations cause this answer. In both, AISafe marks checks as not completed because it cannot show that they were done.
The first is a failed audit task. The run records that a task failed, but not which checks that task was working on. For that reason, a single failed task anywhere changes every answered check in the report to Not completed, and a note under the totals explains why. AISafe does this on purpose: the failed task may have been the one that would have found a vulnerability, and the report cannot tell you which checks it covered.
The second is a check that the audit leaves unanswered. After the first pass, the audit goes back over the checks that are still open, and it keeps doing so as long as each round answers at least one more check. When a round answers none, AISafe records the remaining checks as unsettled instead of dropping them from the report.
Four methodology packs run on every audit
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 mix these kinds of code. A mobile client talks to a web backend, the backend deploys through Terraform, and somewhere in the tree there is a compiled component. If you had to pick one pack up front, you would be deciding what your application is before anyone had read it, and a wrong choice would leave a whole part of your application unexamined.
So every check runs, and the checks that do not fit your application are marked not applicable. They still appear in the report with that answer.
When a whole pack has nothing to test, the report shows its rows as one summary line with the counts. This keeps a backend report from filling up with a hundred inapplicable mobile rows, while the counts still account for every check in the pack.
What "not applicable" means
It means the audit looked for the surface a check needs and found that your application does not have it. For example, the repository contains no native code for a binary check to examine.
It never means that the audit ran out of time, budget, or patience. The report uses Not completed for those cases, and AISafe keeps the two labels separate on purpose.
Checks that code cannot answer
Some checks depend on how a deployed system behaves rather than on what the source code says. No amount of careful reading can settle them.
The report marks such a check Requires runtime instead of leaving it out, so you can see where a code audit's reach ends. If those checks matter to you, follow the audit with a service that tests 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 a regime adds two things together: that regime's checks, and the ability to recognize the data those checks are about. For example, a check that asks where personal data travels comes together with the ability to recognize personal data in your code. You cannot select one without the other, and you would have no reason to, because neither half can answer anything on its own.
If you leave all three unticked, the audit still runs the four packs that are always on.
What a regulatory pack adds
Ticking GDPR does not turn the run into "a GDPR audit". It adds checks tied to the technical articles of the regulation that a code audit can address:
- security of processing
- erasure of personal data
- integrity and confidentiality
- data protection by design and by default
It deliberately leaves out obligations that are met by documents rather than by code. Staff training, processor contracts, and breach-notification timelines are real duties under the regulation, but a code audit cannot read any of them. Your report does not mention them, and you should not read any result in it as covering them.
HIPAA and PCI DSS work the same way. Their checks address the technical controls that exist in your source code. Organizational and procedural controls are outside what reading code can reach, and the audit says nothing about them.
What the scan read
Coverage has a second part. Before any check runs, the audit reports how much of the attached source it actually read.
Most files in a repository are not source code. Images, documents and build output are skipped on purpose, so AISafe never reports them as a gap. It reports only source files that the scan should have read and could not: files too large to accept, files that would not parse, and files the scan could not open.
- If almost nothing was lost, the results page mentions it in one short line.
- If enough was lost to change what you received (for example, a tenth of your source files), the results page says so prominently and gives the exact counts.
- If the attached source contains no readable code at all, AISafe refuses the audit before it starts and before anything is charged. The message says what AISafe found instead, so you can attach the right branch or archive.
A repository of Terraform or other configuration is still a real audit target. AISafe analyzes configuration for infrastructure, dependency, and secret issues even though it contains no application code.
What this is not
An audit is not an assessment of compliance, and AISafe is not an assessor.
What you get is narrower than a compliance assessment, and more useful: findings mapped to control frameworks (see Compliance mapping), plus a record of which methodology checks the audit worked through and what answer each one got. You or your auditor can read that record, question it, and check it against the code.
The record is not a judgment about your application's standing under any standard, and nothing in it supports such a judgment. That decision belongs to your auditor, and the coverage record is one of the things they can read while they make it.
Standing rules
Every audit also runs against a set of standing rules. These are guidance that our security team writes about how each class of weakness actually appears in source code. Each run records the rules assigned to its stages and the rules cited by the work it produced. These records help you review the audit's coverage. However, the fact that a rule was assigned to a stage does not prove that the stage finished or that the rule was applied.