CSAF Remediation - product statuses

[dejanb]

Problem Summary

The current /vulnerability/analyze endpoint only queries the purl_status table, which is populated when advisories contain explicit PURLs in their product_identification_helper field. Red Hat CSAF advisories sometimes do not include PURLs - they use CPE-based product identification with component names. This data goes into the product_status table instead, which is why queries against the analyze endpoint return no results for Red Hat test data.

---

How Product Status Correlation Works

Red Hat CSAF advisories create product_status records with:

• A context_cpe_id linking to the product's CPE (e.g., cpe:/a:redhat:jboss_fuse:7)
• A package text field containing the component name (e.g., spring-security or io.quarkus/quarkus-vertx-http)
• Version range information via product_version_range_id

Correlation to SBOMs happens through a chain: the CPE links to a registered product, which links to product versions, which link to SBOMs. The package field is then matched against SBOM package names using string pattern matching (either exact name match or namespace/name concatenation).

This correlation logic already exists in the vulnerability details endpoint (VulnerabilityAdvisorySummary) but is not present in the analyze endpoint.

---

Handling CPE Context in the Analyze Endpoint

Since the analyze endpoint receives only PURLs (without SBOM or product context), the implementation should query product_status by package name without CPE filtering, but include the CPE context in each result. This means the same package may appear multiple times with different statuses depending on the product context.

For example, querying for spring-security might return:

Status	CPE Context	Remediation
affected	cpe:/a:redhat:jboss_fuse:7	no_fix_planned
not_affected	cpe:/a:redhat:jboss_enterprise_application_platform:7	-

This accurately reflects how Red Hat advisories work - the same component can have different vulnerability statuses depending on which product it's bundled with. The caller can then interpret which context is relevant to their use case.

---

Test Files

For purl_status path (synthetic):

• etc/test-data/csaf/synthetic-affected-with-purl.json - Creates purl_status records, works with current analyze endpoint

For product_status path (real Red Hat data):

• etc/test-data/csaf/CVE-2023-20862.json - Contains affected packages like spring-security, jenkins, io.quarkus/quarkus-spring-security
• etc/test-data/csaf/cve-2023-0044.json - Contains affected package io.quarkus/quarkus-vertx-http

---

Expected Results After Implementation

CVE-2023-20862

• Querying for package spring-security should return the vulnerability with status affected in the context of jboss_fuse
• Associated remediations should include no_fix_planned with details "Out of support scope"
• The response should include the CPE context so the caller knows which product this status applies to

CVE-2023-0044

• Querying for package io.quarkus/quarkus-vertx-http should return the vulnerability with status affected in the context of quarkus
• The same package should also appear as not_affected in contexts like jboss_fuse, jbosseapxp, etc.
• Associated remediations for the affected status should include:
  • none_available
  • workaround (CSRF prevention)
  • vendor_fix pointing to the fixed product versions

---

Implementation Approach

The analyze endpoint needs to be extended to query product_status in addition to purl_status, matching packages by name. The existing raw SQL query in: