Skip to content

Decide the malicious verdict from the purl, not a sibling field - #14

Merged
haksungjang merged 1 commit into
mainfrom
fix/malicious-verdict-version-key
Aug 5, 2026
Merged

Decide the malicious verdict from the purl, not a sibling field#14
haksungjang merged 1 commit into
mainfrom
fix/malicious-verdict-version-key

Conversation

@haksungjang

Copy link
Copy Markdown
Contributor

Found by the security review of #12.

The persist hook keys the catalog row on purl_with_version but passed the SBOM's separate version field to the evaluator. Omit that field and it defaults to "0.0.0", which a version-pinned advisory reads as "not one of the named versions" — clearing a row that is genuinely malicious. 12.4% of the snapshot carries version pins, and component_versions is shared across the whole organization, so the effect is not scoped to the uploader.

The verdict now derives from the same string the row is keyed on. A flagged → clear transition also logs a warning: normal when a snapshot refresh drops a withdrawn advisory, worth a look when one scan does it.

The regression test was checked against the unfixed code — it fails there and passes here. The existing tests could not have caught this because they build the SBOM with both fields agreeing.

This lands before #12 on purpose. The gate axis in that PR turns a wrong stamp into a build-block bypass, so the stamp needs to be trustworthy first.

The persist hook passed the SBOM's `version` field to the evaluator while
keying the row on `purl_with_version`. The two can disagree: omit `version`
and it defaults to "0.0.0", which a version-pinned advisory reads as "not one
of the named versions" and clears the row. 12.4% of the snapshot is pinned,
and `component_versions` is org-wide, so one upload could un-flag a package
for every project sharing it.

A flagged → clear transition now also logs a warning. That is normal when a
snapshot refresh drops a withdrawn advisory, and worth looking at when a
single scan does it.
@haksungjang
haksungjang merged commit 1fa9777 into main Aug 5, 2026
19 checks passed
@haksungjang
haksungjang deleted the fix/malicious-verdict-version-key branch August 5, 2026 00:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant