fix(sbom): version-filter product_status on the advisory and severity paths (TC-5641)

[mrrajan]

What this fixes

GET /sbom/{id}/advisory and the severity summary matched Red Hat product_status rows by package name only — reporting RPMs already past the fix as affected. purl_status/cpe_status and the /purl + /analyze endpoints already version-match; these two SBOM paths were missed.

Change

In modules/fundamental/src/sbom/model/raw_sql.rs, add version_matches to the product_status CTEs in product_advisory_info_sql and batch_severity_counts_sql — joining product_status → product_version_range → version_range, mirroring the sibling purl_version_matches CTE (and adding vp.version to sbom_purls). product_version_range_id is NOT NULL and bare known_affected creates no product_status row, so the inner join drops nothing that would otherwise match.

Tests

New sbom_details_product_status_version_filtering (tests/sbom/details.rs, fixtures in etc/test-data/cyclonedx/TC-5751/): a past-fix RPM is filtered, an in-range RPM is kept, and detail count == severity-summary count. sbom::details suite green; cargo xtask precommit clean.

Implements TC-5641

🤖 Generated with Claude Code

Summary by Sourcery

Apply version-range filtering to product-status matches in SBOM advisory details and severity summaries.

Bug Fixes:

• Filter Red Hat product-status advisory matches by the installed package version so past-fix packages are no longer reported as affected.
• Keep SBOM advisory details and severity summaries consistent when applying product-status version filtering.

Tests:

• Add coverage for past-fix and in-range product versions, including consistency checks between advisory details and severity summaries.

[sourcery-ai]

Reviewer's Guide

The PR fixes inconsistent SBOM advisory reporting by applying Red Hat product_status version-range matching to both advisory details and batch severity counts, then validates that past-fix packages are excluded, in-range packages remain affected, and both response paths stay count-consistent.

Sequence diagram for version-filtered SBOM advisory reporting

sequenceDiagram
    participant Client
    participant AdvisoryAPI
    participant SQL
    participant Database

    Client->>AdvisoryAPI: GET /sbom/{id}/advisory
    AdvisoryAPI->>SQL: product_advisory_info_sql()
    SQL->>Database: Join product_status to product_version_range and version_range
    Database-->>SQL: version_matches(sp.version, vr.*)
    SQL-->>AdvisoryAPI: In-range product_status matches
    AdvisoryAPI-->>Client: Advisory details excluding past-fix RPMs

Loading

Sequence diagram for count-consistent SBOM severity reporting

sequenceDiagram
    participant Client
    participant SeverityAPI
    participant SQL
    participant Database

    Client->>SeverityAPI: Request severity summary
    SeverityAPI->>SQL: batch_severity_counts_sql()
    SQL->>Database: Match product_status by package and version
    Database-->>SQL: version_matches(sp.version, vr.*)
    SQL-->>SeverityAPI: In-range affected packages only
    SeverityAPI-->>Client: Severity counts matching advisory details

Loading

File-Level Changes

Change	Details	Files
Apply product-status version-range filtering consistently to advisory details and severity summaries.	Add installed-version projection to SBOM purl data. Join product statuses through product_version_range and version_range. Use version_matches for both CPE-name and namespaced product-status paths. Preserve existing CPE-context filtering behavior.	modules/fundamental/src/sbom/model/raw_sql.rs
Add regression coverage for past-fix exclusion and in-range preservation.	Add advisory and two CycloneDX SBOM fixtures representing out-of-range and in-range RPM versions. Verify advisory detail filtering for both cases. Verify severity-summary counts match affected advisory details.	modules/fundamental/tests/sbom/details.rs etc/test-data/cyclonedx/TC-5751/advisory-product-status.json etc/test-data/cyclonedx/TC-5751/sbom_pastfix.json etc/test-data/cyclonedx/TC-5751/sbom_inrange.json

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

Sourcery assessment

Needs a human reviewer. An incorrect version-range match could suppress a real vulnerability finding or report a package as affected when it is not, causing downstream users to make security decisions from incorrect SBOM results. Reverting restores the prior matching behavior, but any missed or acted-on advisory before the revert is not undone.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[ctron]

This looks like it should be a parametrized test.

[ctron]

/scale-tests

[ctron]

/perf-test

[ctron]

/perf-test

[github-actions]

🛠️ Perf test has started! Follow the progress here: Workflow Run

[github-actions]

Perf Test Report (Locust)

Type	Name	Request Count	Failure Count	Average Response Time	Min Response Time	Max Response Time	Average Content Size	Requests/s	Failures/s
	Aggregated	0	0	0.0	0	0	0	0.0	0.0

📄 Full Report (Go to "Artifacts" and download report)

[mrrajan]

The CI failure reveals the real concern of this fix. TC-5751 producing false-negatives. The root cause is a semantic mismatch in the version filter I added.