Open mthalman opened 1 year ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
[Triage]
One option that could be explored is to include execution of the ManifestGeneratorTask
after the explicit step which generates the SBOMs. That may perhaps detect the SBOMs on disk and get them signed. Not sure on that, but if it that works it's a hacky approach to solving this. Ideally, there would be a process that clearly indicates the intent to have the SBOMs signed.
This work should be incorporated into the work for signing images: https://github.com/dotnet/dotnet-docker/issues/4589.
The implementation here that currently uses the ManifestGeneratorTask could potentially be simplified by acquiring the sbom-tool directly: https://github.com/microsoft/sbom-tool?tab=readme-ov-file#download-and-installation
EDIT: Even better, we could potentially include the sbom-tool in the ImageBuilder container and call it from there instead of using Pipeline code.
The build stage of the pipeline generates SBOMs using this logic:
https://github.com/dotnet/docker-tools/blob/9791b1592829efbcd4da15a4aabed083b66615b7/eng/common/templates/jobs/build-images.yml#L128-L176
The use of the ManifestGeneratorTask is only used as an "installer" in order to acquire the manifest tool that gets executed in the second step. It's done this way because of the need to have a separate SBOM for each image (see https://github.com/dotnet/docker-tools/issues/979). So the SBOM generation occurs in the second step. But the logic for signing the SBOMs actually occurs in the first step via the ManifestGeneratorTask. This means we're not getting the benefit of signing because we're not using the task to generate the SBOMs. And that means none of our SBOMs are signed.
I've logged a related issue for the manifest generator to have another tool that can be used for signing: https://github.com/microsoft/dropvalidator/issues/668