Integrating SBOM and Attestations with Backstage through a Chainloop Extension

[ImperiumTakp]

Proposal: Integrating SBOM and Attestations with Backstage through a Chainloop Extension

Context:

I recently developed a version matrix plugin for Backstage that presents package listings for different package managers. Initially, the implementation was focused on Composer, where I manually sourced package data and displayed it in Backstage. During the process, I discovered that Chainloop, along with Syft, could serve as an excellent resource for gathering Software Bill of Materials (SBOM) and other attestation data, which would be far more scalable and reliable than building a package listing system from scratch. This led me to explore the potential of integrating Chainloop with Backstage to offer SBOM version tracking.

Proposal:

I propose building a Chainloop extension that integrates SBOM and attestation data with Backstage, initially focusing on SBOM version listings. The architecture for this integration involves decoupling the systems through a message queue to facilitate robust communication between Chainloop's FanOut mechanism and Backstage's backend.

Architecture Overview:

graph TD
    %% Chainloop FanOut process
    subgraph Chainloop
        A1[Chainloop receives SBOM Data] --> A2[Chainloop FanOut Extension]
        A2 --> A3[FanOut Task triggered]
        A3 --> A4[Prepare Message for Queue]
        A4 --> MQ1[Message Queue]
    end

    %% Message Queue decoupling the system
    MQ1[(Message Queue - NATS/Kafka/SQS)] 

    %% Backstage Backend Plugin with detailed tasks
    subgraph Backstage Backend Plugin
        MQ1 --> B1[Scheduled Task]
        B1 --> B2[Pull Message from Queue]
        B2 --> B3[Parse SBOM Data from Message]
        B3 --> B4[Match SBOM to Backstage Entity]
        B4 --> B5[Process SBOM Packages]
        B5 --> B6[Store Processed Data in PostgreSQL DB]
    end

    %% PostgreSQL Database storing the processed data
    B6 --> DB1[(PostgreSQL Database)]

    %% Backstage User interaction with processed data
    subgraph Backstage User Interaction
        U1[Backstage User] --> UI1[Backstage Frontend - View Entity Page]
        UI1 --> UI2[Request SBOM Package Data]
        UI2 --> DB1
        DB1 --> UI3[Render SBOM Package Details on UI]
    end

Loading

Detailed Flow:

1. Chainloop FanOut: Chainloop receives SBOM data, which is processed through a custom FanOut extension. The extension prepares the SBOM data and pushes it to a message queue (e.g., NATS, Kafka, SQS, etc.).

2. Message Queue: A message queue decouples Chainloop and Backstage, ensuring reliability and flexibility in communication.

3. Backstage Backend Plugin:

• A scheduled task in Backstage pulls messages from the queue.
• The plugin parses the SBOM data from the message and matches it to the relevant entity in Backstage.
• The SBOM package data is then processed and stored in a PostgreSQL database.

4. Backstage User Interaction:

• Users interact with the processed SBOM data via Backstage’s frontend, where they can view version listings and package details related to the specific Backstage entity.

Open Questions for Discussion:

1. Message Queue Integration: I opted for a message queue between Chainloop and Backstage to decouple the systems and allow flexibility in the underlying infrastructure (e.g., supporting NATS, Kafka, SQS, etc.). However, I'm open to feedback—do you see this as the best approach, or would a more direct integration (e.g., HTTP-based or WebSocket) be preferable in this case? I’m particularly interested in understanding any trade-offs in terms of performance, complexity, or maintainability.

2. FanOut Process: Should the FanOut process be the preferred extension mechanism for handling this data in Chainloop, or is there another Chainloop component that could provide a more efficient or streamlined method for pushing SBOM data?

3. Backstage Backend Module Structure: Given that I plan to use multiple message queue systems (NATS, Kafka, etc.) based on user needs, should this be handled in a modular fashion within the Backstage plugin, or would a more uniform approach with configurable options be easier to maintain?

Reason for Proposal:

As I mentioned earlier, I initially built a version matrix plugin for Backstage that provides listings of package versions for Composer. Realizing that tools like Syft and Chainloop can automate and centralize SBOM generation and attestation, I want to leverage Chainloop’s existing capabilities instead of manually building a version tracking system from scratch. This integration would provide a scalable solution for organizations using Chainloop and Backstage, starting with SBOM listings and potentially expanding to other types of attestations in the future.

I believe this proposal could greatly enhance both Chainloop's extensibility and Backstage's capability to display SBOM and attestation data, providing developers with more transparency and traceability in their software supply chains.

Looking forward to your feedback and suggestions on this integration approach!