specification first cut #9
Conversation
| honest. When malicious parties interfere in the process, SBOMit provides | ||
| a mix of traceability (knowing which party was malicious) and prevention | ||
| (blocking malicious software from being trusted), depending on how the | ||
| in-toto steps are configured.. |
There was a problem hiding this comment.
this also depends on what the attacker has compromised. A compromised key/malicious user could be traced, while an unauthorized user could be prevented, etc
|
|
||
| #### SIT | ||
|
|
||
| A SIT may be verified in two ways. |
There was a problem hiding this comment.
who verifies an SIT vs an SBOMit document? Should the SIT verifier get some assurance that someone checked the SBOMit document?
There was a problem hiding this comment.
I don't know if this is possible to do. A SIT is an SBOM (CycloneDX, SPDX, etc.) and I don't think we can add custom verification (as I understand it).
There was a problem hiding this comment.
It would be nice if we could at least add an attestation that someone verified the full SBOMit document (maybe as a wrapper around the SBOM verification). Otherwise the end user is only getting a signed SBOM
There was a problem hiding this comment.
I'm fine but if they have to add functionality to their SBOM verification, then it seems like they could just do the SBOMit document verification. Or do you think that people will want to just check the attestation and then say it is okay?
I see checking an attestation as roughly equivalent to signing the SBOM with the attestation key.
| First, the SBOMit document may be downloaded and then verified. This provides | ||
| strong security guarantees, but is a fairly heavyweight operation. | ||
|
|
||
| Second, the SIT may have its signature checked, much like any signed SBOM. |
There was a problem hiding this comment.
How is the key for this distributed?
There was a problem hiding this comment.
I'm imagining the same as you would usually for an SBOM. I'm actually not completely clear how this process works in every case today. I imagine it is like in-toto layout keys, where they are just assumed to exist on the client, but I would love to learn the "correct" way, if I'm wrong.
| ## Introduction | ||
|
|
||
| ### Motivation | ||
| A major problem with the state of an SBOM today is that the documents are | ||
| often inaccurate. This is largely because the documents are derived by looking |
There was a problem hiding this comment.
OK, but "inaccurate" in what sense? When practitioners like @hosseinsia say that an SBOM is "inaccurate," they mean that the list of dependencies may be incomplete or even inaccurate. The meaning written here is quite different, and not yet what people who need SBOMs worry about in practice. I think we need a stronger motivation with a better story.
There was a problem hiding this comment.
As @trishankatdatadog mentioned, at the moment inaccurate means that different tooling might produce SBOM with different list of dependencies, some of which do not really exist or are not used in a software, and some others might not be detected due to them being added dynamically later or through chains of dependencies.
However, one thing that is lacking in almost all of SBOM reports (and I believe in-toto can help) is a mechanism to verify their claims. At the moment, you have to reproduce SBOM using the tooling or other's tooling and compare two SBOM files (semantically, as the formats and order of them might be different). In my ideal world, if SBOMit could provide a proof/reasoning why a SBOM tool believes that this dependency should be included would be really useful. Basically that is my interpretation of 'verifiable SBOM'
There was a problem hiding this comment.
Okay, would you like to take a cut? I don't have enough context on how people are using SBOMs in different steps.
| ### Motivation | ||
| A major problem with the state of an SBOM today is that the documents are | ||
| often inaccurate. This is largely because the documents are derived by looking | ||
| at the resulting software and trying to understand what happened in the past. |
There was a problem hiding this comment.
There are different places that SBOM is generated. One could be sourcecode-based SBOM. In that case, this statement does not really fit. I think the only place this makes sense is when SBOM is generated after build (like the way Software Composition Analysis (SCA tooling) works). There are also other tooling that can extract SBOMs at runtime, and that have the capability of extracting list of dynamic dependencies.
| at the resulting software and trying to understand what happened in the past. | ||
|
|
||
| This specification proposes a means to generate metadata for an SBOM while the | ||
| software is being created. Furthermore, the means by which this information |
There was a problem hiding this comment.
This is called build-time SBOM. Do you want to limit SBOMit to that?
There was a problem hiding this comment.
No, we want to cover all cases, as in-toto does.
There was a problem hiding this comment.
Ok. Then the phrase SBOM while the software is being created might need to be revised to prevent others implying build-time SBOM.
| hold, so that a party cannot appear to be innocent given a re-execution of a | ||
| supply chain with all honest participants. | ||
|
|
||
| * prevention -- this is when an attack is blocked from having any impact. This |
There was a problem hiding this comment.
Does this include attacks such as dependency confusion attacks?
There was a problem hiding this comment.
I talk about this below with the OSS risks...
| in-toto steps are configured.. | ||
|
|
||
|
|
||
| ### Definitions |
There was a problem hiding this comment.
I'm not crazy about these names. They are not immediately self-descriptive, and I think we can do better.
There was a problem hiding this comment.
I'm open to changing them, especially SIT. I just threw that together on the flight.
|
|
||
| ### Definitions | ||
|
|
||
| SIT -- An SBOM which is derived from a SBOMit document. It can |
There was a problem hiding this comment.
Interesting: by "derived," do you mean that an SBOMIT document is something like a high-level intermediate representation from SBOMs that can then be used to generate low-level "machine code," so to speak?
There was a problem hiding this comment.
Yes, you can think of it this way. It is like the complete "source" document which contains things like in-toto metadata which will not be in the SBOM (SIT).
| One key goal of our design is to provide as much security as possible in all | ||
| cases. Security should degrade gracefully when the attacker gains new | ||
| capabilities. Hence, we will consider attacker models where the attacker is | ||
| exceedingly powerful and try to restrict the damage they can do even in those |
There was a problem hiding this comment.
"exceedingly powerful" is still a little bit wishy-washy. Can they, for example, compromise all of the keys used to sign root layouts?
There was a problem hiding this comment.
Yes. I list that case below.
| can show this was the cause, but users will trust a new, maliciously | ||
| generated layout which replaces signing keys. | ||
|
|
||
| From (Endor Lab's top 10 OSS risks)[https://www.endorlabs.com/blog/introducing-the-top-10-open-source-software-oss-risks], |
There was a problem hiding this comment.
Maybe this should come much earlier. I really don't understand what this threat model is trying to say. What sort of attacker goals are we most worried about? Those tampering with just the list of dependencies, or does the tampering extend to the software artefacts themselves?
There was a problem hiding this comment.
This covers both cases. I don't want to describe someone else's work here, but wanted to give some pointers to an external list to show we're handling a broad set of cases.
trishankatdatadog
dismissed
their stale review
Accidentally chose "Approve" instead of "Comment"
Co-authored-by: Trishank Karthik Kuppusamy <[email protected]>
This isn't quite ready, but has a fair number of ideas in it which I'd like review on. Don't merge this PR until we iterate a bit...