Release Audits

Release Audits help you review external audit reports — PDFs, markdown, or archives from a security firm — against the code and deployment context you plan to release. Guardix extracts findings from the reports, reconciles scope against your repository snapshot, and surfaces a structured assessment you can share with stakeholders.

Availability may be feature-gated for your workspace. When enabled, you will see Release Audits in the app sidebar.

When to use it

You received a manual audit report and want a second read on scope, severity, and whether the code at your release commit still matches what was reviewed.
You need a shareable assessment that compares auditor claims to source-at-commit and, when provided, on-chain deployment probes.
Your team works from private source ZIPs (common when auditors deliver archives instead of a public repo).

What you provide

From Release Audits → Start new, the wizard collects:

Input	Required?	Purpose
Audit reports	Yes	PDF, Markdown, plain text, or ZIP archives (up to 25 MB each).
Source code	Recommended	Public git URL(s) and/or private ZIP archives (up to 100 MB each, one repo per archive).
Release ref / commit	When using git	The snapshot auditors should be compared against.
Deployment context	Optional	Contract addresses and chains to probe on-chain.
Extra context	Optional	Notes for the assessment (threat model, rollout plan, known exceptions).

You can run a report-only verification when you do not have source handy yet, but reconciliation and scope checks are strongest when source is attached.

Discovery: the intake gate

Before the analysis spends time on your inputs, Guardix runs a short discovery pass (a few minutes) that checks your submission the way a human auditor onboards a client: reports must be readable, repositories must clone, the commit or ref you typed must exist in the history you provided, every external dependency your contracts import must be accounted for, and every deployed address needs a chain and live contract code behind it.

If everything lines up, the analysis starts automatically. If something is missing, the verification pauses on an intake review instead of failing an hour later:

Chat thread — each gap arrives as an auditor question with an inline answer widget: attach the missing repository, pin the right commit, pick the chain for an address, classify a dependency, or upload the report a link pointed to. You can also leave free-text notes for the record.
System map — a live diagram of your submission as provided: repositories, contracts, reports, dependencies, and deployments, colored by verification status. It re-renders after every re-check, so you watch the picture become fully accounted for.

Answering a question does not close it — a re-check has to verify the fix (or fail it with sharper evidence). A few basics are fix-required (readable reports, reachable repositories, a resolvable ref); everything else can be waived with a reason when it is genuinely out of scope, and you can always acknowledge remaining gaps and run anyway.

Waivers and out-of-scope declarations are not silent: they are recorded in the intake attestation, which appears on the final assessment and on the public share page. Readers see exactly what was verified at intake and what you chose to exclude.

What you get

After the run completes, the assessment is organized into tabs:

Overview — executive summary, scorecard-style criteria, and headline scope/deployment verdict with deep links into detail sections.
Auditors — each uploaded report with view/download actions and firm-level trust signals.
Findings — extracted issues with severity, rationale, and cross-report context.
Scope & deployment — three-way reconciliation (audited vs source-at-commit vs deployed), freshness signals, privileged roles, and on-chain probes when addresses were supplied.

Sections hide automatically when the underlying data is not available — you will not see empty placeholders for probes that were never run.

Pricing and quotas

Pricing and any free verification allowance for your team are shown at checkout before you confirm a run, the same way as code audits.

Completed assessments can be shared via a read-only link for investors, partners, or internal reviewers who do not need a Guardix account.

Command line

You can create and manage the same Release Audit workflow with the Guardix CLI. Inside a connected checkout, the repository and current branch are inferred:

guardix release-audit start --report audit.pdf --wait

For standalone or multi-repository releases, repeat source and report flags:

guardix release-audit start \
  --project "Protocol v2.4" \
  --report auditor-one.pdf \
  --report auditor-two.pdf \
  --repo-url https://github.com/acme/protocol \
  --source-zip private-dependency.zip \
  --release-ref v2.4.0 \
  --wait

If intake pauses, inspect the questions and their answer examples:

guardix release-audit discovery show <release-audit-id>

For CI and coding agents, add --non-interactive --json. Exit code 3 means checkout or intake input is required, rather than a failed assessment.

Your first audit — starting a code audit (full pipeline on your repository).
Sharing audit results — share links for code audit results.