Report Structure
Every AnkerCode Evidence Report is written in German. Here is what each section contains and why it matters.
Section 1: Zusammenfassung
Section titled “Section 1: Zusammenfassung”A key-metrics table at the top of the report:
| Kennzahl | Bedeutung |
|---|---|
| Scan-Datum | When the scan was run |
| Branch / Commit | Git context for reproducibility |
| Schwachstellen (gesamt) | Total CVE count across all severities |
| Kritisch/Hoch (offen) | The number that matters most to auditors |
| Secrets-Treffer | Exposed credentials found by Gitleaks |
| Lizenzen erfasst | Total license findings |
| Akzeptierte Risiken | Findings with a documented risk acceptance |
| Policy-Status | Pass/fail against ankercode.policy.yaml (if configured) |
This section is what a CTO reads first. Keep “Kritisch/Hoch (offen)” low.
Section 2: Policy-Bewertung
Section titled “Section 2: Policy-Bewertung”Present only when an ankercode.policy.yaml is configured.
Shows the overall pass/fail verdict and a table of blocking violations — findings that would fail a CI gate. Non-blocking warnings are not listed here; they appear in the Maßnahmenplan so they stay visible without cluttering the verdict section.
Section 3: Maßnahmenplan
Section titled “Section 3: Maßnahmenplan”Present when the policy evaluation produced any violations or warnings.
A package-centric action table — one row per package@version, not one row per CVE. This mirrors how Snyk and Dependabot present upgrade recommendations: the unit of action is the upgrade, not the individual finding.
| Column | What it shows |
|---|---|
| Prio | 🔴 Blockierend / 🟡 Warnung |
| Paket | Package name |
| Aktuell | Installed version |
| Upgrade auf | Recommended fix version |
| CVEs | Number of CVEs fixed by this upgrade |
| Schwere | Highest severity CVE in this package |
Secrets are surfaced as a separate sub-table above the upgrade list.
Section 4: SBOM-Zusammenfassung
Section titled “Section 4: SBOM-Zusammenfassung”A reference to the CycloneDX SBOM generated by Syft, including:
- SBOM format (always CycloneDX in Phase 0)
- SHA-256 hash of the SBOM file (first 16 chars)
- Local file path
The hash lets an auditor verify the SBOM file hasn’t been altered after generation.
Section 5: Schwachstellen
Section titled “Section 5: Schwachstellen”All open CVE findings grouped by severity:
| Severity | Description |
|---|---|
| Kritisch | CVSS 9.0–10.0. Immediate action required. |
| Hoch | CVSS 7.0–8.9. Fix within the sprint. |
| Mittel | CVSS 4.0–6.9. Fix in next release cycle. |
| Niedrig | CVSS 0.1–3.9. Fix when convenient. |
| Info | Informational. No immediate risk. |
Each finding shows: CVE ID, affected package + version, whether a fix is available, and the manifest file where the dependency was found.
Findings covered by a VEX not_affected statement or a risk acceptance do not appear here — they appear in Sections 7 and 8 instead.
Section 6: Secrets / Leaked Credentials
Section titled “Section 6: Secrets / Leaked Credentials”Present only when Gitleaks finds secrets.
Each entry shows: severity, secret type (API Key, JWT, SSH Private Key, etc.), the file path where it was found (shortened to last 3 path segments), and current status.
Section 7: Lizenz-Risiko
Section titled “Section 7: Lizenz-Risiko”Two parts:
- Summary table — each license detected and how many packages use it
- Per-license package list — packages grouped by license
Common safe licenses (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC) require no action. Licenses to watch: GPL-2.0, GPL-3.0, AGPL-3.0, LGPL (copyleft implications), BUSL-1.1, and any UNKNOWN entries.
Section 8: Vulnerability-Handling-Nachweis
Section titled “Section 8: Vulnerability-Handling-Nachweis”Your documented VEX statements from ankercode.decisions.yaml. For each:
- Finding ID (short)
- Status (
not_affected/affected/fixed/under_investigation) - Justification or prose statement
- Author (the human responsible)
This section demonstrates to an auditor that your team analyzed findings rather than ignoring them. It is the core of CRA Article 13’s vulnerability handling requirement.
Section 9: Akzeptierte Risiken
Section titled “Section 9: Akzeptierte Risiken”Your documented risk acceptances from ankercode.decisions.yaml. For each:
- Finding ID (short)
- Reason for accepting
- Who accepted it
- Expiry date (or “unbegrenzt”)
Accepted risks without an expiry date should be reviewed periodically.
Section 10: Methodik und Scanner-Versionen
Section titled “Section 10: Methodik und Scanner-Versionen”Records exactly which scanner versions and which CVE database snapshot were used:
| Scanner | Version | Funktion |
|---|---|---|
| syft | 1.46.0 | SBOM-Erzeugung (CycloneDX) |
| trivy | 0.72.0 | Schwachstellen & Lizenzen |
| trivy-db | 2026-07-02 | CVE-Datenbank (Stand des Scans) |
| gitleaks | 8.30.1 | Secret Detection |
| osv-api | v1 | OSV-Datenbank Abgleich |
The trivy-db date is the key reproducibility anchor: it tells an auditor exactly which vulnerability snapshot was active when the scan ran.
The section ends with the legal disclaimer: this report is machine-generated and does not constitute a conformity declaration. A human is responsible for review and signature.