Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Predicate for Open Source Program Office (OSPO) Governance #297

Open
geekythoughts opened this issue Nov 5, 2023 · 0 comments
Open
Assignees

Comments

@geekythoughts
Copy link

What's your use case?

Many organizations/companies utilize some form of an Open Source Program Office (OSPO) to review and approve each artifact in the software bill of materials to ensure the artifact complies with the organization/company's legal, contractual/customer/client, and/or other internal policy constraint. To comply with organization/corporate/legal policies, developers in these organizations leverage their OSPO to request and obtain vetted versions of software (this could include FOSS as well as COTS). An OSPO may leverage internal tools that developers within the organization/company use to request new/updated versions of software and download them (usually from a central proxy cache). An attestation with an ospo-governance predicate would attest that the artifact(s) have been vetted by the OSPO.

Why don’t existing predicates cover this use case?

Existing predicate types including SPDX, CycloneDX, SLSA-VSA, and SCAI capture the process, functionality, or evidence used by a producer of an artifact. As mentioned in the SCAI spec, SPDX and CycloneDX, and SLSA covers coarse-grain and build service information. The "ospo-governance" attestation will typically consume attestations such as SPDX, CycloneDX, SCAI, and/or SLSA-VSA to contribute to the "ospo-governance" predicate result; however, the OSPO uses internal policies to produce the "ospo-governance" predicate for artifact(s).

What might a new predicate type for your use case look like? (concrete examples in JSON or CUE preferred)

NOTE: additional predicate attributes still need to be defined

"_type": "https://in-toto.io/Statement/v1",
"subject": [{
  "name": <NAME>,
  "digest": { <digest-in-request> }
}],

"predicateType": "https://in-toto.io/attestation/ospo-governance/v0.1",
"predicate": {
    "ospoStatus": "<String>"
}

Example for a new package requested for use to the OSPO but the OSPO is still reviewing the package (hence the UNDER_REVIEW status):

"_type": "https://in-toto.io/Statement/v1",
"subject": [{
  "name":  "log4j-core",
  "purl": "pkg:maven/org.apache.logging.log4j/[email protected]?type=jar",
  "digest": { <digest-in-request> }
}],

"predicateType": "https://in-toto.io/attestation/ospo-governance/v0.1",
"predicate": {
    "ospoStatus": "UNDER_REVIEW"
}

The example below shows the same package as approved by the OSPO:

"_type": "https://in-toto.io/Statement/v1",
"subject": [{
  "name":  "log4j-core",
  "purl": "pkg:maven/org.apache.logging.log4j/[email protected]?type=jar",
  "digest": { <digest-in-request> }
}],

"predicateType": "https://in-toto.io/attestation/ospo-governance/v0.1",
"predicate": {
    "ospoStatus": "APPROVED"
}

What policy questions do you want to be able to answer with the predicate?

  • Are all components (via a CycloneDX/SPDX attestation) used to build MyCompany FancyApp APPROVED by MyCompany's OSPO?
  • Are all components in my CycloneDX SBOM attestation have the "OSPO-governance" attestation?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants