Hackathon to create S2C2F Attestation Schema + Tool - Week of Sept 11th, 2023

[adriandiglio]

Hey OpenSSF!

We are launching a Hackathon the week of Sept 11th to create a schema in OSCAL format for capturing conformance to S2C2F requirements, along with a tool to auto-generate the machine-readable (JSON) OSCAL file. This project will be "born in the OpenSSF". We already have our repo created here that we'll use: https://github.com/ossf/S2C2F-attestation-schema-and-tool

This initiative aligns with our S2C2F Strategic goals for Driving Tooling Innovation, and Adoption.

There are 2 goals for this project:

1. Define a schema for representing S2C2F compliance in JSON format using https://pages.nist.gov/OSCAL/
2. [If we get enough engineers] Build a POC in GitHub that auto-generates a machine-readable (JSON) attestation file that captures the S2C2F compliance information at build time.

If you have questions, or want to participate, please join this Discussion!

[stevespringett]

You may want to consider trialing the new CycloneDX standards and attestation support coming in v1.6. The working group has been developing the spec over the last four months. We currently have support from Synopsys (BSIMM), PCI Council, OWASP (ASVS, MASVS, SCVS, SAMM), and have implemented SSDF as well.

Attestations, claims, evidence, counter evidence, conformance, and mitigation strategies are all implemented and should be ready to use. The team is currently working on signatures, signatories, and affirmations.

Anyway, something to consider.

[adriandiglio]

Thanks for the suggestion! To keep the scope of the Hackathon focused, we will be working with OSCAL as the first format. It's entirely possible that other formats could be used in the future, but in evaluating OSCAL, it perfectly meets our needs and is a familiar format used by many to meet FedRAMP and other compliance programs. Thanks!

[colek42]

Witness (https://github.com/testifysec/witness) has a plugin system and cosign support let us know know if this would fit in
c

[adityasaky]

+1 on exploring how Witness can be used here. It'd also allow us to explore how in-toto can be used which will mean a compatible attestation language across S2C2F, SLSA, and others!

[adriandiglio]

Thanks all for the suggestion! While in-toto does a great job for SLSA provenance, OSCAL is purpose-built for reporting conformance to requirements and aligns perfectly with our needs. We can leverage their schema instead of inventing our own, so this hackathon will be scoped to OSCAL. Thanks!

[jkjell]

in-toto simply wraps the specific content inside a SLSA provenance document and I'm think it could do that for OSCAL documents too, giving cryptographic verification and trust. I don't know a whole lot about OSCAL but, I couldn't find any references to information on how to establish trust for OSCAL documents. Totally get limiting scope for this Hackathon. ☺️ Just trying to get a sense of this could be more useful later on.

[colek42]

@adriandiglio Sorry for the confusion. I was thinking along the lines of #2 "[If we get enough engineers] Build a POC in GitHub that auto-generates a machine-readable (JSON) attestation file that captures the S2C2F compliance information at build time."

My initial thought would be to use Witness to generate in-toto attestations containing signed (with sigstore) build metadata, this metadata could be evaluated against a OSCAL schema using a in-toto layout/witness policy.

You can see some examples of the attestations we can generate here: https://judge.testifysec.io/?s=a6a8215d1d2e83143f3208bacc1cd979350ac199, but the attestor system is pluggable and it is fairly straight forward to create attestors that make different claims.