Goal Summary:

Meet Konflux SCA requirements to make RHACS the SCA (Software Composition Analysis) of choice in the pipeline to support pro-active vulnerability management.

Requirements: Konflux SCA scanner requirements to support pro-active vulnerability management in pipeline

Background:

Red Hat is migrating it's internal container build pipeline from legacy CPASS to Konflux [konflux-ci.dev/docs] platform. 

Konflux is a platform for building integrated software that streamlines, consolidates, and secures the development lifecycle (Konflux Architecture).

REF: Konflux review for secure supply chain leadership group

Goals and expected outcomes:

• Konflux and ACSCS POC
  • confirm if it's a viable alternative to current Clair as a CI Job{}
  • confirm it supports requirements to support Konflux tenants 
  • based on the outcome of the POC it's to be determined if additional performance improvements should be made to "Clair as a CI job".
• Address any known (as identified by RH ProdSec) Scanner V4/ Clair inadequacies that could result in a false positive for RH content
• Confirm Scanner V4/ Clair can correctly distinguish Red Hat content based on the content type (rpm vs non-rpm).
• Validate  Scanner V4/ Clair is using official Red Hat security metadata (CSAF/VEX files) and is interpreting it correctly based on CSAF Security Advisories and VEX Security Data guidelines. 
• Address any known (as identified by RH ProdSec) Scanner V4/ Clair inadequacies so that it reports detected vulnerabilities based on the official CVE id (grouping based in CVE, not various advisories) and must include at minimum the following information:
  • CVE ID;
  • name of the container image where CVE was detected;
  • detected vulnerable component name,
  • detected vulnerability path;
  • CVE Severity/Impact;
  • CVE Data Source;
  • Information about potential patch (based on the data source, for example for Red Hat it will be information about potentially available RHSA)
• Enhance Scanner V4/Clair functionality to support scanning SBOM file as an input instead of doing its own detection based on file system scanning. The expected SBOM format is SPDX 2.3 (in the future we might switch to SPDX 3.0, especially in case of AI BOMs support, but this is not a requirement as for now). The SBOM content interpretation should follow the Understanding SBOMs guideline. **

Acceptance Criteria:

A list of specific needs or objectives that a feature must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.

<enter general Feature acceptance here>

Success Criteria or KPIs measured:

A list of specific, measurable criteria that will be used to determine if the feature is successful. Include key performance indicators (KPIs) or other metrics., etc. Initial completion during Refinement status.

<enter success criteria and/or KPIs here>

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios together with user type/persona. Initial completion during Refinement status.

<your text here>

Out of Scope (Optional):

High-level list of items that are out of scope. Initial completion during Refinement status.

<your text here>