This page explains what happens during an audit: the work that takes place after you connect a repository and before findings appear as reports in your program inbox. For connecting repositories, see Connect Repositories to H1 Code from HackerOne.
Note: The audit reads your source code to analyze it. It does not run your application, and it does not change your code. It is a security audit, not a compliance audit, and it does not certify compliance with any regulatory or other standard.
How it Works
H1 Code Security Audit is built on the premise that finding real vulnerabilities in source code takes more than pattern matching. It takes reasoning about how a system fits together, whether a weakness can actually be reached, and what an attacker would gain by reaching it.
The agents read and analyze your code methodically: they follow the leads that matter and rule out the ones that do not. The specialized agents that carry out audit workflows are continuously evaluated through a benchmark program and framework built to measure efficacy for catching real-world risks and filtering false-positive noise. For eligible customers and programs, Frontier Cyber Models can be leveraged by agents to conduct discovery and validation work.
Two lines of analysis run simultaneously. One examines the code your team wrote. The other examines the open-source dependencies that code relies on. Both feed a single, prioritized set of findings.
The Audit Workflow
Building Context on Your Codebase
The audit begins by mapping your repository: the languages and frameworks it uses, how the application is put together, and where it handles the security-relevant work of accepting input, authenticating users, and reaching data. This map shows the agents where risk concentrates, so their effort goes to the parts of the code that warrant it.
Hunting for Candidate Weaknesses
Working from that map, the agents investigate the areas most likely to hold vulnerabilities. They trace how untrusted data moves through the code and follow the paths that lead from an entry point to a sensitive operation. Each candidate weakness is recorded with its location and the reason it is a concern. Controls and mitigations are noted.
Verifying Each Finding
A candidate is not a finding until the audit confirms it. Each one is re-examined on its own to establish that the security risk is real: the conditions that trigger it, the path that reaches it, and the impact if it is exploited. Candidates that cannot be substantiated are dropped. This verification is why the audit is designed to minimize false alarms, and why the findings you receive are worth your team’s attention.
Assess Reachability and Impact
For a confirmed weakness, the audit asks whether an outside attacker could reach it and what they would gain. A flaw sitting behind controls an attacker cannot cross carries different real-world risk than one exposed at the surface. Capturing that difference lets the audit rank findings by the risk they pose in the system.
Checking Vulnerable Dependencies
In parallel, the audit reviews the open-source components your code depends on. Many tools flag known vulnerabilities (CVEs) in the dependency tree whether or not the affected code ever runs. The audit adds a reachability check: it follows the chain of dependencies that pulled each component in and determines whether your application calls the vulnerable code. Known vulnerabilities your application never reaches are marked as such, which turns a long list of dependency alerts into a shorter list of the ones that apply to you.
Prioritizing and Packaging Findings
The audit then brings the results together. It consolidates duplicate reports of the same underlying issue, rates each finding for severity, and writes each one to stand on its own. The result is an ordered set of findings, with the highest-severity, reachable issues first and informational items marked clearly.
What Each Finding Includes
Each finding is written to stand on its own, so your team can judge it and act on it. Every report opens with a short classification set, then follows with documentation, references, evidence and reasoning behind the finding.
Every finding opens with a classification:
Severity: a rating on the standard Critical, High, Medium, Low, and Informational scale.
Weakness type (CWE): the Common Weakness Enumeration identifier for the flaw, so it maps to the triage and reporting your team already runs.
Impacted axes: the security properties at risk, one or more of confidentiality, integrity, availability, and privilege.
Attacker class: the access an attacker needs to reach it, from an unauthenticated outsider to an authenticated user, another tenant, or a peer service.
Manifestations: how many places in your code share the same underlying flaw. When one root cause appears in several locations, the audit groups them into a single finding so you fix it once.
It then documents the case for the finding:
Root cause: the primary location in your source (file, line, and symbol) that enables the security issue.
Mechanism: a description of how the security issue is enabled.
Attack path: what an attacker gains and any conditions needed to exploit it.
Severity assessment: why the finding carries the severity it does, in terms of who can exploit it and what they affect.
Verification brief: the steps to reproduce the issue, built only on the preconditions the audit verified in your source.
Remediation guidance: what a fix needs to establish, so the change closes the issue instead of moving it.
Context Usage & Data Protection
Read-only access: The audit reads your source code. It does not write to it. There are no commits, branches, or merges.
Inference, not training: Your code is used as context to analyze your application. It is not used to train models.
Scope-bound: The audit works within the repositories you connect and the scope agreed before it starts.
From Findings to Your Inbox
When the audit finishes, its confirmed and prioritized findings arrive as reports in your program inbox. Each report carries a severity and a weakness type (CWE), and routes to the team that owns the affected system, alongside your pentest and disclosure reports. You triage, remediate, and retest them through the workflow you already use. A HackerOne security engineer can walk your team through the results.
Once a finding is fixed, H1 Remediation closes the loop by tracing the fix back to the specific source locations identified in the audit and generating developer-ready verification steps to confirm the root cause has been resolved. It also scans for the same pattern elsewhere in your codebase and flags related instances, so your fix can cover them in the same pass.