Skip to content

Latest commit

 

History

History
1178 lines (1058 loc) · 77.6 KB

openssf_metrics.md

File metadata and controls

1178 lines (1058 loc) · 77.6 KB
Raw

Use Case: Attestations of alignment to S2C2F and org Overlays

Pull Request Review (WIP): ietf-scitt#18

Collection of metric data into shared database (crowdsourcable OpenSSF Metrics). There are many repos to search, we want to enable self reporting and granularity as applicable to ad-hoc formed policy as desired by end-user.

  • Related: https://github.com/ossf/s2c2f/blob/main/specification/framework.md#appendix-relation-to-scitt
  • This use case will be mostly focused on the policy / gatekeeper component and federation components of SCITT.
    • 5.2.2: Registration Policies
    • 7: Federation
  • 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
  • Alice builds a python Package
    • Notary checks for receipts from needed sign offs
      • In this example the SCITT instance the notary inserting into it have the same insert/sign policies (system context, dataflow, open architecture document, living threat model)
        • Alice has two jobs, one which bulds a Python package, and other which runs SCITT in a TEE (perhaps with a redis service container to ease comms)
          • She auths to job in TEE (SGX in this example) local SCITT via OIDC, the SCITT notary and ledger are unified in this example and a claim is inserted that she had a valid OIDC token for job_workflow_sha + repositoryUri + repository_id + job.. The enclave is then dumped at the end of the job so that it can be joined to an other transparency services. This enables decentralized hermetic builds via federation of transparency services (by grafting them into org sepcific registires ad-hoc via CD eventing of forge federation).
      • The notary is what's verifying the OIDC token.
        • We can runs-on an SGX machine to do that.
        • Using confidential compute and attribute based trust we can authenticate to a usage policy, this is the place for on/off chain contract negotiation.
          • Off chain would be whenever we have to enter a hermetic enviornment (IPVM).
    • Activity Pub Actors for signoff, send to inbox requesting signoff (issue ops), they say okay I'll add this exception sign off for this use case /system context to SCITT
      • Then policy violating system context collects all needed exception receipts, listens for their entry via listening to the SCITT ActivityPub stream, and then re-issues request for admissions along with exception receipts using overlay section of serialized system context object

ActivityPub extensions for security.md/txt contact URIs

2023-03-16: This will get reworked heavily as we align across https://codeberg.org/forgejo-contrib/discussions/issues/12, Rapunzel, and Alice

A methodology allowing organizations to nominate security contact points and policies via ActivityPub Actors. This allows for notifications to be federated of new lifecycle events. These lifecycle events might be VEX, SBOM, CSAF security advisory information, repository events, etc.

VEX documents should be aligned with the either the https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html or OpenVEX specs: https://www.chainguard.dev/unchained/accelerate-vex-adoption-through-openvex. We can then communicate the IDs via ActivityPub like so.

Summary

When entities find security issues in source code, the correct channel to report security issues can be found if the repo has an RFC 9116 security.txt file with a Contact field. This contact field can be a URL which points to an ActivityPub Actor.

Via traversal of ActivityPub AcivityStream objects, reporters are enabled to discover reporting endpoints. Researchers are also enabled to receive up to date events by following declared ActivityPub Actors. When a researcher finds a vulnerability, they can submit their evidence to an eNotary (could be self notarized). The eNotary attests validity of the vuln and then replys to ActivityPub threads to facilite communication of valid vuln to upstream.

Imagine the following YAML as a directed graph whose upleveled pesudocode form is:

bob_vcs_repo:
  security.txt:
    Contact: https://activitypub.securitytxt.activitypub.example.org/bob

