[POC] Provisioner for SBOM

[devashish-patel]

Example templates:

JSON:

{
  "builders": [
    {
      "type": "docker",
      "image": "ubuntu:20.04",
      "commit": true
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": [
        "apt-get update -y",
        "apt-get install -y curl",
        "bash -c \"$(curl -sSL https://install.mondoo.com/sh)\""
      ]
    },
    {
      "type": "shell",
      "inline": [
        "cnquery sbom --output cyclonedx-json --output-target /tmp/sbom_cyclonedx.json"
      ]
    },
    {
      "type": "hcp_sbom",
      "source": "/tmp/sbom_cyclonedx.json"
    }
  ]
}

HCL:

packer {
  required_plugins {
    docker = {
      version = ">= 1.0.0"
      source  = "github.com/hashicorp/docker"
    }
  }
}

source "docker" "ubuntu" {
  image  = "ubuntu:20.04"
  commit = true
}

build {
  sources = ["source.docker.ubuntu"]

  provisioner "shell" {
    inline = [
      "apt-get update -y",
      "apt-get install -y curl",
      "bash -c \"$(curl -sSL https://install.mondoo.com/sh)\""
    ]
  }

  provisioner "shell" {
    inline = [
      //"cnquery sbom --output cyclonedx-json | tee /tmp/sbom_cyclonedx.json",
      "cnquery sbom --output cyclonedx-json --output-target /tmp/sbom_cyclonedx.json",
    ]
  }

  provisioner "hcp_sbom" {
      source      = "/tmp/sbom_cyclonedx.json"
      //destination = "sbom_cyclonedx.json"
  }
}

[lbajolet-hashicorp]

Left a bunch of comments on the code, I think we can simplify the download to have it done once only, technically once we've copied the file locally for Packer, we can copy it to the user-specified destination (if specified). That or we can factorise the code for downloading since it's very similar.
I'll let you address those comments and do another pass of review after that.

[lbajolet-hashicorp]

Is there a reason why we keep this as part of the provisioner? Since we only create the file during Prepare and wipe it by the end, it doesn't seem that we need it here

[lbajolet-hashicorp]

Since the underlying provisioner writes to this file, we should not defer its closure I'd think, typically on Windows this might fail depending on the kind of Handle we've received from CreateTemp

[lbajolet-hashicorp]

At this point p.TempFileLoc was not set, so this won't work I'd think, since the parameter will be empty when the function executes?

[lbajolet-hashicorp]

You can use a function like os.ReadFile here instead of manually opening/reading/closing it.

[lbajolet-hashicorp]

This should become a log.Printf, if not removed completely imho

[lbajolet-hashicorp]

Given that the alternative has only one instruction, you can probably invert this logic here

Suggested change

	if !ok {
	continue
	}
	b.SBOMFilesCompressed = append(b.SBOMFilesCompressed, sbomInternalProvisioner.CompressedData)
	if ok {
	b.SBOMFilesCompressed = append(b.SBOMFilesCompressed, sbomInternalProvisioner.CompressedData)
	}

[lbajolet-hashicorp]

Won't that fail if the directory doesn't exist? Since we create the hierarchy below if not existing, we should assume that the directory doesn't already exists before attempting to create it, so failing here feels off.

[lbajolet-hashicorp]

This is suspiciously similar to the downloadSBOMForPacker function's code, we might be able to factorise the implementation I'd think, if only to avoid unnecessary repetition

[lbajolet-hashicorp]

Ping on this one @devashish-patel, we talked about this out-of-band, just want to kickstart a conversation on this line of work

[lbajolet-hashicorp]

We should report errors here, the function should return an error if something went wrong, as the user requests the SBOM be kept somewhere else, if it fails for some reason, so should the provisioner

[lbajolet-hashicorp]

This heuristic seems brittle, the output can be a directory even if the path doesn't end with /, we should rely on os.Stat regardless to know if this is a directory, irrespective of what the path looks like