[RFC #0095] Exporter should export bom files for launch layers

[buildpack-bot]

This issue have been automatically created from pull request buildpacks/rfcs#166.

Given for example the following file structure:

/layers
  /config
    /sbom
      /launch
        bom.cdx.json
        /buildpack.id
          bom.cdx.json
          /cache-true-launch-true
            bom.cdx.json
          /cache-false-launch-true
            bom.cdx.json
        /other.buildpack.id
          bom.cdx.json
          /cache-true-launch-true
            bom.cdx.json
          /cache-false-launch-true
            bom.cdx.json

The exporter should create two layers - one for layers/config/sbom/launch/buildpack.id, the other for layers/config/sbom/launch/other.buildpack.id, and add them to the app image.

The io.buildpacks.lifecycle.metadata label contains a list of buildpacks and their layers. The data for each buildpack should contain a SHA referencing the digest of the layer containing the boms for that buildpack.

Additionally the exporter should create a third layer containing only the merged layers/config/sbom/launch/bom.cdx.json (this is not captured in #741). We'll likely need to extend our LayerFactory interface to be able to create a layer containing a single arbitrary file (this action is most similar what we do with LauncherLayer).

[aemengo]

Sorry, can I get clarified on why we're creating 3 layers in that example? According to the RFC:

[the lifecycle should] ... putting all the /layers/config/sbom/launch/ directory in the application image as a separate layer and ..

From that line, I'm reading it as 1 seperate layer. Was this something I'm missing? Some subtext can came out during a community meeting?

cc: @samj1912

[sambhav]

Yes - it was supposed to be one separate layer.

[natalieparellano]

I think we need a separate layer per-buildpack, because it's possible that on a rebuild, a subset of the first set of buildpacks detect. Then we don't want to restore all of the SBOMs from the previous build, but only the ones for the buildpacks that detected.

[natalieparellano]

Closing the loop here, we are fine to put all the BOMs in one layer. But when we copy BOMs from /layers/sbom/buildpack-id/layer-id/cdx.json to /layers/buildpack-id/layer-id.cdx.json we'll only do that for buildpacks that detected. We'll need to wipe the /layers/sbom directory before the build (which is fine because we'll do the reverse copy after the build is finished).

[sambhav]

This should be closed.

[fg-j]

Maybe I'm a bit out of the loop here, but I am wondering how a user would access the contents of an SBOM for a layer that's not marked for launch.

Based on #738, it seems like these SBOM files do get copied from /layers/buildpack.id/my-build-layer/bom.cdx.json to /layers/config/sbom/build/buildpack.id/my-build-layer/bom.cdx.json, but in practice that build SBOM directory doesn't appear in my app image at runtime. Is this by design? If so, what other means exists to look at what's in that SBOM?

[aemengo]

Hey @fg-j, we have following two PRs in place for viewing SBOM content.

• Show SBOMs in interactive pane pack#1349
• Add new command: pack sbom download pack#1351

The latter in particular will let you download the content for a pre-built image, meaning you will only access the contents of the launch SBoM. This is by design, but nothing is set in stone. Do you need the build SBoM contents for your use-case? Happy to discuss more in detail.

[fg-j]

We (Paketo) do see a need for the build SBoM. You can take a look at paketo-buildpacks/go-mod-vendor#13 for an example use-case. In this scenario, the user wants to know what go modules were used during the build, but the layer that contains the go modules isn't marked for launch (since all you need to run the app is a Golang binary).

Also, happy to move this conversation somewhere else if that makes sense 😄

[aemengo]

@fg-j I think you've been very clear. I thank you for describing your use-case too. I'll ping you with an update and solicit your feedback. 👍🏾