Run a Code Audit

Code Audit reads one commit of a connected repository branch: scanners flag suspect code, a security review investigates what they flag, and verification decides what holds up. It keeps those source findings separate from Pentest apps and findings.

​

Prerequisites

• The workspace Admin or Developer role. Viewers can read audits and findings but can’t start one. See Roles.
• A connected Git provider with access to the repository and branch you want to assess.
• Permission to audit that source. You don’t need a pentest app, an application URL, DNS proof, or an application login.

​

Start an audit

​

Read the results

SAST is the automated pass: scanners read the code and flag suspect lines and exposed secrets. Security review looks at how the code behaves and raises candidates. Verification weighs each candidate against its evidence and decides the outcome below. Open a finding to read its impact, the fix, the conditions it depends on, the verification, and the lines it points at. That evidence belongs to the commit the audit pinned. Proving a problem in source code doesn’t prove it can be exploited against the running app: that’s what a pentest is for. A finished audit doesn’t mean every file was read. Failed checks, skipped files, and blocked verification all need a look. A failed audit can still show what it collected, but those results are incomplete.

​

Track a branch

A tracked branch keeps the published findings from completed audits and links to the earlier ones. Later audits update the branch view without rewriting reports you already have.

• Run audit in the branch header assesses the branch again. An unchanged commit is skipped until a full scan is due.
• A full scan reads the whole tree instead of the changed files only. You don’t ask for one: it happens when there’s no successful audit to compare against, when commit history is missing, when the analysis settings change, or seven days after the last full scan.
• A failed or cancelled attempt leaves the last published findings in place. Check the current attempt’s status before you read the branch view.

​

Choose a findings view

Switch between Table and Kanban. Search, severity, source, and false-positive visibility carry across views and detail navigation. The board groups findings by outcome, and you can’t drag a card to change its verdict. Not confirmed findings are hidden by default; use Show false positives to read them. On a tracked branch, No longer detected still isn’t the same as a confirmed fix. Pentest’s triage stages don’t apply here. New, unchanged, and reappeared describe what changed between audits, not extra verification outcomes.

​

Schedule reassessment

Click Schedule in the branch header, or in the branch’s Settings, to open Schedule branch checks. Pick a recurrence and check the timezone it shows, or tick Audit when commits are pushed to this branch. Push auditing follows the exact connected repository branch. Once a schedule is saved, Schedule opens it as an Automation, where you edit, pause, or delete it. A queued or running audit is not a finished result. When an audit ends, its notification links to the report.

​

Hand off confirmed findings

Click Create PR with agent on a confirmed finding to open a fix conversation. The conversation works from the current branch and keeps the assessed commit for comparison. Open conversation on an audit reopens the conversation that audit saved. There’s no button that files a tracker ticket from a Code Audit finding, so raise that in your tracker yourself. Preparing or merging a fix doesn’t change the original verdict. Run another audit against the changed code, or wait for the branch’s next scheduled audit.

​

Troubleshooting

For every Cyber problem in one place, see Cyber troubleshooting.

​

Next steps