Skip to content

SPIKE: Store and expose security reports for scanned SBOM components

Topic to Evaluate

Tasks prior to evaluation

  • Clearly document the topic to evaluated in this issue description
  • Determine specific scope including time-bounds for investigation: 3 days

Tasks to Evaluate

  • Determine feasibility of the feature
  • Create issue for implementation or update existing implementation issue description with implementation proposal
  • Set weight on implementation issue
  • If weight is greater than 5, break issue into smaller issues

Risks and Implementation Considerations

Assumptions and Context

Considering potential issues with file size and the deviation of this file from the concept of a typical job artifact, the following assumptions have been made:

  1. Historically, timeouts have occurred during report parsing. Therefore, persisting the new JSON file would be more efficient than building and serving it in-memory.
  2. A new model and corresponding services would need to be created, as this file functions more like an export file rather than a report artifact.

Proposed Approaches

1. Generate the File at the Time of Ingestion

This approach ensures the file is generated early in the process, but it has a notable limitation: it doesn’t incorporate the latest vulnerability information (produced by CVS), as this data is only available after ingestion.

Backend
  • Introduce a feature flag, such as enable_sbom_with_vex_download, to toggle between the current implementation and the new feature.
  • Trigger the generation of the VEX file just after SBOM ingestion.
  • Use Gitlab::VulnerabilityScanning::SecurityReportBuilder (introduced in MR 171019) to load vulnerability data linked to dependencies.
  • Create a new model and associated services (e.g., create method) that leverages FileStoreMounter to persist the file.
Frontend
  • Update SecurityReportsSummary related components to consider the feature flag, enabling support for downloading the VEX file.
2. Generate the File On-Demand at the Time of Download

This approach requires a slight modification in the download behavior, necessitating UX approval. Its key advantage is that it incorporates the latest vulnerability data (produced by CVS) at the time of the file generation.

Backend
  • Add a new feature flag, such as enable_sbom_with_vex_download, to toggle between the current implementation and the new functionality.
  • Implement an export and download API, similar to the the existing dependency list export mechanism.
  • Use Gitlab::VulnerabilityScanning::SecurityReportBuilder (introduced in MR 171019) to load vulnerability data linked to dependencies.
  • Create a new model and related services (e.g., create method) that utilize FileStoreMounter to persist the generated file.
  • Ensure the file output adheres to the VEX format.
Frontend
  • Update SecurityReportsSummary related components to consider the feature flag and support the export and download APIs.

Summary (AI generated)

The choice between these two approaches depends on the priorities:

  • Ingestion-Time Generation: Simplifies implementation and aligns with existing ingestion workflows but lacks the latest CVS vulnerability data.
  • On-Demand Generation: Involves a more dynamic workflow and offers up-to-date vulnerability insights but requires UX changes.

Both approaches include the creation of a new model and services, the use of FileStoreMounter, and modifications to the frontend to support the feature flag.

Team

/cc @tkopel @johncrowley @gonzoyumo

Edited by Zamir Martins