Report Artifact Reference¶
This page explains the intended use of every file generated by a complete scan.
manifest.json¶
Use for: scan identity, inputs, selected references, generated artifact inventory, warnings, and automation traceability.
Do not use as: the finding or risk-detail report.
Inspect this file first when a folder is incomplete, a downstream import fails, or a user is unsure which source and project metadata produced the reports.
opengrep-results/opengrep-results.json¶
Use for: raw OpenGrep evidence, parser troubleshooting, and advanced rule investigation.
Do not use as: the primary PostQ review contract. It precedes PostQ normalization, metadata enrichment, grouping, and assessment.
This file can be larger and more implementation-oriented than the review reports. Retain it only according to engineering evidence and data-retention policy.
findings.json¶
Use for: canonical normalized scanner evidence, including crypto discovery, anti-pattern signals, parameter-flow evidence, function metadata, and finding-level FIPS assessment.
Do not use as: a direct count of user-facing crypto functions without applying the report's finding types. Parameter-trace and anti-pattern helper evidence can be present without representing separate crypto functions.
crypto-functions.json¶
Use for: individual crypto API calls, source locations, detected operations, libraries, parameters, resolution state, confidence, CWE, anti-pattern, quantum, FIPS, and manual-review facts.
Do not use as: proof that every runtime parameter was resolved or that unmatched code is safe.
This is the primary per-call review contract and the main source for editor diagnostics.
operation-groups.json¶
Use for: related calls grouped into one logical asset or operation lifecycle, such as cipher creation, initialization, and final encryption/decryption.
Do not use as: a replacement for source-level function evidence. Open the underlying steps when the group requires remediation.
Use groups to avoid treating setup and final operations as unrelated findings.
crypto-finding-assessment.json¶
Use for: repository-level readiness status, counts, manual-review workload, recommendations, algorithms, operation counts, vulnerabilities, confidence, and CWEs.
Do not use as: certification or as a substitute for detailed finding review. It summarizes the completed scanner facts and does not embed all function/group rows.
cbom.json¶
Use for: exchanging a cryptography bill of materials with inventory, governance, and migration planning systems.
Do not use as: a software bill of materials for every dependency or as the only source for developer remediation detail.
The CBOM is currently generated from operation groups and canonical risk facts. Consumers should validate the schema/version they accept.
See the CycloneDX CBOM guidance for the broader interoperability concept.
results.sarif¶
Use for: importing source-linked deterministic results into SARIF-compatible code scanning and security tools.
Do not use as: the complete PostQ inventory or operation-lifecycle report. SARIF is an interoperability view generated from canonical findings.
See the OASIS SARIF 2.1.0 specification.
Retention recommendation¶
Retain the whole output directory for any scan used in an audit, comparison, exception workflow,
or migration baseline. If policy requires selective retention, keep manifest.json with every
retained report and record why raw evidence was removed.