SBOM file generation.

[jvanz]

Adds new steps in the build and release workflow to generate, sign and publish a SBOM file for Policy Server.

Fix #305

[viccuad]

Looks good!
I like how the signing of the artifacts happens in the same job as the build, and the release job just consumes the signed artifacts already.

I wonder though, if we could keep the release job in the .github/workflows/release.yml workflow file. I feel it's clearer to set everything in one file with:

on:
  push:
    tags:
    - 'v*'

and not use if: github.ref_type == 'tag'.

I wonder also if by having it in a different workflow, it's more easy to find the release job in the github pop-ups of commits and so.

[jvanz]

@viccuad , in order to have a more complete SBOM file, the tool needs access to the files generated by the build. Thus, the release workflow needs to have access to the target directory. That's the reason I've merged the release worflows into a single file. I can split it again and call the same worflows to build the binaries in both workflows (ci and release). Do you prefer that? One cons of this approach is that the build will run twice when a tag is released. What do you think?

[jvanz]

I don't understand if the final SPDX file will contain a list of all the dependencies of the policy-server binary (basically the contents of Cargo.lock).

As far as I could understand reading the spdx specification the file contains anything used to build the binary. Therefore, you can see all the files include in a package, the relationship between packages, checksum of everything, license and etc.

[flavio]

Thanks @jvanz, I was able to run the command locally.

I've looked at the _manifest/spdx_2.2/manifest.spdx.json file generated and I wonder how useful it would be.

For example, take a look at this snippet about the addr2line dependency:

    {
      "fileName": "./deps/addr2line-28aec851f2e54f6a.d",
      "SPDXID": "SPDXRef-File--deps-addr2line-28aec851f2e54f6a.d-19D14F2B41953D84DFBB935FED640F81D0809DFA",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "4512d8e3dd2ea20f9b30e414254f9f04dcd8991d764b6f1a6d6b47abab74e6d2"
        },
        {
          "algorithm": "SHA1",
          "checksumValue": "19d14f2b41953d84dfbb935fed640f81d0809dfa"
        }
      ],
      "licenseConcluded": "NOASSERTION",
      "licenseInfoInFiles": [
        "NOASSERTION"
      ],
      "copyrightText": "NOASSERTION"
    },

This snippet doesn't tell me where the dependency is coming (crates.io release, a github repository,...) and it doesn't tell me the version being used. I can see what I assume is a git commit shasum inside of the folder name ./deps/addr2line-28aec851f2e54f6a.d.

This isn't what I expected to find inside of a SPDX report.

I did some quick search, and I ran opensbom-generator/spdx-sbom-generator in this way:

$ spdx-sbom-generator

This produced a bom-cargo.spdx which has contents that are more aligned with what I was expecting. For example, taking the same addr2line dependency:

##### Package representing the addr2line

PackageName: addr2line
SPDXID: SPDXRef-Package-addr2line-0.17.0
PackageVersion: 0.17.0
PackageSupplier: NOASSERTION
PackageDownloadLocation: https://github.com/gimli-rs/addr2line
FilesAnalyzed: false
PackageChecksum: SHA1: 59f51ecbe91443fc78708b82c2ad39645cba5d9d
PackageHomePage: https://github.com/rust-lang/crates.io-index
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseComments: NOASSERTION
PackageComment: NOASSERTION

Relationship: SPDXRef-Package-addr2line-0.17.0 DEPENDS_ON SPDXRef-Package-rustc-demangle-0.1.21 
Relationship: SPDXRef-Package-addr2line-0.17.0 DEPENDS_ON SPDXRef-Package-smallvec-1.9.0 
Relationship: SPDXRef-Package-addr2line-0.17.0 DEPENDS_ON SPDXRef-Package-backtrace-0.3.66 
Relationship: SPDXRef-Package-addr2line-0.17.0 DEPENDS_ON SPDXRef-Package-clap-3.2.17 
Relationship: SPDXRef-Package-addr2line-0.17.0 DEPENDS_ON SPDXRef-Package-cpp-demangle-0.3.5 
Relationship: SPDXRef-Package-addr2line-0.17.0 DEPENDS_ON SPDXRef-Package-fallible-iterator-0.2.0 
Relationship: SPDXRef-Package-addr2line-0.17.0 DEPENDS_ON SPDXRef-Package-gimli-0.26.2 
Relationship: SPDXRef-Package-addr2line-0.17.0 DEPENDS_ON SPDXRef-Package-object-0.29.0 

This looks more "human-friendly".

Now, I'm not suggesting we have to move to this other tool. I just wonder if we are not invoking the Microsoft one with the right set of parameters.

[viccuad]

@flavio here, the sbom-tool outputs the expected contents for addr2line (in fact, the same you pasted). After applying #312 (comment).

[jvanz]

@viccuad @flavio , I've updated the PR to use the spdx-sbom-generator tool and generate the right packages dependencies.

Furthermore, I've also open an issue in the sbom-tool to know why we cannot get the right packages dependencies relationships from cargo file.

[viccuad]

Maybe we could sign the binary and upload the binary and its signature to the interim artifacts.
The signatures could be checked when building the container image. I suppose this may be needed for SLSA.
Not much improvement for our current security stance, as we depend on GHA and artifacts anyway. But in the future we could build in our own worker.

[flavio]

Yes, I think this would be a nice improvement. However I would not block this PR to get this implemented, I would rather file a new issue

[jvanz]

That's sound a good idea indeed. I've just created an issue to keep track of this improvement.

[viccuad]

Approving, I'm happy to merge as it is.

We could add SBOM for both build image and resulting container image in following PRs.

[flavio]

LGTM, I left some minor comments that are not mandatory to get this PR merged

[flavio]

Yes, I think this would be a nice improvement. However I would not block this PR to get this implemented, I would rather file a new issue