data: map publications to personas, problems, and project relationships

data/definitions/publications.yml

@@ -15,6 +15,11 @@
 # WHO PRODUCES/CONSUMES WHAT IS NOT AUTHORED HERE. A project declares its own
 # `produces:` / `consumes:` edges in its `relationships:` list, pointing at a
 # publication id. The publication pages reverse-derive from that.
+#
+# Persona / problem mappings ARE authored here, same shape as on a project.
+# Since these specs have no OpenSSF maintainer to confirm them, the mappings
+# are curator judgments about how each role uses the format — corrections
+# welcome by PR.
 
 - id: in-toto-attestation
   name: in-toto Attestation
@@ -24,21 +29,44 @@
     in. Defines the predicate/statement structure and signature wrapper used by every conforming
     attestation.
   kind: publication
+  personas:
+  - id: security
+    note: >-
+      Verifies attestation signatures and predicates to confirm supply-chain steps ran as
+      claimed before trusting an artifact.
+  - id: devops
+    note: >-
+      Configures build and pipeline steps to emit signed in-toto attestations so each step's
+      actions are independently verifiable.
+  - id: package-manager
+    note: >-
+      Verifies incoming attestations at publish time and surfaces their provenance claims
+      to package consumers.
+  problems:
+  - id: build-provenance
+    note: >-
+      The signed envelope that carries build and supply-chain evidence from producer to verifier.
+  - id: artifact-signing
+    note: >-
+      Wraps supply-chain statements in a signature layer so tampering with the claim invalidates
+      it.
 # UNRESOLVED — is OSV one publication or two?
 #
-# This record and the `osv-openvex` record in
-# data/working-groups/vulnerability-disclosures.yml (also `kind: publication`
-# since the 2026 consolidation) share the same url
-# (https://ossf.github.io/osv-schema/), joined by the `osv-record extends
-# osv-openvex` edge below.
+# This record and the `osv-schema` record in
+# data/working-groups/vulnerability-disclosures.yml (also `kind: publication`)
+# share the same url (https://ossf.github.io/osv-schema/).
 #
 # The pair looks like it was imported without anyone deciding what OSV is here.
-# Now that both are publications, the likely resolution is merging them into
-# one record (or giving them distinct urls and a real distinction). Left as-is
+# Both being publications, the likely resolution is merging them into one
+# record (or giving them distinct urls and a real distinction). Left as-is
 # deliberately — this is a question for the OSV folks, not a cleanup.
 #
+# The `extends` edge below pointed at `osv-openvex` until that record was split
+# into `openvex` and `osv-schema`; it is authored against `osv-schema` here and
+# left needs-review until OSV maintainers confirm the target.
+#
 # The `description` below is also truncated mid-sentence; it arrived that way and
-# renders that way on /artifacts/osv-record/. Rewrite it when the above is settled.
+# renders that way on /publications/osv-record/. Rewrite it when the above is settled.
 - id: osv-record
   name: OSV Record (vulnerability record format)
   aliases: [OSV Record]
@@ -50,11 +78,34 @@
   kind: publication
   relationships:
   - kind: extends
-    target: osv-openvex
-    status: confirmed
+    target: osv-schema
+    status: needs-review
     note: >-
       The artifact (the record format itself) is the concrete instance of what the OSV Schema
-      project specifies.
+      project specifies. Authored against `osv-schema`, which replaced `osv-openvex` in the
+      split; OSV maintainers, please confirm the target — or tell us these are one record.
+  personas:
+  - id: developer
+    note: >-
+      Checks dependencies against OSV-format advisories (osv.dev, GHSA, PyPA) to catch known-vulnerable
+      versions before shipping.
+  - id: security
+    note: >-
+      Feeds OSV records into scanners and triage so findings share one schema across every
+      ecosystem.
+  - id: devops
+    note: >-
+      Fails or flags builds when dependency scans match OSV records, keeping known-vulnerable
+      versions out of releases.
+  problems:
+  - id: vulnerability-management
+    note: >-
+      Gives every ecosystem's advisories one machine-readable schema, so a single scan covers
+      them all.
+  - id: dependency-visibility
+    note: >-
+      Identifies affected package versions precisely, so dependency inventories can be matched
+      against known vulnerabilities.
 - id: sarif
   name: SARIF
   aliases: [Static Analysis Results Interchange Format]
@@ -64,6 +115,23 @@
     by code-scanning UIs (e.g. GitHub Code Scanning) and produced by linters, scanners, and
     policy tools such as Scorecard.
   kind: publication
