Summary
informational is a valid severity in the findings schema and is exported to SARIF and CSV, but the report.md projection filters it out. A scan whose findings are all informational produces a sealed findings.json containing them, a SARIF file containing them, and a human-facing report that states there were no findings.
The severity is accepted by the schema (findings.schema.json line 107) and mapped for SARIF export (finalize_scan_contract.py line 51, "informational": "note"), but excluded from the report:
|
REPORTABLE_SEVERITIES = {"critical", "high", "medium", "low"} |
REPORTABLE_SEVERITIES = {"critical", "high", "medium", "low"}
applied at line 587. The severity and confidence mixes shown in the Scan Summary are computed from the already-filtered list, so those counts omit informational findings as well.
Affected version and environment
- Released package:
@openai/codex-security@0.1.1
- Confirmed on current
main at f22d4a36f26d16287bcdfd707b369116e02a08c3
- Python 3.12.13
Steps to reproduce
Take the bundled examples/completed-scan bundle (one finding) and render the report twice, changing only the severity level:
import report_projection as R
findings["findings"][0]["severity"]["level"] = level
text = R.build_report_markdown(manifest, findings, coverage)
Observed:
--- severity='high'
report.md says 'No findings': False
finding title appears: True
--- severity='informational'
report.md says 'No findings': True
finding title appears: False
Expected behavior
Either informational findings should appear in report.md — perhaps in a separate, clearly de-emphasised section — or the exclusion should be stated somewhere. references/final-report.md lists critical through low when describing ordering, but never says informational findings are dropped.
Actual behavior
The report claims no reportable findings survived the discovery, validation and reportability gates, while the sealed findings.json and the SARIF export both contain them.
Impact
Modest in severity but awkward in kind: the three outputs of a single scan disagree with each other, and the one a human reads is the one that omits data. Someone reviewing report.md concludes the scan found nothing, while the SARIF uploaded to a code-scanning dashboard shows note-level results, and findings.json records them as real findings.
Whether this is reachable depends on how often a scan produces only informational findings, which I have not measured — on a clean codebase it seems plausible rather than exotic.
Suggested direction
If the exclusion is deliberate, the clearest fix is to say so in the report itself — for example a line noting that N informational findings were recorded and are available in findings.json and the SARIF export — so the three artifacts no longer contradict each other. If it is not deliberate, adding informational to REPORTABLE_SEVERITIES and giving it its own section would align the report with the other two outputs.
Summary
informationalis a valid severity in the findings schema and is exported to SARIF and CSV, but thereport.mdprojection filters it out. A scan whose findings are all informational produces a sealedfindings.jsoncontaining them, a SARIF file containing them, and a human-facing report that states there were no findings.The severity is accepted by the schema (
findings.schema.jsonline 107) and mapped for SARIF export (finalize_scan_contract.pyline 51,"informational": "note"), but excluded from the report:codex-security/sdk/typescript/_bundled_plugin/scripts/report_projection.py
Line 16 in f22d4a3
applied at line 587. The severity and confidence mixes shown in the Scan Summary are computed from the already-filtered list, so those counts omit informational findings as well.
Affected version and environment
@openai/codex-security@0.1.1mainatf22d4a36f26d16287bcdfd707b369116e02a08c3Steps to reproduce
Take the bundled
examples/completed-scanbundle (one finding) and render the report twice, changing only the severity level:Observed:
Expected behavior
Either informational findings should appear in
report.md— perhaps in a separate, clearly de-emphasised section — or the exclusion should be stated somewhere.references/final-report.mdlistscriticalthroughlowwhen describing ordering, but never says informational findings are dropped.Actual behavior
The report claims no reportable findings survived the discovery, validation and reportability gates, while the sealed
findings.jsonand the SARIF export both contain them.Impact
Modest in severity but awkward in kind: the three outputs of a single scan disagree with each other, and the one a human reads is the one that omits data. Someone reviewing
report.mdconcludes the scan found nothing, while the SARIF uploaded to a code-scanning dashboard showsnote-level results, andfindings.jsonrecords them as real findings.Whether this is reachable depends on how often a scan produces only informational findings, which I have not measured — on a clean codebase it seems plausible rather than exotic.
Suggested direction
If the exclusion is deliberate, the clearest fix is to say so in the report itself — for example a line noting that N informational findings were recorded and are available in
findings.jsonand the SARIF export — so the three artifacts no longer contradict each other. If it is not deliberate, addinginformationaltoREPORTABLE_SEVERITIESand giving it its own section would align the report with the other two outputs.