How to Read and Act on a CodeAuditAgent Report

A security report is only useful if it turns into merged fixes. CodeAuditAgent reports are designed around that: each finding is specific enough to verify quickly and comes with a patch you can adapt. This guide explains every part of a report, how to triage it when you do not have a dedicated security engineer, and how to confirm that your fixes worked.

What gets audited

An audit runs on either a public GitHub repository or a code snippet you paste in. For repositories, CodeAuditAgent reads the default branch. Private repositories cannot be audited by URL, and there are no pull-request comments yet; results live in the dashboard and in exports.

How much of a repository is read depends on your plan. The Free plan covers 1 repository, 3 audits per month and up to 20 files per audit. Starter, at $49 per month, covers 5 repositories, 50 audits and 40 files per audit. Pro, at $199 per month, covers unlimited repositories, 500 audits and 80 files per audit. Individual files larger than 60 KB are skipped. Monthly audit counts reset at the start of each calendar month (UTC). A pasted snippet is also a quick way to check one file you are worried about before auditing the whole repository.

When files are left out because of these limits, the report is labeled as a partial snapshot. Take that label seriously. A clean partial report means the files that were read look clean, not that the repository is. If the code you care about most was omitted, audit it as a pasted snippet or on a plan that covers more files.

The risk score

At the top of every report is a risk score from 0 to 100; the Markdown export also states the overall severity next to it. Higher means more risk. It is a summary of the findings in that audit, useful for two things: deciding how urgently to look at a repository, and tracking whether it is getting better over time.

Do not read too much into small differences between unrelated repositories. A score is always relative to what was audited, and a partial snapshot sees less code. Comparing the same repository before and after fixes is where the number is most meaningful.

Severity and confidence

Each finding has a severity and a confidence. They answer different questions: severity is how bad it would be if the finding is real, and confidence is how sure the reviewer is that it is real.

• Critical: directly exploitable with serious impact, such as injection on a public endpoint, authentication bypass or exposed production credentials.
• High: a real vulnerability that needs some precondition, or has significant but limited impact.
• Medium: a weakness that matters in combination with other bugs, or has moderate impact.
• Low: hardening issues and defense-in-depth gaps.
• Info: observations worth knowing that are not vulnerabilities on their own.

Confidence is high, medium or low. A high-confidence finding has clear evidence in the code that was read. A low-confidence finding usually depends on something the audit could not see, such as middleware in another file, a database policy, or a configuration value set at deploy time. Low confidence does not mean ignore it; it means a human should check the missing context before fixing.

Anatomy of a finding

Every finding follows the same structure, so you can verify it in a consistent order.

• Title and CWE: the class of weakness, such as CWE-639 for an authorization bypass through a user-controlled key. The CWE tells you what kind of fix to expect.
• Location: the file and line, so you can open the code directly.
• Evidence: the relevant code quoted from the file. Check that the quote matches your current code; if the line has already changed, the finding may be stale.
• Exploit scenario: how an attacker would actually use the weakness, step by step. This is the fastest way to judge whether it is real in your context.
• Remediation patch: a suggested change in the style of the surrounding code.

Treat the patch as a strong starting point, not a merge-ready commit. It is written from the code the audit read, so it may not know about your helper functions, your ORM conventions or a caller elsewhere in the codebase. A typical patch is small and targeted:

--- a/app/api/invoices/[id]/route.ts
+++ b/app/api/invoices/[id]/route.ts
@@
-  const invoice = await db.invoice.findUnique({ where: { id } });
+  const invoice = await db.invoice.findFirst({
+    where: { id, userId: session.user.id },
+  });
   if (!invoice) return Response.json({ error: 'not_found' }, { status: 404 });

Positive observations and next steps

Reports also list what is done well: parameterized queries used consistently, secrets loaded from the environment, a strict cookie configuration. These are worth reading. They tell you which patterns to keep and copy into new code, and they are useful when explaining the state of a codebase to someone else.

The recommended next steps section turns the findings into an ordered plan. It often groups related findings, for example several missing ownership checks that are best fixed with one shared helper rather than five separate patches.

A triage workflow for small teams

Without a security engineer, the risk is not ignoring a report; it is spending a day on low findings while a critical one waits. A simple order works well:

• Read every critical and high finding first. For each, read the exploit scenario and decide: real, not real, or needs context.
• Fix real critical findings the same day. If a fix needs time, add a temporary mitigation such as disabling the endpoint or tightening a check.
• For findings that need context, check the missing piece: is there middleware, a row-level policy or a config that already prevents it? Write down the answer.
• Schedule high findings into the current sprint, medium ones into the backlog, and batch low and info items into a hardening pass.
• When a finding is not real, record why. That note saves the next person from investigating it again.

Assign each finding to one owner. Findings shared by the whole team tend to belong to nobody.

The findings explorer and exports

Once you have several audits, the findings explorer is easier to work from than individual reports. It lists findings across audits and filters them by severity, CWE and repository. Filtering by CWE is particularly useful: if the same weakness appears in three repositories, it usually points to a shared pattern or a missing helper, and fixing the pattern is cheaper than fixing each instance.

Findings can be exported as CSV from the explorer, which is handy for importing into an issue tracker or spreadsheet. Individual reports can be exported as Markdown, which reads well in a pull request description, an internal wiki or a message to a contractor who is doing the fix.

Re-audit to confirm the fix

A fix is not done until you have checked it. After merging, run a new audit on the same repository. Each report can be compared with the previous audit, so you can see which findings are gone, which remain and whether anything new appeared. The risk score should drop when real issues are fixed; if it does not, look at the comparison to see why.

Keep the comparison fair. If the first audit was a partial snapshot and the second read different files, the difference reflects coverage as well as fixes. Audits come out of your monthly allowance, so it is usually worth batching several fixes before re-auditing rather than re-running after each commit.

What a report does not cover

Knowing the limits helps you fill the gaps. Audits read your source code; they do not scan dependencies for known vulnerable versions, so keep a dependency scanner such as the one built into your package manager or GitHub running as well. Audits do not see deploy-time configuration, infrastructure outside the repository or files that were skipped. And like any reviewer, human or AI, the audit can be wrong: evidence and confidence levels are there so you can check it quickly rather than take it on trust.

Used this way, a report becomes a short, prioritized list of changes with evidence attached. Fix the critical ones, check the uncertain ones, re-audit, and watch the score move.