Audit Portal

​

Overview

A finding tells you where a requirement was violated. The Audit Portal tells you the other half: which requirements were actually evaluated against which change — including the runs that came back clean and produced nothing. That distinction is the whole point. A repository with zero findings looks identical to a repository Zenable silently stopped running on. The Audit Portal is what separates the two, so “requirement R was checked against change C” becomes a fact you can show an auditor rather than something inferred from the absence of a finding. Find it under Reporting → Audit Portal.

​

Who it’s for

Three audiences read this page:

• Engineering — where are we covered, and where are the holes?
• Cybersecurity — are our controls being enforced?
• Auditors — show me proof the controls ran.

Auditors reach it through the Security Auditor role, which grants read-only access to the audit surface. See Permissions.

​

What’s on the page

​

The assurance matrix

The centerpiece. It answers one question:

Can we provide assurance that these requirements were enforced in these scenarios?

Your requirements run down the side; the enforcement surfaces run across the top — GitHub PR, GitLab MR, IDE / Agent, and CLI / Pre-commit. Each cell reports one of: “No activity” is not a gap. It is deliberately distinct from Not covered: “we never had the chance” is not “we had the chance and missed it”. A quiet surface should not read as a failure. A requirement that never ran anywhere still gets a row — it’s shown as Not covered across the board. That is the finding, not an omission. The matrix is rebuilt nightly. The whole page reports complete days only — figures always end yesterday or earlier, so a partially-elapsed today can never make the numbers disagree with themselves.

​

Landed without a check

Default-branch changes that landed with no Zenable evidence. This is the actionable list: each row is a change that reached your main branch unchecked. Every way a change can land is counted — merge commits, squash merges, rebase merges, fork PRs, and commits pushed directly to the default branch (shown with a Direct push badge). Landings are observed from your VCS provider directly, so the count does not depend on webhook delivery. A direct push counts as checked only when a Zenable check ran on that exact commit (for example a CLI or pre-commit check before pushing) — a direct push is not rewritten on landing, so commit identity is the honest test.

​

PR discipline

The share of default-branch landings that arrived through a pull/merge request. Direct pushes bypass review entirely, so this number is the process-integrity signal auditors ask about alongside coverage.

​

Filtering

The repository and date range filters at the top apply to the whole page at once — the matrix, the gap list, the evidence log, and the export all narrow together, and the filters ride the URL so a filtered view can be shared.

​

Evidence log

Every check that ran, including the clean ones. Each entry records the change (repository, commit, change ref), the surface it ran on, how many checks executed, and how many findings came out.

​

Exporting evidence

Export evidence pack downloads the bundle an auditor asks for over your selected period: the assurance matrix, the gap list, and the raw attestations behind both. In order to export, you must have the audit:export permission. For more details, see the Role Permission Matrix.