+  personas:
+  - id: developer
+    note: >-
+      Reads scanner findings as SARIF in the editor or code-scanning UI instead of parsing
+      each tool's bespoke output.
+  - id: security
+    note: >-
+      Aggregates results from multiple scanners into one SARIF-based triage pipeline.
+  - id: devops
+    note: >-
+      Wires static-analysis tools into CI once, uploading SARIF wherever the code-scanning
+      platform expects it.
+  problems:
+  - id: vulnerability-management
+    note: >-
+      Normalizes static-analysis findings into one format, so triage doesn't depend on which
+      tool found the issue.
 - id: sbom
   name: Software Bill of Materials
   aliases: [SBOM]
@@ -73,6 +141,40 @@
     authoritative formats exist (CycloneDX, SPDX); this record models the SBOM concept itself
     rather than any single format.
   kind: publication
+  personas:
+  - id: developer
+    note: >-
+      Publishes an SBOM with each release so consumers can see exactly which components are
+      inside.
+  - id: ospo
+    note: >-
+      Requires SBOMs across the portfolio to track the components and licenses in software
+      the organization ships and consumes.
+  - id: security
+    note: >-
+      Queries SBOMs to scope exposure within hours of a new CVE instead of auditing each application
+      by hand.
+  - id: devops
+    note: >-
+      Generates SBOMs automatically in the build pipeline so every artifact ships with its
+      component inventory.
+  - id: executive
+    note: >-
+      Meets regulatory and customer demands (e.g. EO 14028, the Cyber Resilience Act) for
+      component transparency.
+  problems:
+  - id: dependency-visibility
+    note: >-
+      The machine-readable component inventory that every downstream dependency question starts
+      from.
+  - id: vulnerability-management
+    note: >-
+      Lets known-vulnerability data be matched against a precise component list instead of
+      guesswork.
+  - id: policy-compliance
+    note: >-
+      Satisfies the component-transparency requirements that regulation and procurement increasingly
+      mandate.
 - id: slsa-provenance
   name: SLSA Provenance
   url: https://slsa.dev/spec/v1.0/provenance
@@ -81,6 +183,27 @@
     build platform identity, source revision, build parameters, and the resulting artifact
     digest.
   kind: publication
+  personas:
+  - id: security
+    note: >-
+      Verifies provenance against expected source, builder, and parameters to detect tampering
+      between build and deployment.
+  - id: devops
+    note: >-
+      Configures build platforms to emit signed provenance for every artifact the pipeline
+      produces.
+  - id: package-manager
+    note: >-
+      Verifies and displays build provenance for published packages so consumers can check
+      who built what, from where.
+  problems:
+  - id: build-provenance
+    note: >-
+      The attestation format that records how, where, and from what an artifact was built.
+  - id: artifact-signing
+    note: >-
+      Binds the build record cryptographically to the artifact digest so provenance can't
+      be swapped or forged.
 - id: vex
   name: Vulnerability Exploitability eXchange
   aliases: [VEX]
@@ -89,6 +212,7 @@
     A machine-readable statement asserting whether a known vulnerability affects a given software
     artifact (and under what conditions). Pairs with SBOM and OSV records to reduce false-positive 
     vuln signals.
+  kind: publication
 - id: openssf-education
   name: OpenSSF Education Courses
   aliases: [OSSF-EDU]
@@ -312,3 +436,24 @@
     Mamber case studies demonstrating the value they have recieving in
     deploying  OpenSSF projects and practices.
   kind: publication
+  personas:
+  - id: developer
+    note: >-
+      Issues VEX statements for their releases so users aren't paged about vulnerabilities
+      that don't actually affect the product.
+  - id: security
+    note: >-
+      Consumes VEX to suppress non-exploitable findings and focus remediation on the vulnerabilities
+      that matter.
+  - id: devops
+    note: >-
+      Gates pipelines on exploitability rather than raw CVE counts, cutting false-positive
+      build failures.
+  problems:
+  - id: vulnerability-management
+    note: >-
+      States whether a vulnerability is actually exploitable in a given product, separating
+      real risk from noise.
+  - id: dependency-visibility
+    note: >-
+      Pairs with SBOMs to turn a raw component list into an actionable picture of exposure.

data/working-groups/orbit.yml

@@ -64,6 +64,14 @@ projects:
     note: >-
       Standardizes how risk and control evidence are expressed so posture can be assessed
       automatically and compared across projects.
+- id: gemara-whitepaper
+  name: Gemara Whitepaper
+  url: https://openssf.org/wp-content/uploads/2026/03/04_OpenSSF_Gemara-Project_Whitepaper.pdf
+  description: >-
+    "Gemara: A Governance, Risk, and Compliance Engineering Model for Automated Risk Assessment" —
+    the whitepaper defining Gemara's layered model of governance, risk, and compliance activities
+    and how they interoperate.
+  kind: publication
 - id: minder
   name: Minder
   url: https://github.com/mindersec/minder
