new SBOM parser

[developer-guy]

There is a concept called SBOM (Software Bill Of Materials), and there are various tooling around this^1^3 concept to generate it. There are several methods designed specifically for delivering SBOMs, including SPDX (Software Package Data Exchange), Software Identification (SWID) Tags, and Cyclone DX.

Wouldn't be nice if we support validating these types of SBOM specs via rego-based policies in conftest.

cc: @luhring @nishakm @puerco 🥳🙋🏻‍♂️

[luhring]

I love this idea... although I'll admit I'm pretty new to OPA. Is the idea that we'd enable validation of SBOMs based on their content (e.g. must not include dependency X), or more about validating compliance of SBOM documents with a given SBOM standard/schema?

Is this the right place to learn more about how the implementation might work? https://www.openpolicyagent.org/docs/latest/extensions/

Syft exports a Go library API that can perform all of its functionality. I'm assuming we'd wrap this somehow?

[jalseth]

To the best of my knowledge, these SBOMs are structured data (typically JSON or XML) which conftest already supports parsing, so I don't think there's any need to update conftest to support them. What would be good to have is a set of community Rego libraries that implement common operations on these documents, but that's outside the scope of the conftest project.

If they are using other formats that conftest doesn't currently support, please link to the specifications for the format and we can look into adding additional parsers for them.

[developer-guy]

hello @jalseth, yes, I was aware of that while opening this issue but the thing is I thought that it would be nice to support SBOMs both (Cyclone DX and SPDX format) in the first place and treat them like a separate format rather than JSON or XML.

[developer-guy]

I'm saying that because they have predefined specifications, for example: for Cyclone DX^1, and for SPDX^2. So, again, that would be nice to treat them like a special format.

[nishakm]

@jalseth From a tools perspective, creating consumers for known SBOM standards helps with tool interoperability which would be awesome! I would be happy to help with the SPDX parser :)

[jalseth]

OK, after further reading I think the desired outcome of this would be to support the plaintext formats for the SBOMs in addition to their structured JSON/XML formats? If so that makes sense and I'd welcome PRs. It would also be good to open issues for each format that needs to be implemented (again with a link to the spec and/or examples) so that the work can be better tracked.

[developer-guy]

OK, after further reading I think the desired outcome of this would be to support the plaintext formats for the SBOMs in addition to their structured JSON/XML formats?

Yeah, exactly. Let me explain it to you by giving an example, here is my thought about the SBOM validation belonging to SPDX.

Let's consider this repository for SPDX examples.

package main

deny[msg] {
    input[i].FileChecksum.SHA1 == "20291a81ef065ff891b537b64d4fdccaf6f5ac02"
    msg = sprintf("sha1 format of the filechecksum is invalid: %s", [input[i].FileName])
}

Btw, I'm not sure about how to do this parser, maybe @jalseth you can help me with it, waiting for your thoughts too.

also, WDYT @nishakm, is it useful?

[jalseth]

@developer-guy I'd imagine you'd want to use https://github.com/spdx/tools-golang to handle the parsing from the file into the struct. From there it isn't much work to plumb that to the OPA/Rego engine since it accepts an interface{} for input. I may work on adding this if I have time, but it would be great to receive a PR from the community!

[developer-guy]

@jalseth I'm a volunteer for doing this, may I take a look at it? Can you please assign it to me? 😍

[developer-guy]

for the other one we can use this https://github.com/CycloneDX/cyclonedx-go

[developer-guy]

friendly ping @jalseth

[jalseth]

@developer-guy I would welcome PRs! Please keep the SPDX and CycloneDX changes separate so they're easier to review.