activitypub_service:
  endpoint_url: https://activitypub.securitytxt.activitypub.example.org
  actors:
    bob:
      attachment:
        type: "PropertyValue"
        name: "activitypubextensions"
        value: "<a href=\"https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/1\" target=\"_blank\" rel=\"nofollow noopener noreferrer me\"><span class=\"invisible\">https://</span><span class=\"\">activitypub.securitytxt.activitypub.example.org/users/bob/statuses/1</span><span class=\"invisible\"></span></a>"
      statuses:
        - id: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/1"
          content: "activitypubextensions"
          replies:
          - "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/2"
        - id: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/2"
          inReplyTo: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/1"
          content: "activitypubsecuritytxt"
          replies:
          - "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/3"

        - id: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/3"
          inReplyTo: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/2"
          content: "https://github.com/opencontainers/image-spec/raw/v1.0.1/schema/image-manifest-schema.json"
          replies:
          - "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/4"
        - id: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/4"
          inReplyTo: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/3"
          content: "bob.registry.example.org/src_repo_name_contents_are_webhook_translated_to_vcs_push_manifest:sha256@babebabe"

        - id: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/5"
          inReplyTo: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/2"
          content: "did:web:registry.example.com:policy-as-code:blocklist%40sha256%3Aaaaaaaaa"
          replies:
          - "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/6"
        - id: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/6"
          inReplyTo: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/5"
          content: "did:web:registry.example.com:receipts:not_on_blocklist%40sha256%3Aaaaaaaaa"
    alice:
      statuses:
        - id: "https://activitypub.securitytxt.activitypub.example.org/users/alice/statuses/1"
          inReplyTo: "https://activitypub.securitytxt.activitypub.example.org/users/bob/statuses/4"
          content: "alice.registry.example.org/vex_contents_are_openvex_from_scratch:sha256@babebabe"
  • ActivityPub extensions for security.txt
    • Can you put things in @context?, yes. Unsure if other servers will propagate events.
    • It this piggybacking within the content approach interoperable today, yes.
  • Somewhere, something happened
    • Bob tells Alice what happened
    • Alice decides, do I care about what whappened? (the federated event)
      • It's the triage process
      • intel/cve-bin-tool#2639
      • Take upstream policy (attached to incoming via inReplyTo and or replies, you'd have to decide if you want to dereference these, perhaps based on reputaion of propagator to reduce attack impact)
graph TD
  subgraph lifecycle[BOM Component Trust Asserstion Generation Lifecycle]
    subgraph lifecycle_background[Background]
      watch_for_new_releases_on_repo[Scan: New Release / Tag on Repo]
    end
    subgraph lifecycle_submission[Submission]
      new_release[Scan: New Release / Tag on Repo]
      use_in_bom[Scan: Pulled into cached / downloaded PyPi index]
    end
    subgraph lifecycle_deployment[Scanning aka GUAC firewall pattern]
      is_on_latest[Scan release/tag]
      submit_to_allowlist[Submit repo and SHA of commit scanned as trust attestation: trusted/untrusted]

      use_in_bom --> is_on_latest
      new_release --> is_on_latest

      is_on_latest --> submit_to_allowlist
    end
    subgraph lifecycle_transparency_service[Transparency Service]
      add_to_ts[Add Trust Attestation to append only log]
      list_ts_trusted[Index of attestations with result: Trusted]

      add_to_ts --> list_ts_trusted
    end
    subgraph lifecycle_usage[Use in CI/CD]
      check_ts[Check Transparency Service for all BOM items]
      do_build_if_all_trusted[Run build if all trusted]

      check_ts --> do_build_if_all_trusted
    end

    submit_to_allowlist --> add_to_ts
    list_ts_trusted --> watch_for_new_releases_on_repo
    watch_for_new_releases_on_repo --> new_release

    list_ts_trusted --> check_ts
  end
Loading 
graph TD
subgraph home
h_prt[pull request target PRT flow]
subgraph home_tee
h_ts[transparency service]
end
h_guac[GUAC neo4j]
h_manifest[PEP 440 Manifest Change]
h_eval[Dependency Evaluation flow]

h_manifest -->|pull request submited triggers| h_prt
h_prt -->|source TCB protection ring admission control query<br>sync poll or waitformessage ActivityPub async| h_guac
h_guac -->|emit data for query not in graph| h_eval
h_eval -->|metric collection data<br>shouldi<br>home and new faraway| h_ts
h_ts -->|ActivityPub emit data added to graph<br>trigger ingest| h_guac

end

subgraph faraway
f_prt[pull request target PRT flow]
subgraph faraway_tee
f_ts[transparency service]
end
f_guac[GUAC neo4j]
f_manifest[PEP 440 Manifest Changed]

f_manifest -->|pull request submited triggers| f_prt
f_prt -->|source TCB protection ring admission control query<br>sync poll or waitformessage ActivityPub async| f_guac
f_ts -->|ActivityPub emit data added to graph<br>trigger ingest| f_guac

end

h_prt -->|admission control allowed dep change<br>create pull request to trigger downstream valdation<br>waitformessage and status check api<br>for downstream aka faraway results| f_manifest
f_guac -->|emit data for query not in graph| f_ts
h_ts -->|federate evaluated claims| f_ts
Loading 
graph TD
    subgraph bob[Bob's Cool Software]
      actor[ActivityPub Actor - &#x0040 bob&#x0040 forge.mycoolsoftware.example.com]
      actor_attachment[Attachment PropertyValue activitypubsecuritytxt]
      activitypubsecuritytxt_root_post[activitypubsecuritytxt root post]
      activitypubsecuritytxt_vcs_push[vcs.push root post]
      activitypubsecuritytxt_vcs_push_content[vcs.push content - content address of manifest instance in registry]

      actor --> actor_attachment
      actor_attachment -->|Link| activitypubsecuritytxt_root_post
      activitypubsecuritytxt_vcs_push -->|inReplyTo| activitypubsecuritytxt_root_post
      activitypubsecuritytxt_vcs_push_content -->|inReplyTo| activitypubsecuritytxt_vcs_push
    end

    subgraph alice[Alice]
      alice_shouldi_contribute[Static Analysis Result] -->|inReplyTo| activitypubsecuritytxt_vcs_push_content
    end
Loading
  • So no matter where you're executing, all the reporting and eventing is the same, because we are loosely coupled.
    • We can do fromjson in jq or we can do more advanced xargs chaining on the websocket for ad-hox dev work
    • We can shoot from the activitypub inbox receiver to a message queue for integration with existing celery
    • This way we sidestep all rate limiting except for when we have to preform write events to GitHub
    • Otherwise we always read GitHub data from cypher queries over the reboardcast data
      • We can also have listeners which reboardcast the resolved contents of content address style broadcast data (the top level, so if this sees a container image uri broadcast, it would be pulling it down and maybe rebroadcasting the results.yaml or whatever is they transform needed to rebroadcast that data.
      • This is our onramp into the linked data space, eventually KERI for backing comms security
  • We'll implement an InputNetwork fro DFFML so that every fucntion/operation automaticlly gets added into the noe/GUAC graph on execution (triggering eventing via SBOM of query).

schema/alice/shouldi/contribute/github-com-omnilib-aiosqlite.json

{
    "@context": "https://github.com/intel/dffml/raw/alice/schema/schema/alice/shouldi/contribute/0.0.0.schema.json",
    "repo_url": "https://github.com/omnilib/aiosqlite"
}
  • As container build

schema/image/container/build/alice-shouldi-contribute-results-github-com-omnilib-aiosqlite.json

{
    "@context": "https://github.com/intel/dffml/raw/alice/schema/github/actions/build/images/containers/0.0.0.schema.json",
    "include": [
        {
            "branch": "alice",
            "build_args": "[[\"REPO_URL\", \"https://github.com/omnilib/aiosqlite\"]]",
            "commit": "ca92bfae5092bce908b70f6b5e0afbe242ce7a5b",
            "dockerfile": "entities/alice/scripts/alice-shouldi-contribute-results.Dockerfile",
            "image_name": "alice-shouldi-contribute-results-github-com-omnilib-aiosqlite",
            "owner": "intel",
            "repository": "dffml"
        }
    ]
}
  • Open Source scanning flow
    • https://github.com/ossf/s2c2f/blob/main/specification/framework.md#appendix-relation-to-scitt
    • Upload manifest to registry
      • Federation event (send to follower /inbox)
        • content: https://github.com/opencontainers/image-spec/raw/v1.0.1/schema/image-manifest-schema.json inReplyTo: activitypub extensions for security.txt post URL for content activitypubsecuritytxt
        • content: container image uri uploaded inReplyTo: activitypub extensions for security.txt post URL for content https://github.com/opencontainers/image-spec/raw/v1.0.1/schema/image-manifest-schema.json
    • Downstream listener (aka delve into config dict)
      • Federation event (send to follower /inbox)
        • content: https://github.com/intel/dffml/raw/alice/schema/github/actions/build/images/containers/0.0.0.schema.json inReplyTo: activitypub extensions for security.txt post URL for content activitypubsecuritytxt
        • content: <extracted content(?)> inReplyTo: activitypub extensions for security.txt post URL for content https://github.com/intel/dffml/raw/alice/schema/github/actions/build/images/containers/0.0.0.schema.json
    • Downstream listener
      • Republish watched inReplyTo schema into job/message queue
        • RabbitMQ
      • Message queue delivers to worker nodes
        • Kaniko job waiting for celery queue for image to build
          • Exit after rebuild and have orchestration manage respawn
graph LR

  subgraph vcs_source[Version Controled Software]
    subgraph dffml_vcs_source[dffml.git]
      subgraph dffml_vcs_source_security_txt[security.txt]
        dffml_vcs_source_security_txt_contact[Contact: https://example.org/dffml]
      end
      subgraph dffml_vcs_source_dockerfile[dffml.Dockerfile]
        dffml_vcs_source_dockerfile_from_base[FROM upstream as dffml]
      end
      subgraph dffml_vcs_source_dockerfile_example[dffml.example.Dockerfile]
        dffml_vcs_source_dockerfile_example_from_base[FROM dffml &#x0040 sha:latest]
      end
      subgraph vcs_source_alice[dffml.git/entities/alice]
        subgraph alice_vcs_source_security_txt[security.txt]
          alice_vcs_source_security_txt_contact[Contact: https://example.org/alice]
        end
        subgraph alice_vcs_source_dockerfile[alice.Dockerfile]
          alice_vcs_source_dockerfile_from_base[FROM dffml &#x0040 sha:latest]
        end
        subgraph alice_vcs_source_dockerfile_shouldi_contribute[alice_shouldi_contribute.Dockerfile]
          alice_vcs_source_dockerfile_shouldi_contribute_from_base[FROM alice &#x0040 sha:latest]
          subgraph alice_shouldi_contribute[alice shoulid contribute -keys ARG_REPO_URL]
            alice_shouldi_contribute_git_clone[git clone ...]
            alice_shouldi_contribute_read_security_txt[grep Contact: security.txt]
            alice_shouldi_contribute_result[Static Analysis Result]

            alice_shouldi_contribute_git_clone --> alice_shouldi_contribute_read_security_txt
            dffml_vcs_source_security_txt_contact --> alice_shouldi_contribute_read_security_txt
            alice_shouldi_contribute_read_security_txt --> alice_shouldi_contribute_result
          end
        end
      end
    end
  end
  
  subgraph schema[Manifest ADRs]
    subgraph manifest_build_images_contianers[Build Image Container]
      manifest_build_images_contianers_intent[README.md/THREATS.md]
      manifest_build_images_contianers_schema[1.0.0.schema.json]
    end
  end

  subgraph manifest_instances[Manifest Instances]
    alice_manifest_build_images_contianers_alice_shouldi_contribute
  end

  subgraph transparency_logs[Transparency Logs]
    dffml_scitt[dffml.scitt.example.org]
    alice_scitt[alice.scitt.example.org]
  end

  subgraph factory[Secure Software Factories aka Federated Forge]
    subgraph build_images_contianers[build_images_contianers.yml]
    end

    subgraph factory_container_image_registries[Container Image Registry https://oras.land]
      subgraph dffml_factory_container_image_registries_project[DFFML Images]
        dffml_container_image[dffml:latest]
      end
      subgraph alice_factory_container_image_registries_project[Alice Images]
        alice_container_image[alice:latest]
        alice_shouldi_contribute_scan_results[shouldicontribute &#x0040 sha384:babebabe]
      end
    end

    build_images_contianers --> dffml_scitt
    build_images_contianers --> alice_scitt
  end

  subgraph protocol_knowledge_graph_activity_pub[ActivityPub]
    subgraph ActivityPubExtensionsForSecurityTXT[activitypub extensions for security.txt]
      subgraph dffml_security_txt_contact[dffml.git/security.txt:Contact]
        dffml_actor[ActivityPub Actor - &#x0040 dffml &#x0040 example.org]
        dffml_actor_attachment[Attachment PropertyValue activitypubsecuritytxt]
        dffml_activitypubsecuritytxt_root_post[activitypubsecuritytxt root post]
        dffml_activitypubsecuritytxt_vcs_push[vcs.push root post]
        dffml_activitypubsecuritytxt_vcs_push_content[vcs.push content - content address of manifest instance in registry]

        dffml_actor --> dffml_dffml_actor_attachment
        dffml_actor_attachment -->|Link| dffml_activitypubsecuritytxt_root_post
        dffml_activitypubsecuritytxt_vcs_push -->|inReplyTo| dffml_activitypubsecuritytxt_root_post
        dffml_activitypubsecuritytxt_vcs_push_content -->|inReplyTo| dffml_activitypubsecuritytxt_vcs_push
      end

      subgraph alice_security_txt_contact[dffml.git/entites/alice/security.txt:Contact]
        alice_actor[ActivityPub Actor - &#x0040 alice &#x0040 example.org]
        alice_actor_attachment[Attachment PropertyValue activitypubsecuritytxt]
        alice_activitypubsecuritytxt_root_post[activitypubsecuritytxt root post]
        alice_activitypubsecuritytxt_vcs_push[vcs.push root post]
        alice_activitypubsecuritytxt_vcs_push_content[vcs.push content - content address of manifest instance in registry]

        alice_actor --> alice_actor_attachment
        alice_actor_attachment -->|Link| alice_activitypubsecuritytxt_root_post
        alice_activitypubsecuritytxt_vcs_push -->|inReplyTo| alice_activitypubsecuritytxt_root_post
        alice_activitypubsecuritytxt_vcs_push_content -->|inReplyTo| alice_activitypubsecuritytxt_vcs_push
      end
    end

    alice_actor -->|follow| dffml_actor
  end

  subgraph render_knowledge_graph_agora[Agora]
  end

  alice_vcs_source_dockerfile_shouldi_contribute

  dffml_vcs_source_security_txt_contact --> dffml_actor
  alice_vcs_source_security_txt_contact --> alice_actor

  alice_shouldi_contribute_result --> alice_shouldi_contribute_scan_results
  alice_shouldi_contribute_scan_results --> |inReplyTo| dffml_vcs_source_dockerfile_example_from_base

  dffml_container_image --> dffml_vcs_source_dockerfile_example_from_base
  alice_container_image --> alice_vcs_source_dockerfile_example_from_base

  dffml_vcs_source_dockerfile_example_from_base --> dffml_activitypubsecuritytxt_vcs_push
  dffml_activitypubsecuritytxt_vcs_push --> build_images_contianers_trigger
  alice_vcs_source_dockerfile_example_from_base --> alice_activitypubsecuritytxt_vcs_push

  alice_shouldi_contribute
Loading 
{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://w3id.org/security/v1",
    ],
    "id": "https://mastodon.social/users/alice",
    "type": "Person",
    "following": "https://mastodon.social/users/alice/following",
    "followers": "https://mastodon.social/users/alice/followers",
    "inbox": "https://mastodon.social/users/alice/inbox",
    "outbox": "https://mastodon.social/users/alice/outbox",
    "featured": "https://mastodon.social/users/alice/collections/featured",
    "featuredTags": "https://mastodon.social/users/alice/collections/tags",
    "preferredUsername": "alice",
    "name": "Alice",
    "summary": "An ActivityPub Actor",
    "url": "https://mastodon.social/@alice",
    "publicKey": {
        "id": "https://mastodon.social/users/alice#main-key",
        "owner": "https://mastodon.social/users/alice",
        "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgk\n-----END PUBLIC KEY-----\n"
    },
    "attachment": [
        {
            "type": "PropertyValue",
            "name": "activitypubextensions",
            "value": "<a href=\"https://mastodon.social/users/alice/statuses/1\" target=\"_blank\" rel=\"nofollow noopener noreferrer me\"><span class=\"invisible\">https://</span><span class=\"\">mastodon.social/users/alice/statuses/1</span><span class=\"invisible\"></span></a>"
        }
    ],
    "endpoints": {
        "sharedInbox": "https://mastodon.social/inbox"
    }
}
{
    "@context": [
        "https://www.w3.org/ns/activitystreams"
    ],
    "id": "https://mastodon.social/users/alice/statuses/1",
    "type": "Note",
    "summary": null,
    "inReplyTo": null,
    "published": "2022-11-11T04:40:17Z",
    "url": "https://mastodon.social/@alice/1",
    "attributedTo": "https://mastodon.social/users/alice",
    "to": [
        "https://www.w3.org/ns/activitystreams#Public"
    ],
    "cc": [
        "https://mastodon.social/users/alice/followers"
    ],
    "sensitive": false,
    "content": "activitypubextensions",
    "updated": "2022-11-11T04:42:27Z",
    "attachment": [],
    "replies": {
        "id": "https://mastodon.social/users/alice/statuses/1/replies",
        "type": "Collection",
        "first": {
            "type": "CollectionPage",
            "next": "https://mastodon.social/users/alice/statuses/1/replies?min_id=1&page=true",
            "partOf": "https://mastodon.social/users/alice/statuses/1/replies",
            "items": [
                "https://mastodon.social/users/alice/statuses/2"
            ]
        }
    }
}
{
    "@context": [
        "https://www.w3.org/ns/activitystreams"
    ],
    "id": "https://mastodon.social/users/alice/statuses/2",
    "type": "Note",
    "summary": null,
    "inReplyTo": "https://mastodon.social/users/alice/statuses/1",
    "published": "2022-11-11T04:40:17Z",
    "url": "https://mastodon.social/@alice/2",
    "attributedTo": "https://mastodon.social/users/alice",
    "to": [
        "https://www.w3.org/ns/activitystreams#Public"
    ],
    "cc": [
        "https://mastodon.social/users/alice/followers"
    ],
    "sensitive": false,
    "content": "activitypubsecuritytxt",
    "updated": "2022-11-11T04:42:27Z",
    "attachment": [],
    "replies": {
        "id": "https://mastodon.social/users/alice/statuses/2/replies",
        "type": "Collection",
        "first": {
            "type": "CollectionPage",
            "next": "https://mastodon.social/users/alice/statuses/2/replies?min_id=2&page=true",
            "partOf": "https://mastodon.social/users/alice/statuses/2/replies",
            "items": [
                "https://mastodon.social/users/alice/statuses/3"
            ]
        }
    }
}
{
    "@context": [
        "https://www.w3.org/ns/activitystreams"
    ],
    "id": "https://mastodon.social/users/alice/statuses/3",
    "type": "Note",
    "summary": null,
    "inReplyTo": "https://mastodon.social/users/alice/statuses/2",
    "published": "2022-11-11T04:40:17Z",
    "url": "https://mastodon.social/@alice/3",
    "attributedTo": "https://mastodon.social/users/alice",
    "to": [
        "https://www.w3.org/ns/activitystreams#Public"
    ],
    "cc": [
        "https://mastodon.social/users/alice/followers"
    ],
    "sensitive": false,
    "content": "https://github.com/opencontainers/image-spec/raw/v1.0.1/schema/image-manifest-schema.json",
    "updated": "2022-11-11T04:42:27Z",
    "attachment": [],
    "replies": {
        "id": "https://mastodon.social/users/alice/statuses/3/replies",
        "type": "Collection",
        "first": {
            "type": "CollectionPage",
            "next": "https://mastodon.social/users/alice/statuses/3/replies?min_id=3&page=true",
            "partOf": "https://mastodon.social/users/alice/statuses/3/replies",
            "items": [
                "https://mastodon.social/users/alice/statuses/4"
            ]
        }
    }
}
{
    "@context": [
        "https://www.w3.org/ns/activitystreams"
    ],
    "id": "https://mastodon.social/users/alice/statuses/4",
    "type": "Note",
    "summary": null,
    "inReplyTo": "https://mastodon.social/users/alice/statuses/3",
    "published": "2022-11-11T04:54:56Z",
    "url": "https://mastodon.social/@alice/4",
    "attributedTo": "https://mastodon.social/users/alice",
    "to": [
        "https://www.w3.org/ns/activitystreams#Public"
    ],
    "cc": [
        "https://mastodon.social/users/alice/followers"
    ],
    "sensitive": false,
    "content": "registry.example.org/vex:sha256@babebabe",
    "attachment": [],
    "tag": [],
    "replies": {
        "id": "https://mastodon.social/users/alice/statuses/4/replies",
        "type": "Collection",
        "first": {
            "type": "CollectionPage",
            "next": "https://mastodon.social/users/alice/statuses/4/replies?only_other_accounts=true&page=true",
            "partOf": "https://mastodon.social/users/alice/statuses/4/replies",
            "items": []
        }
    }
}
{
  "@context": "https://openvex.dev/ns",
  "@id": "https://mastodon.social/users/alice/statuses/vex-sha256@feedface",
  "author": "GitHub Actions <[email protected]>",
  "role": "GitHub Actions",
  "timestamp": "2023-02-02T14:24:00.000000000-07:00",
  "version": "1",
  "statements": [
    {
      "vulnerability": "vex-vcspush-sha256@feedface",
      "products": [
        "pkg:github/intel/dffml@ddb32a4e65b0d79c7561ce2bdde16d963c8abde1"
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
      "impact_statement": "registry.example.org/vcspush:sha256@feedface",
    }
  ]
}
$ curl -sfL https://vcs.example.org/push/outbox | jq --unbuffered -r '.orderedItems[].object.content' | grep stream_of | grep modified | jq -r --unbuffered '.commits[].modified[]'
Dockerfile

Why?

Decentralized

Actors can be spun up ad-hoc, mirrors decentralized nature of OSS development.

Enables projects to update based on policy.

sequenceDiagram
    SupportLevelOneSecondPartyPluginPullRequest->>+Webhook: 
    Webhook->>+ActivityPub: 
    ActivityPub->>+SupportLevelOneSecondPartyWatcher: 
    RequiredCIJobPassDownstreamSupportLevelOneSecondPartyPlugin->>+Webhook: 
    Webhook->>+ActivityPub: 
    SupportLevelOneSecondPartyPlugin->>+Webhook: 
    DFFML->>+Webhook: 
    Webhook->>+ActivityPub: 
    SupportLevelOneSecondPartyPluginPullRequest->>+Webhook: 
    Webhook->>+ActivityPub: 
    ActivityPub->>+DFFMLTutorialPullRequestBumpPin: 
    ExampleDockerFileWithPinnedVersion->>+ContainerBuild: 
    ContainerBuild->>+ExampleDockerFileWithPinnedVersion: 
    ExampleDockerFileWithPinnedVersion->>+Webhook: 
    ActivityPub->>+DFFMLTutorialPullRequestBumpPin: 
    DFFMLTutorialPullRequestBumpPin->>+Webhook:
Loading

Upstream of following mermaid: https://github.com/intel/dffml/tree/alice/docs/tutorials/rolling_alice/0000_architecting_alice#what-is-alice

graph BT
    subgraph Alice[Alice the Entity]
        subgraph compute[Compute]
        Web5[Web 5]
        KCP
        CI_CD[CI/CD]
        end
        subgraph soul[Strategic Plans and Principles]
        Threat_Modeling[Threat Modeling]
        Debug
        end
        subgraph collector[Collector]
        subgraph dynamic_analysis[Dynamic Analysis]
            policy[policy.yml]
            sandbox_policy_generator[Adaptive Sandboxing]
        end
        subgraph static_analysis[Static Analysis]
            cve_bin_tool[CVE Binary Tool]
            SBOM
        end
        end
        Open_Architecture
        Open_Architecture[Alice the Open Architecture]
        snapshot_system_context[Alice the Overlay<br>Snapshot of System Context]
        orchestartor[Orchestartor]


        Open_Architecture --> Threat_Modeling
        Open_Architecture --> Debug

        Threat_Modeling --> orchestartor
        Debug --> orchestartor

        orchestartor --> KCP
        orchestartor --> Web5
        orchestartor --> CI_CD

        CI_CD --> snapshot_system_context
        KCP --> snapshot_system_context
        Web5 --> snapshot_system_context

        snapshot_system_context --> sandbox_policy_generator
        snapshot_system_context --> cve_bin_tool

        sandbox_policy_generator --> policy --> Open_Architecture
        cve_bin_tool --> SBOM --> Open_Architecture
        cve_bin_tool --> VEX -->|Trigger validation run of mitigation suggestion| orchestartor
        policy -->|Check if policy says out of scope<br>client vs. server usage| VEX
    end
Loading

Side from Andrew Ng's Intel Innovation 2022 Luminary Keynote Source: https://www.intel.com/content/www/us/en/newsroom/news/2022-intel-innovation-day-2-livestream-replay.html#gs.iex8mr image

  • Possible alignment with Andrew's "Data-Centric AI"
  • is the discipline of systematically engineering the data used to build an AI system
    • This is what we're doing with Alice
  • Possible alignment with Andrew's "The iterative process of ML development"
    • https://github.com/intel/dffml/tree/alice/docs/tutorials/rolling_alice/0000_architecting_alice#entity-analysis-trinity
    • Intent / Train model
      • Establish correlations between threat model intent and collected data / errors (telemetry or static analysis, policy, failures)
    • Dynamic analysis / Improve data
      • We tweak the code to make it do different things to see different data. The application of overlays. Think over time.
    • Static / Error analysis
      • There might be async debug initiated here but this maps pretty nicely conceptually since we'd think of this as a static process, we already have some errors to analyze if we're at this step.

Gif of Alice on roller skates throwing a bowling ball which is a software vuln, strike, she frontflips throwing knife style throws the pins into pull requests. We zoom out and see her just doing this over and over again around the Entity Analysis Trinity. Intent/LTM is where the throwing board is. Bowling alley is static analysis and the end of the bowling ally where she frontflips over (through hoop of CI/CD fire?) is where she pics up the pins and throws them as pull request (titles and numbers maybe, pulls/1401 style maybe?) knives into the board at the top which is the LTM and codebase. Then from top, LTM to static analysis where bowling alley starts shes in the lab, cooking up the vuln or maybe out looking for it. Or maybe refactoring after pull requests!

Entity Analysis Trinity

Misc. Notes

Mike from OpenSSF 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 impelmenetation details.

  • TODO
    • Going with Authenticated Chained Data Containers and KERI Watchers as an implmentation of SCITT for this
      • It's basically a decentralized pubsub event notification methodology that can be done over ACDC piggybacking on ActivityPub as layer 7.
      • Event data lives "off chain" in a container registry secured via existing transparency service based methods (KERI, SCITT, SigStore), where the chain is the network of keys involved for a train of thoughts comms between entities. Since we transmit ActivityPub over KERI, the graph of our supply chain data we are sharing can be shared with trusted actors who agree not to be duplicitous, and who's KERI keys can be tied back to TEEs so that we can confirm they are running software that doesn't intend (via ML-based, Alice, analysis) to be duplicitous. We can now have our trusted computing based for decentralized compute, aka CI/CD pipelines delivering across project trust boundries.
    • Go over .github/workflows/alice_shouldi_contribute.yml which is called as reusable workflow using SLSA demos as conceptual upstream.
      • This gives us metric collection with overlays applied to input network which log data provenance later used via policy referenced in a Living Threat Model of a downstream end user facing application. The use case document will cover how we effectivly self notarize the data provenance assisted by the OIDC token issused to the workflow from GitHub.
    • Align with Software Supply Chain Artifact Examples use case
    • As CI/CD velocity increases, we approach a similar threat model to distributed compute, address here.
    • As consumer, how can I discover that fact and trust that it's accruate
    • Could imagine a world where things like Scorecard express the data as as SCITT attestation
    • You go and query that (source code data mining data or vuln data) store (via DID resolution) and you say tell me everythig you know about foo and you get it all back.
      • Addresses OpenSSF/Christine's: Looking at trying to connect all the different data sources
    • Until we have an implementation with Web5 (https://github.com/TBD54566975) that's at at least beta, we could expore what that looks like.
    • Open Architecture: 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).
  • References
  • We first issue the verifiable credentials, with a reference to the rest of the hashlinks (or whatever the CBOR style thing is)
    • Open Source Decentralized Identifiers and Verifiable Credentials Infrastructure and Tooling - verifiable-data/Hashlink.ts at c80cab9abe4db478add16b14837ba9a3afc3a70f
    • Then we hashlink that, and that's the top level ref. effectivly the evolution of the zephyr.stripped shasum patchset
    • zephyrproject-rtos/zephyr#51954
  • Future
    • As a follow on to the OpenSSF Metrics use case document and Living Threat Models are better than Dead Threat Models Rolling Alice: Volume 1: Coach Alice: Chapter 1: Down the Dependency Rabbit-Hole Again will cover how we identify and query provenance on dependencies where caching on data flow execution is assisted via quering public SCITT infrastructure and sourcing cached state from trustworthy parties.
    • Leveraging our restoration of cached state from trustworthy parties and LTM policy we can measure alignment of ML model's used within BOM components so as to report conceptual alignment with entity strategic plans / principles.
      • We care about data provenance. 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 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 might say
        • "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 orchestrator trust boundary.
    • https://time.crystals.prophecy.chadig.com
      • https://twitter.com/OR13b/status/1621907110572310528
        • Actor acquire
          • attachments Link to activitypubextensions thread
          • content: "activitypubextensions" thread
            • inReplyTo: "$activitypubextensions_thread", content: "https://time.crystals.prophecy.chadig.com/bulk.1.0.0.schema.json" thread
              • This becomes analogous to shared stream of consciousness uniform API for submitting across contexts (Manifests).
                • CI/CD across projects with different orchestrators for downstream validation of the 2nd and 3rd party plugin ecosystem.
                  • This facilitates communication across pipelines across repos across PRs so we can use versioned learning to promote across trust boundaries (3rd party to 2nd party or support level 2 to 1)
                  • #1207
                  • #1315
                  • Alice helps us see risk over time, this is where we see Coach Alice, cartography used applied to dev branches, we grow closer to distributed compute with this, as iteration time is on dev branches rather than release or main
                    • This will probably be part of Alice and the Health of the Ecosystem
        • Ask him to reply to @[email protected]
      • ActivityPub Actor watches for messages replying to certain threads
      • Actor creates pull request to https://github.com/OR13/endor style repo
        • Actor creates didme.me and gets VC SCITT receipt for associated did:pwk: (committed into Endor fork, he'd used git as database)
          • This could also be our content address of something in oras.land
          • In the AI training data/human case we see the input data (meme) validated via SCITT
            • We want to enable application of policy to data set ingestion, because this will happen in MLOps aka CI/CD
            • Workstream: AI Ethics
          • In the CI/CD use case, we see the input data (manifest referenced content, images, packages, metrics data output FROM scratch OpenSSF metrics use case) validated via SCITT.
          • Later we build up the threat modeling for the dynamic analysis portion of Alice which plays with input data as changes to repos and connects more of our Data, Analysis, Control for the software development process.
        • Actor replies to Orie's reply with his receipt for his time crystals.
      • For k8s style or OS DecentAlice style deployments (OSS scanning feeding OpenSSF metrics) we could run the graphed trust / event chain to a sidecar ActivityPub Actor / root of trust.
  • RCFv1 Feedback
    • https://mailarchive.ietf.org/arch/msg/scitt/dowMkmWhbi9Pkq6B5DhdXzip0so/

    • Maik: I'm curious to understand this more in detail. I think so far we've been thinking about the term federation as accepting SCITT claims/receipts from one transparency service in another transparency service, based on some policy. I think what you're describing is more about subscriptions/broadcasting/... Can you describe a little more on how you see this working in a SCITT transparency service? It might be that this is something that sits outside of it, but I'm not fully sure yet, so I wanted to understand it better first.

    • Sketch response notes
      • Policy as code, but sometimes it needs to execute because it's context aware, it's trying to decide for each piece of data that's pubsub'd for federation, does this SCITT instance want to be serving that trust assertion
      • Open Policy Agent
      • JSONLD
      • Cypher
      • Verfiable Credentials

      • SCITT claims/receipts from one transparency service in another transparency service, based on some policy

        • Policy as compute contract, exec result determines entry of broadcast/subscribed syned SCITT instances (OSS projects, 2nd party, walled gardens)
          • Can use this methodlolgy to broadcast those policies to topics via inReplyTo or later maybe service endpoint (as relay compute contact via did:oa)
          • TDX self attest/DICE style layering where we wrap the receipt with the proposed insersion policy
            • https://github.com/TrustedComputingGroup/DICE
            • Something about the decentralized compute and the compute contract sandboxing to enable distributed trust propagation
              • The AI travel in sandboxes. This is how trust (Alice) surfs the hypergraph. 🏄‍♀️ It's like ePBF but IPVM but as k8s admission controller but on scitt /inbox
                • What's the sandbox? The policy here, what's the policy? The compute contract defining what the schema?+OPA?+cypher and what are the content addresses of the upstream contracts needed to fulfill the query
                • On of the goals with the SCITT federation via ActivityPub is that it's a step towards the event stream being all JSONLD. Then audit and policy are effectively all done with definitions within DID referenced Verifiable Credentials. These encapsulate a receipt for a claim which who's insertion policy is a (or a context address of) policy as code aka compute contract. That contract statically defines or fulfils fetching or generating whatever data is needed to validate for insertion or federation and executes within a sandboxed environment. These policies can be overlayed with instance local additional policy as code. We can then read this event stream from anywhere or graft new trust chains off of it. GAUC is awesome it's just centralized from what I can tell, which is perfect for a performant view into a decentralized ecosystem. I think the two will work great together. We're all thinking in the same directions from what I can tell, just different goals in terms of data sovereignty, GUAC-GPT on the centralized side, Alice on the decentralized side.. The reason for the heavy focus on decentralization is that it for CI/CD we need to be able to spin dev and test chains of trust ad-hoc, for the AI side, we need to spin them for offline use cases tied to the users root of trust, or viewed as the user + their hardware roots of trust. Decentralized primitives allow us to never be forced to trust any authority other than what the deployment use case needs, scoping privilege to the threat model.
            • Something about it being recursive
              • If your log inserted it and you want to federate that insertion to my log I want to know why you thought this was valid to insert. Tell me the scientific evidence Alice. What's the analysis report, why should that entry also get admission into my log. It's dynamic evaluation, so I can say based on my overlays okay I will take that receipt in my log based on that scientific method/process but due to this isntamces special overlays I won't take this other one. Maybe this is a recursion into the concept of a notary but required "self" notary required for that instances overlays applied to incoming receipt scientific processes / ipvm / data flow / open architecture.
            • Decentralized trust propagation
              • why should this be in your internal CA set sort of thing, what's your roots of trust and how to we justify adds / removes / modifications and notify that we think it's in your best interest for you to also trust the propagation of this trust assertion
            • Decentralized dependency review - hence Open SSF Metrics use case
      • https://mailarchive.ietf.org/arch/msg/scitt/5SDINK63mr1BWX-BzbcsvalVLOA/

        • As part of this service offering example.com only allows artifacts to be added to the ledger by government customers who paid for the service. Example.com also requires a certain level of identity proofing and multi-factor authentication because it offers sensitive services to their government customers. Auditors require an even high level of identity proofing and authentication.

          This policy of example.com is dictated by their business model and is outside the scope of what the IETF SCITT will define.

      • https://mailarchive.ietf.org/arch/msg/scitt/cgz-9oif4SLMbdLyPn0P6-E8cIY/

        • This is interesting - many thanks Hannes. I notice our spec includes Merkle trees as the database structure - seems like an implementation detail, i.e. just a database. Can an implementer use, for example, an otherwise secured and RBAC'd record structure such as a file system or relational/hierarchical/sharded db, or is distributed ledger mandatory?

        • df: overlay: Implement middleware/RBAC chains of ordered applications of overlays #1400
      • There exist N instances of SCITT, which ones are tied to the current executing system context? Those determine reality, aka what is real, what to trust, for that system context
        • Hallucinating large language models train/chain of thought is tied to context local SCITT. We graft in (accept new federated claims/receipts) from other system contexts we trust. We trust based on if we should propagate from that context to this context. Equilibrium as reality. Context local reality for the net. If they are isolated, they define their own reality.
        • The truth will set you free. Equilibrium of record propagation.
        • Everything is true, everything is permitted (insert policy*)
          • Most of the time what's permitted is context dependent, overlays
          • Time is context local, Earth is current most likely context, we have to ensure we factor in changes to this via abstraction of "when", ref lunar comms (LCRNS), beyond
            • Vol 6: Where are your NTP gods now?
          • https://esc.gsfc.nasa.gov/projects/LCRNS
          • https://bigthink.com/hard-science/time-perception/

            • The idea of 'absolute time' is an illusion. Physics and subjective experience reveal why.

          • Physics, also context local, gravity differs on different parts of Earth, and elsewhere. Make no assumptions, always policy as code, always recursive. Always show my why I should believe this message, message as the entity, not the messanger (instance federating from), focus on the truth in the message when propagating, not who propagates, critical thinking, threat modeling, deployment contexts
  • Fork and exec over ActivityPub over DWN CLI

Post RFCv3

SLSA (in-toto style)

Upstream for S2C2F sections: https://github.com/ossf/s2c2f/blob/98803e0a558e6d8cef4d2770864ffd3cf7618c65/specification/framework.md#appendix-relation-to-scitt

S2C2F: Appendix: Relation to SCITT

The Supply Chain Integrity, Transparency, and Trust initiative, or SCITT, is a set of proposed industry standards for managing the compliance of goods and services across end-to-end supply chains. In the future, we expect teams to output "attestations of conformance" to the S2C2F requirements and store it in SCITT. The format of such attestations is to be determined.

S2C2F: Appendix: Mapping Secure Supply Chain Consumption Framework Requirements to Other Specifications

Goal: Create YAML file allowing users to map webhook event data to creation of data notarized by SCITT, statments and receipts created. Use YAML as basis for overall automatable format for alignment to S2C2F.

Requirement ID Requirement Title References
ING-1 Use package managers trusted by your organization CIS SSC SG : 3.1.5
OWASP SCVS: 1.2
CNCF SSC: Define and prioritize trusted package managers and repositories
ING-2 Use an OSS binary repository manager solution OWASP SCVS: 4.1
CNCF SSC: Define and prioritize trusted package managers and repositories
ING-3 Have a Deny List capability to block known malicious OSS from being consumed
ING-4 Mirror a copy of all OSS source code to an internal location CNCF SSC: Build libraries based upon source code
SCA-1 Scan OSS for known vulnerabilities SP800218 : RV.1.1
SP800161 : SA-10, SR-3, SR-4
CIS SSC SG : 1.5.5, 3.2.2
OWASP SCVS: 5.4
CNCF SSC: Verify third party artefacts and open source libraries, Scan software for vulnerabilities, Run software composition analysis on ingested software
SCA-2 Scan OSS for licenses CIS SSC SG : 1.5.6, 3.2.3
OWASP SCVS: 5.12
CNCF SSC: Scan software for license implications
SCA-3 Scan OSS to determine if its end-of-life SP800218 : PW.4.1
SP800161 : SA-4, SA-5, SA-8(3), SA-10(6), SR-3, SR-4
OWASP SCVS: 5.8
SCA-4 Scan OSS for malware clamav workflow or job
SCA-5 Perform proactive security review of OSS SP800218 : PW.4.4
SP800161 : SA-4, SA-8, SA-9, SA-9(3), SR-3, SR-4, SR-4(3), SR-4(4)
OWASP SCVS: 5.2, 5.3,
INV-1 Maintain an automated inventory of all OSS used in development OWASP SCVS: 1.1, 1.3, 1.8, 5.11
CNCF SSC: Track dependencies between open source components
INV-2 Have an OSS Incident Response Plan SP800218 : RV.2.2
SP800161 : SA-5, SA-8, SA-10, SA-11, SA-15(7)
UPD-1 Update vulnerable OSS manually
UPD-2 Enable automated OSS updates
UPD-3 Display OSS vulnerabilities as comments in Pull Requests (PRs)
AUD-1 Verify the provenance of your OSS CIS SSC SG : 3.2.4
OWASP SCVS: 1.10, 6.1
SLSA v1.0: Producing artifacts – Distribute provenance
AUD-2 Audit that developers are consuming OSS through the approved ingestion method CIS SSC SG : 4.3.3
AUD-3 Validate integrity of the OSS that you consume into your build CIS SSC SG : 2.4.3
OWASP SCVS: 4.12
CNCF SSC: Verify third party artefacts and open source libraries
AUD-4 Validate SBOMs of OSS that you consume into your build CNCF SSC: Require SBOM from third party supplier
ENF-1 Securely configure your package source files (i.e. nuget.config, .npmrc, pip.conf, pom.xml, etc.) SP800218 : PO.5.2
CIS SSC SG : 2.4.2, 3.1.7, 4.3.4, 4.4.2
ENF-2 Enforce usage of a curated OSS feed that enhances the trust of your OSS SP800218 : PO.5.2
CIS SSC SG : 2.4.3, 3.1.1, 3.1.3
REB-1 Rebuild the OSS in a trusted build environment, or validate that it is reproducibly built CIS SSC SG : 2.4.4
REB-2 Digitally sign the OSS you rebuild SP800218 : PS.2.1
REB-3 Generate SBOMs for OSS that you rebuild SP800218 : PS.3.2
SP800161 : SA-8, SR-3, SR-4
CIS SSC SG : 2.4.5
OWASP SCVS: 1.4, 1.7
CNCF SSC: Generate an immutable SBOM of the code
REB-4 Digitally sign the SBOMs you produce CIS SSC SG : 2.4.6
FIX-1 Implement a change in the code to address a zero-day vulnerability, rebuild, deploy to your organization, and confidentially contribute the fix to the upstream maintainer

Webhook endpoint

Targets are new commits, branches, tags, and their CI/CD (status check) results

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "<NAME>",
      "digest": {"<ALGORITHM>": "<HEX_VALUE>"}
    },
    ...
  ],
  "predicateType": "https://in-toto.io/attestation/test-result/v0.1",
  "predicate": {
      "result": "PASSED|WARNED|FAILED",
      "configuration": ["<ResourceDescriptor>", ...],
      "url": "<URL>",
      "passedTests": ["<TEST_NAME>", ...],
      "warnedTests": ["<TEST_NAME>", ...],
      "failedTests": ["<TEST_NAME>", ...]
  }
}
{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "<NAME>",
      "digest": {"<ALGORITHM>": "<HEX_VALUE>"}
    },
    ...
  ],
  "predicateType": "https://spdx.dev/Document/v2.3",
  "predicate": {
    "SPDXID" : "SPDXRef-DOCUMENT",
    "spdxVersion" : "SPDX-2.3",
    ...
  }
}