Compliance report

The compliance report answers the questions an auditor asks about vulnerability management: what was open, what was fixed and how fast, whether the fixes met your severity SLAs, which risks were accepted and by whom, and which policy was in force. You choose the period and, optionally, one repository.

Find it at Security › Reports › Compliance report (/<org>/_admin/security/reports/compliance). Org owners and members of the org’s Auditors team can open and download it.

What it contains

Section	What it shows
Open findings	Findings open at the end of the period, by type and severity. Types: dependencies, container images (including images pulled through the dependency proxy), licences, SAST, secrets, malware, and registry packages. Dismissed and fixed findings are not counted.
Remediation	Per severity: findings opened, fixed and dismissed in the period, the mean time from opened to fixed, and SLA compliance. Also opened, fixed, dismissed and still open per type.
SLA breaches	Findings of every type whose SLA deadline passed in the period while they were still open, next to the `code-security.sla.breached` events recorded for dependency findings (the ones sent to your SIEM).
Exceptions in force	Approved exceptions in force at the end of the period, with who requested and who approved each one and when it expires. An exception revoked or expired later still shows if it was in force then.
Riskiest components	Up to 20 components ranked by a severity-weighted count of their open advisories (critical 10, high 5, medium 2, low 1). From the component inventory.
Policy settings	The settings in force when the report is generated: SLA days, scan policy and scanner thresholds, the licence policy with its deny, warn and allow lists, the package policy with its deny and allow lists, and the exception settings.
Finding history	Every finding that was open at some point in the period, with when it was opened, fixed or dismissed, and its SLA state. CSV only.

Severities follow the Security overview: SAST error counts as high and warning as medium; a forbidden licence counts as critical and a restricted one as high; secrets and malware are critical.

SLA compliance for a severity is the findings fixed within their SLA, divided by those fixed within it, those fixed after it, and those still open past it at the end of the period. A severity without an SLA has no compliance figure.

Registry package findings appear only for an organisation whose package policy pipeline is enabled. Otherwise the report leaves them out and says so; your own package policy and its exceptions are still listed.

Formats

PDF summary: every section summarised on a few A4 pages, in your console language (English, Danish, German, French, Dutch or Swedish).
CSV: one file per section (open, remediation, sla, exceptions, components, policy, findings), each complete, with stable English column names, for a spreadsheet or a script.

Every download is recorded in the audit log as compliance.security_report.generated.

The period

Whole days in UTC, both ends included, at most 366 days. The default is the last 30 days. A finding opened at 00:00:00 on the first day or fixed at 23:59:59 on the last counts as in the period.

Where the history comes from

Most scanners replace their findings on every scan, so the scanner tables alone cannot say when something was fixed. fremforge therefore records each finding’s lifecycle (opened, fixed, dismissed) once a day for every org and again every time a report is generated. The report reads that record, and its last section, About the history, states what it can and cannot show:

History begins on the date recording started for your org. A fix before that date is only counted where the scanner kept the finding (it marks findings a later scan no longer reports, and malicious-package and registry package findings keep their own resolved dates). For a finding that was already open, the opened date is the one the scanner recorded.
Fix times are exact to the hour or within a day. Where the scanner marked the fix, its time is used. Where a finding simply disappeared, the fix is recorded when the daily recording, or a report, first no longer finds it.
SAST findings that were open before recording began carry their latest scan as the opened date, because the SAST scanner does not keep a first-seen date.
Dismissals are shown as they stand now; one that was lifted later is not in the report.

Via REST API

GET /_app/api/v1/orgs/{org}/security/compliance-report
    ?from=2026-09-01&to=2026-09-30
    &repo=web                          optional, a repository of the org
    &format=json | pdf | csv           default json
    &section=open|remediation|sla|exceptions|components|policy|findings   with format=csv
    &lang=en|da|de|fr|nl|sv            PDF language; else Accept-Language, else English

Requires a token with findings:read. The JSON is the whole report, including history.notes. Example:

curl -H "Authorization: Bearer ${FREMFORGE_TOKEN}" \
  "https://frem.sh/_app/api/v1/orgs/acme/security/compliance-report?from=2026-07-01&to=2026-09-30&format=pdf&lang=da" \
  -o compliance-report.pdf

Attach it to the weekly digest

An org owner can attach the PDF to the weekly security digest: tick Attach this report as a PDF to the weekly security digest at the bottom of the report page. It is off by default. The attached report covers the digest’s own period (7 days, or 1 day for a daily subscription) and is in each recipient’s language.

Via the API: PUT /_app/api/v1/orgs/{org}/security/compliance-report/settings with {"digest_attachment": true} (policy:write); read it with GET on the same path (policy:read).

Branch protection Package policies