Use Case: Attestations of alignment to S2C2F and org overlays

[pdxjohnny]

This is very much a work in progress, largely unstarted, just posting here to consolidate notes first transparently

WIP DRAFT: https://github.com/pdxjohnny/use-cases/blob/openssf_metrics/openssf_metrics.md

Related: #14
Related: https://github.com/ossf/s2c2f/blob/main/specification/framework.md#appendix-relation-to-scitt
Related: intel/dffml#1454

This use case will be mostly focused on the policy / gatekeeper component and federation components of SCITT.

• 5.2.2: Registration Policies
  • Simple decoupled file based policy engine scitt-community/scitt-api-emulator#27
• 7: Federation
  • Federation via ActivityPub scitt-community/scitt-api-emulator#37

This use case is a specialization of (cross between) the following use cases from the Detailed Software Supply Chain Uses Cases for SCITT doc.

• 3.3: Security Analysis of a Software Product
  • We'll cover OpenSSF Scorecard and other analysis mechanisms including meta static analysis / aggregation (example: GUAC).
• 3.4: Promotion of a Software Component by multiple entities
  • We'll cover how these entities can leverage analysis mechanisms to achieve feature and bugfix equilibrium across the diverged environment.
    • Future use cases could explore semantic patching to patch across functionally similar projects.

---

• RFCv2: IETF SCITT: Use Case: OpenSSF Metrics: activitypub extensions for security.txt
• RFCv3: IETF SCITT: Use Case: OpenSSF Metrics: activitypub extensions for security.txt
  • RFCv3.2: IETF SCITT: Use Case: OpenSSF Metrics: activitypub extensions for security.txt
• RFCv4: IETF SCITT: Use Case: OpenSSF Metrics: activitypub extensions for security.txt
  • RFCv4.1: IETF SCITT: Use Case: OpenSSF Metrics: activitypub extensions for security.txt
  • RFCv4.2: IETF SCITT: Use Case: OpenSSF Metrics: activitypub extensions for security.txt
• RFCv5: IETF SCITT: Use Case: Attestations of alignment to S2C2F and org Overlays
  • RFCv5.1: IETF SCITT: Use Case: Attestations of alignment to S2C2F and org Overlays
  • RFCv5.2: IETF SCITT: Use Case: Attestations of alignment to S2C2F and org Overlays
• RFCv6: IETF SCITT: Use Case: Attestations of alignment to S2C2F and org Overlays
  • RFCv6.1: IETF SCITT: Use Case: Attestations of alignment to S2C2F and org Overlays

---

2022-07-20 OpenSSF Identifying Security Threats WG Meeting Notes

• Mike leading
• ... clipped not directly related notes ...
• Amir: Security Reviews
  • Repo is looking good
  • Updating with four new audits that ostif.org published last week
  • At almost 100 reviews from Mike (Omega work), ostif.org, and community
  • We're gaining traction, getting good stuff in there all the time
  • Might need some help with the automated testing that get's done
    when we upload reviews.
  • Feedback always welcome.
• Christine
  • Looking at trying to connect all the different data sources
• John: Collection of metric / Alpha-Omega data into shared DB
  • https://github.com/intel/dffml/tree/alice/docs/tutorials/rolling_alice
  • https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-architecture
  • https://www.w3.org/2022/07/pressrelease-did-rec.html.en
  • https://docs.microsoft.com/en-us/azure/confidential-ledger/architecture
  • Mike
    • Mike has been thinking about SCITT as a schema and rules on how one would assert facts, weither it's confidential compute or traditional permissions is implementation details.
    • If metircs runs across you're repo and you have 30 contributors, great
    • As consumer, how can I discover that fact and trust that it's accruate
    • Could immaiget a world where things like Scorecard express the data as as SCITT assursion
    • You go and query that store and you say tell me everythig you know about foo and you get it all back
    • Until we have an implementation with WEb5 that's at at least beta, we could expore what that looks like.
      • John: We can do rekor for now, we'll bridge it all later target 1-2 years out
      • John: We have alignment. Time to execute. rekor + sigstore for metric data atteststation signed with github odic tokens. We care about data provenance. We will later bridge into web5 space used as central points of comms given DID as effectively the URL or the future (via SCITT). This is in relation to AI ethics data provenance. We need to start planning how we are going to build up this space now so we can have provenance on thoughts later. This provenance could be for example on inference derived from provenance from training data and model training env and config. This will allow us to ensure the prioritizer make decisions based on Sprit of the law / aka intent based policy derived from Trinity of Static Analysis, Dynamic Analysis, and Human Intent.
        • Living Threat Model threats, mitigations, trust boundaries as initial data set for cross domain conceptual mapping of the the trinity to build pyramid of thought alignment to strategic principles.
        • One of our strategic plans / principles says: "We must be able to trust the sources of all input data used for all model training was done from research studies with these ethical certifications"
          • This allows us to write policies (Open Policy Agent to JSON to DID/VC/SCITT translation/application exploration still in progress) for the organizations we form and apply them as overlays to flows we execute where context appropriate. These overlaid flows define the trusted parties within that context as applicable to the active organizational policies as applicable to the top level system context.
          • The policy associated with the principle that consumes the overlaid trust attestations we will implement and LTM auditor for which checks the SCITT provenance information associated with the operation implementations and the operation implementation network, input network, etc. within the orchestrators trust boundary (TODO need to track usages / reuse of contexts ictx, nctx, etc. with something predeclared, aka at runtime if your Operation data structure doesn't allowlist your usage of it you can pass it to a subflow for reuse. This allows us to use the format within our orchrestration and for static analysis because we can use this same format to describe the trust boundry proeprties that other domain sepcific represenatations of architecture have, for instance we could if we were doing and Open Architecture (OA) Intermediate Representation (IR) for and ELF file we might note that the input network context is not reused from the top level system context. Where as if we did an OA IR for Python code we would say that the input network is reused from the top level system context (it has access to that memory region, whereas when you launch and ELF you look access to the parents memory region, typically).