POLICY for "Organization Requirements"

[TomHennen]

Should the policy for tooling that evaluates a SLSA level include or ignore the Organization Requirements?

Rationale to include: these are part of the requirements. If the tooling doesn't take them into account then downstream users won't get the full picture.

Rationale to exclude: It's unclear how the tooling could take some of them into account, like "canonical location" or "distribute * attestations". Those requirements are on the organization documenting things. How does the tool know where they're documented?

Option 1: maybe the tool takes those answers as parameters? Or, perhaps, "canonical location" isn't needed (since it can perhaps be handled via SLSA Build Provenance). Then distribution is easier to handle since the tool itself can handle the distribution question.

Option 2: maybe end users define the POLICY that gets linked in the VSA. And it can be documented there? Seems like a lot of work.

[mlieberman85]

By policy, do you mean the canonical location for the policy?

[TomHennen]

So, in part I'm trying to fill out https://github.com/slsa-framework/slsa-source-poc/blob/main/POLICY.md which is the rationale for how this PoC will determine any particular source level. I'm currently having the policy.uri in the VSA link to that file.

However, I could imagine instead saying "Users should define their own POLICY.md that defines these things and we'll link to that instead", but that seems very messy. We don't want users to redefine the whole thing, but rather a subset. So we'd probably want to link to something else (not just markdown) instead... if we decide to go that route.

[mlieberman85]

So, this is something that security insights hopes to solve. I have issues with the current implementation however: https://github.com/ossf/security-insights-spec

The idea could be to have something like a machine readable document that describes a lot of these things. However, we've just pushed some of the problems to a different spot.

[TomHennen]

So, this is something that security insights hopes to solve. I have issues with the current implementation however: https://github.com/ossf/security-insights-spec

The idea could be to have something like a machine readable document that describes a lot of these things. However, we've just pushed some of the problems to a different spot.

Right, that would be unsatisfying. I'd honestly prefer something that requires as little of end-users as needed. If we can get what we really want from these requirements elsewhere (like saying "we get the canonical source repo from the build provenance") that would be ideal.

[TomHennen]

Maybe one option, when the spec requirements orgs to document something, is that the tool makes a link to that documentation an input to the workflow and then can somehow expose that information in the repo? Sort of like how Scorecards add stuff? (I'm out of my depth here and don't actually know how that would work).

[TomHennen]

Maybe "Solution 2" from #8 will be good enough if the tool itself handles the attestation distribution?