search

tektoncd / chains

Supply Chain Security in Tekton Pipelines
Apache License 2.0
240 stars 125 forks source link

Generating SBOMs for container images once they're built by TaskRun #277

Open developer-guy opened 2 years ago

developer-guy commented 2 years ago

Feature request

We (w/@dentrax @erkanzileli) propose generating SBOMs once the images are built when Taskrun has been completed, then signing them. I want to list the tools that can help us to do that:

cc: @luhring @puerco @cpanato @nishakm @dlorenc

Use case

SBOMs are really needed to understand the software and libraries being used during your build and deployment cycle. There are several methods designed specifically for delivering SBOMs, including SPDX (Software Package Data Exchange), Software Identification (SWID) Tags, and Cyclone DX. So, we can use one of these formats to identify how our images were built during the Tekton Pipeline process.

priyawadhwa commented 2 years ago

Hey @developer-guy thanks for opening this issue, I think it's a really good idea! It looks like some of these tools build SBOMs from the container image and some from source code. I see two ways of doing this:

  1. SBOMs are generated in a TaskRun and then Chains is responsible for signing & storing the signatures somewhere (works with source code or image)
  2. Chains generates the SBOM from a container image & then signs and stores the signatures somewhere (only works with image)

It seems like (1) is the more flexible option, but we would need to wait on https://github.com/tektoncd/pipeline/issues/4012 to be implemented for it to work (right now Tekton results can't store anything bigger than 4096 bytes, which I believe isn't large enough for a typical SBOM). We could implement (2) right now, but it won't be as flexible.

developer-guy commented 2 years ago

Thank you so much for the explanation. TBH I'm in favor of the second one because all these tools that I mentioned above can be used as a go module, so we can choose one of the formats that we want to support (SPDX, Cyclone DX), then select the module to do that, we'll be ready to go. So it makes sense to me because, as Tekton Chains did for provenance, we can do the same one for SBOMs, I mean generating, signing, and storing them behind the scenes. WDYT? We can create TEP for this if you want. 🤩

priyawadhwa commented 2 years ago

Ya that sounds good to me! tbh we could probably end up supporting both options, I can see either being valuable to people.

I think this change should be small enough that it doesn't require a TEP, but if you think you'd like to have more of a discussion on one definitely go for it :) Maybe we could add artifacts.oci.sbom.enabled and artifacts.oci.sbom.format as options to the config, which users could set. Like you said, from there Chains should be able to handle generating, signing and storing!

mlieberman85 commented 2 years ago

Thank you so much for the explanation. TBH I'm in favor of the second one because all these tools that I mentioned above can be used as a go module, so we can choose one of the formats that we want to support (SPDX, Cyclone DX), then select the module to do that, we'll be ready to go. So it makes sense to me because, as Tekton Chains did for provenance, we can do the same one for SBOMs, I mean generating, signing, and storing them behind the scenes. WDYT? We can create TEP for this if you want. 🤩

As per Priya's comment, wouldn't the second option only be able to support images, and in fact wouldn't it only support after the fact scans of the image?

A lot of plugins for SBOM generate the SBOM at build time, and generally that's a better process than scanning after the fact. For flexibility purposes I like the first option as it's more or less what we already do with stuff like signing images. e.g. it's the responsibility of the Task to generate an image, it's the responsibility of Chains to sign the image.

tekton-robot commented 2 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

priyawadhwa commented 2 years ago

/remove-lifecycle stale

xchapter7x commented 2 years ago

/area s3c

tekton-robot commented 2 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

developer-guy commented 2 years ago

I'm going to write a TEP for this ASAP

tekton-robot commented 1 year ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten with a justification. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

priyawadhwa commented 1 year ago

/remove-lifecycle rotten

tekton-robot commented 1 year ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

msathe-tech commented 1 year ago

+1 for this requirement. SBOM is the missing piece in the Chains SLSA story. Option #2 is more simple. Chains can give a config option just like storage format to select the SBOM format. Default can be SPDX format. If Option #1 is chosen (and while Chains is still missing this feature) is there an example Tekton task to attach SBOM to the container image?

tekton-robot commented 1 year ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten with a justification. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

lcarva commented 1 year ago

/lifecycle frozen

(This is an important feature that we should add to Chains, thus adding a lifecycle exemption).

lcarva commented 1 year ago

If a TaskRun produces the SBOM, it seems odd to have Chains blindly sign it. This opens the door to problems that could reduce the trust of such signed SBOMs. However, combined with the image attestation (more specifically the PipelineRun attestation) the trust is established because the exact steps that generated the SBOM can be securely seen.

Given the amount of SBOM formats out there, adding support to all of them would be difficult to maintain. We have to also consider upcoming formats which may not be mature enough to be supported by Chains. A plugin mechanism could mitigate this, of course.

Between the two options, the first one seems like the right call.

Maybe we don't need to wait for https://github.com/tektoncd/pipeline/issues/4012. We could instead have a Task that produces an unsigned SBOM image, have Chains sign it, and either replace it or push to a different location. The only result needed would be the sbom image url and the sbom image digest.

sbose78 commented 1 year ago

+1, I like the first option too.