@@ -73,6 +81,13 @@ projects:
     A software-supply-chain security platform that continuously verifies secure practices
     and enforces standardized policies across repositories and artefacts.
   kind: project
+  relationships:
+  - kind: consumes
+    target: osps-baseline
+    status: needs-review
+    note: >-
+      Baseline requirements can be enforced as Minder policy profiles across an organization's
+      repositories.
   personas:
   - id: developer
     note: >-

data/working-groups/securing-software-repositories.yml

@@ -26,17 +26,26 @@ working_group:
 projects:
 - id: malicious-packages
   name: Malicious Packages
+  url: https://github.com/ossf/malicious-packages
   openssf_url: https://openssf.org/projects/malicious-packages/
   description: >-
     An open source database of reports of malicious packages publshed on open source package repositories.
   kind: project
 - id: package-analysis
   name: Package Analysis
+  url: https://github.com/ossf/package-analysis
   openssf_url: https://openssf.org/projects/package-analysis/
   description: >-
     Dynamically and statically analyzes packages from open source package registries to detect
     malicious behavior such as credential exfiltration and backdoors.
   kind: project
+  relationships:
+  - kind: produces
+    target: osv-record
+    status: needs-review
+    note: >-
+      Detections feed the malicious-packages dataset, which publishes its advisories in OSV
+      format.
 - id: rstuf
   name: Repository Service for TUF (RSTUF)
   url: https://repository-service-tuf.readthedocs.io/

data/working-groups/supply-chain-integrity.yml

@@ -97,6 +97,16 @@ projects:
   - kind: consumes
     target: slsa-provenance
     status: confirmed
+  - kind: consumes
+    target: osv-record
+    status: needs-review
+    note: >-
+      Ingests OSV vulnerability data to link known vulnerabilities into the artifact graph.
+  - kind: consumes
+    target: vex
+    status: needs-review
+    note: >-
+      Ingests VEX statements so exploitability status can be queried alongside composition.
   personas:
   - id: developer
     note: >-
@@ -131,7 +141,7 @@ projects:
     note: >-
       Joins vulnerability data to the dependency graph to reveal the blast radius of a newly
       disclosed flaw.
-  compatible_with: [protobom, osv-openvex]
+  compatible_with: [protobom]
 - id: slsa
   name: SLSA
   url: https://slsa.dev/
@@ -194,3 +204,9 @@ projects:
     Enables continuous software delivery onto air-gapped, disconnected, or otherwise constrained
     systems by bundling applications and their dependencies into portable packages.
   kind: project
+  relationships:
+  - kind: produces
+    target: sbom
+    status: needs-review
+    note: >-
+      Generates SBOMs for the images and components it bundles into air-gapped packages.

data/working-groups/uncategorized.yml

@@ -36,6 +36,17 @@ projects:
     Format-agnostic Software Bill of Materials tooling that bridges the gap between SBOM generation
     and SBOM analysis — fetching, merging, and manipulating SBOMs across SPDX and CycloneDX.
   kind: project
+  relationships:
+  - kind: consumes
+    target: sbom
+    status: needs-review
+    note: >-
+      Fetches and merges existing SPDX and CycloneDX documents from registries and repositories.
+  - kind: produces
+    target: sbom
+    status: needs-review
+    note: >-
+      Emits the merged, translated, or otherwise manipulated SBOMs it assembles.
   personas:
   - id: developer
     note: >-
@@ -86,6 +97,18 @@ projects:
     A shared library and toolset for generating, translating, and consuming Software Bills
     of Materials in standard formats such as SPDX and CycloneDX.
   kind: project
+  relationships:
+  - kind: produces
+    target: sbom
+    status: needs-review
+    note: >-
+      Generates and translates SBOM documents in SPDX and CycloneDX formats.
+  - kind: consumes
+    target: sbom
+    status: needs-review
+    note: >-
+      Reads standard-format SBOMs into its protobuf representation for other tooling to work
+      with.
   personas:
   - id: developer
     note: >-
@@ -116,7 +139,7 @@ projects:
     note: >-
       Generates and translates SBOMs in standard formats so the component inventory travels
       with the artefact.
-  compatible_with: [guac, osv-openvex]
+  compatible_with: [guac]
 - id: sbomit
   name: SBOMit
   url: https://sbomit.dev/
@@ -126,6 +149,17 @@ projects:
     Bills of Materials, cryptographically validating the steps performed across the software
     supply chain.
   kind: project
+  relationships:
+  - kind: consumes
+    target: in-toto-attestation
+    status: needs-review
+    note: >-
+      Embeds in-toto and Witness attestations into the SBOMs it processes.
+  - kind: produces
+    target: sbom
+    status: needs-review
+    note: >-
+      Outputs SBOMs carrying embedded attestations for each supply-chain step.
   personas:
   - id: developer
     note: >-