Tom Hennen

I think something might have gotten a bit screwy with the git commits (I've done this myself for sure). When I look at 'Files Changed' it doesn't look like anything...

I appreciate these changes, but the one big problem I see is that it erases the old 'vuln v0.1' predicate and replaces it with this new one. There are folks...

Would something like this work? ```jsonc { "_type": "https://in-toto.io/Statement/v1", "subject": [ { "name": "foo.jar", "digest": {"sha256": "fe4fe40ac7250263c5dbe1cf3138912f3f416140aa248637a60d65fe22c47da4"} } ], // Predicate: "predicateType": "https://in-toto.io/attestation/reference/v0.1", "predicate": { "referrer": { "id": "http://example.com/sbom_generator" },...

Would it make any sense to rename this issue to 'Add a reference predicate' with the goal of "allowing an attestor to point to out-of-band data" or something like that?...

This is an interesting idea and could have other benefits. Thanks for outlining the concerns w.r.t. the current Scorecards architecture, we'd definitely need to address those if we pursued this...

Oh, I'd like to add that I think there are some questions with respect to scorecards: 1. Could Scorecards issue the required attestations instead of requiring it of the Source...

Talked with @msuozzo about this briefly. It seems it would be reasonable to have two attestations One predicate type for observed source security properties of some source control system. This...

Yes, that's exactly what I'm thinking! Though it may only apply to commit hashes that have been merged to certain branches.

Took a quick look at crev, it does look interesting. So far we've left it up to the source control systems as to how they want to handle requiring reviews....

Added the slsa-provenance label because this is pretty related to SLSA (it's about the SLSA source requirements) so we might want to move it to the SLSA repo...