A full-capability report is too thick: engineers want code paths, supply-chain wants CVEs, compliance wants license exceptions—do not invent five unrelated exporters. Narrow filters on the same report snapshot.
Takeaway: First follow the report-export article to pick an audience and freeze a READY snapshot; then filter by capability/engine:
sast(OpenGrep),sca(Trivy: deps/artifacts/images),secret(Gitleaks), and license-related filters. SARIF only covers finding details (SAST/SECRET/SCA); quality-only or license-only scopes may hide SARIF in the download menu. External files never include raw secret text.
SBOM concepts: see Reference. Wizard, monthly, share, publish steps are in the snapshot-export article.
1. Division of labor
| Problem | Read |
|---|---|
| Audience, time window, monthly, formats, READY, share/publish | Snapshot export (how to produce) |
| Keep only SAST / deps / image / secret / license view | This article |
| How to read severity and paths | How to read reports |
Compressed prerequisites: completed jobs → create report → pick audience → scope jobs or current/time window → filter by capability / engine / severity → enable finding details for SARIF → download when READY.
2. Filter matrix (start here)
| View | Select (console field names win) | Preferred audience | SARIF |
|---|---|---|---|
| SAST | Capability SAST / OpenGrep | Engineering | Usually after finding details on |
| Dependency CVEs | SCA; directory deps or artifact jobs | Engineering; management wants summary | Usually after details on |
| Image CVEs | SCA; select that IMAGE job |
Engineering / release archive | Same |
| Secrets | SECRET / Gitleaks | Internal: engineering; external: third-party (counts) | Usually after details (careful externally) |
| Licenses | License / LICENSE filters | Third-party or engineering | Usually do not expect SARIF |
| Quality | Quality chapters | May appear on engineering; default not in security gate | Often unavailable |
Five perspectives: one Spec/Document per report—create five reports (or clone and change filters). Do not hand-edit exports and pretend they are separate snapshots.
3. SAST: paths and remediation
| Item | Do |
|---|---|
| Filter | SAST only; drop SECRET/SCA noise |
| Chapters | Finding details on; group by rule if offered |
| Accept | HTML/CSV show path + rule ID; SARIF opens in IDE with similar volume |
| Avoid | Counting quality smells as the security gate; using management-brief as a fix list |
See SAST guide in Reference.
View-specific failure: management audience → no paths. Switch to engineering + finding details.
4. Dependency CVEs: components and order
| Item | Do |
|---|---|
| Filter | SCA on lockfile/manifest or artifact jobs—not unrelated image jobs |
| Narrow | Min severity; KEV/EPSS if the console offers them |
| Accept | CSV/JSON with coordinates, CVE, suggested versions; do not re-ticket unexpired suppressions |
| Avoid | Unverifiable “we detect more than cloud SCA X” claims |
Prioritize CRITICAL/HIGH with a clear upgrade path. CVE playbook: Reference.
View-specific failure: mixed secret hits → leave only SCA.
5. Image CVEs: this image job
| Item | Do |
|---|---|
| Scope |
Selected jobs → that completed IMAGE job (avoid “current state” mixing last week’s tags) |
| Capability | SCA (Trivy image) |
| Accept | Gate result matches that job; tag/digest align |
| Note | Stale vuln DB → false green—see intranet vuln-DB article |
CRITICAL grey rollout: Reference (Trivy gate).
View-specific failure: current state shows multiple tags → pin the job.
6. Secrets: locations inside, counts outside
| Audience | Include | Forbid |
|---|---|---|
| Engineering (internal) | Path, rule, masked context (product redaction) | Full secrets in chat/tickets/wiki |
| Third-party (external) | Hit counts, disposition, exception approvals | Secret bodies, recoverable snippets, unretracted repo URLs |
Publish before sharing externally. Secret CI practice: Reference.
View-specific failure: renaming an engineering PDF for externals → void and regenerate third-party.
7. OSS licenses: non-compliant and approved exceptions
Licenses here are dependency licenses (SPDX-style IDs from the engine)—not the product’s own GPL-3.0 community license in the same argument section.
| Item | Do |
|---|---|
| Filter | License-related filters (console names win) |
| Reader takes | Non-compliant components, dual/unknown licenses, approved exceptions |
| Export | PDF/HTML/CSV; do not force SARIF |
| Accept | Exception list reconciles with suppressions / risk-accept |
Unknown/dual-license exceptions: Reference.
View-specific failure: SARIF on license-only scope → use CSV/PDF.
8. SARIF limits (capability view)
| OK | Do not assume |
|---|---|
| SAST/SECRET/SCA finding details into IDE / GitHub code scanning | “Every report has SARIF” |
| Numbers match HTML/PDF findings from the same Document | Management brief, external without details, quality-only, license-only always expose SARIF |
| Findings data only | SARIF replaces a full external evidence pack |
9. Failure table
| Symptom | Cause | Fix |
|---|---|---|
| SAST without paths | Management brief / details off | Engineering + finding details |
| Deps report mixes secrets | Capability filter off | SCA only |
| Image mixes old tags | Not job-scoped IMAGE | Select that job |
| External PDF searchable for token shapes | Wrong audience/redaction | Void; third-party regenerate |
| License SARIF forced | No finding-like items | CSV/PDF |
| Five files disagree | Hand-edited exports | Five separate READY reports |
FAQ
Can one click split five report files?
One Spec/Document per report; create five (or clone filters).
Is a quality report a security report?
Quality chapters may appear on engineering reports but default out of security gate / risk score (product rules). Do not treat quality engines as default SAST.
Relation to Repo ingest reports?
Repo can do light ingest blocking; cross-repo, suppressions, formal external checks live in Security. See Repo integration Reference.
Summary
- Same snapshot machinery; five filter recipes; generation steps in snapshot-export.
- Secrets: paths inside, counts outside.
- Licenses: dependency licenses only; do not expect SARIF.
- Images must pin an IMAGE job.
Reference articles
- How to export scan reports: https://www.anguskit.com/en/blog/security-scan-report-snapshot-export
- How to read scan reports: https://www.anguskit.com/en/blog/how-to-read-security-scan-reports
- SAST guide: https://www.anguskit.com/en/blog/sast-static-application-security-testing-guide
- SCA guide: https://www.anguskit.com/en/blog/sca-dependency-vulnerability-scanning-guide
- Image scanning: https://www.anguskit.com/en/blog/container-image-vulnerability-scanning-trivy
- Secret CI gate: https://www.anguskit.com/en/blog/secret-scanning-gitleaks-ci-gate-practice
- License compliance: https://www.anguskit.com/en/blog/open-source-license-compliance-scanning-guide
- License exceptions: https://www.anguskit.com/en/blog/license-scan-unknown-dual-license-exceptions
- SBOM getting started: https://www.anguskit.com/en/blog/sbom-software-bill-of-materials-getting-started
- CVE playbook: https://www.anguskit.com/en/blog/cve-vulnerability-response-playbook
- Intranet vuln DB: https://www.anguskit.com/en/blog/intranet-vuln-db-offline-update-rollback
- Trivy gate rollout: https://www.anguskit.com/en/blog/trivy-gate-critical-block-and-gradual-rollout
- Repo integration: https://www.anguskit.com/en/blog/angussecurity-angusrepo-artifact-gate-integration
- Ask about highs, findings, and gates via MCP: https://www.anguskit.com/en/blog/angussecurity-mcp-server-design
- Docs: https://www.anguskit.com/en/docs/security
Top comments (0)