Reports, exports and evidence
Reports
| Report | Covers |
|---|---|
| Executive Report | The risk picture in plain words, for the whole workspace, one org, one repository or one team. PDF. |
| Security Report | One org or one repository: its issues in full. PDF. |
| Combined report | Every org or every repository in one PDF. |
| Guest Exposure report | Salesforce: what a guest user can reach. PDF. |
Exports for a repository
A repository's Reports & Exports page offers:
- Security Report (PDF) and Executive Report
- Issues (CSV) and Issues (SARIF)
- SBOM (CycloneDX) and SBOM (SPDX)
- VEX (OpenVEX) and VEX (CycloneDX)
- Cryptography Inventory (CBOM)
The SBOM, VEX and CBOM rows appear when the scan collected that view. Each branch's menu also downloads its latest results as SARIF or CSV.
Evidence packs (Team plan and up)
An evidence pack records, for each control of a compliance framework:
- how it was tested (automated checks or manual),
- the result: pass, partial, fail, evidence or not assessed,
- the open issues behind it, with their key, severity, status, owner and due date, and
- the exceptions, with who approved them, why, and when they expire.
It opens with an executive summary and is sealed with a SHA-256 hash, so a reader can tell it has not been changed. Packs come as PDF and CSV, for Salesforce orgs and for code repositories. Generating a pack is on the Team plan and up; packs you already generated stay downloadable on every plan.
Scheduled emails
Owners and Maintainers can schedule two kinds of email, on the Team plan and up:
- Executive Report: the Executive Report PDF, emailed.
- Evidence pack: a new evidence pack, stored in the workspace, with a link emailed.
Each schedule runs monthly (on the 1st) or quarterly (1 January, 1 April, 1 July and 1 October), can be limited to one team, and goes to members plus any extra addresses at your allowed email domains.
Scheduled emails are sent through your own SMTP server: the mail server of the workspace's first enabled Email destination (see Notifications and Jira).
Fix deadlines
Every open issue gets a fix deadline from its severity. The defaults:
| Severity | Days to fix |
|---|---|
| Critical | 15 |
| High | 30 |
| Medium | 90 |
| Low | 180 |
The deadline is then scaled by the criticality of the org or repository the issue is in. By default a High or Medium criticality asset keeps the deadline as it is (x1), and a Low criticality asset gets twice as long (x2). An asset with no criticality set keeps the deadline as it is.
Change both in Workspace Settings > Issues: Fix Deadlines by Severity and Deadlines by Criticality (each factor from 0.1 to 10). Set a repository's criticality when you connect it, and an org's in Org Settings.
Overdue issues can be filtered in Issues, and members are reminded before an issue is due ("Issue Due Soon").
On your machine
The scanner produces the same kinds of output locally: see
Output formats, vulkro sbom and
vulkro compliance.