diff --git a/data/definitions/publications.yml b/data/definitions/publications.yml
index 615a6c5..35411ae 100644
--- a/data/definitions/publications.yml
+++ b/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.
diff --git a/data/working-groups/orbit.yml b/data/working-groups/orbit.yml
index a475c80..82b47a6 100644
--- a/data/working-groups/orbit.yml
+++ b/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: >-
diff --git a/data/working-groups/securing-software-repositories.yml b/data/working-groups/securing-software-repositories.yml
index e5ec207..e52b6e9 100644
--- a/data/working-groups/securing-software-repositories.yml
+++ b/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/
diff --git a/data/working-groups/supply-chain-integrity.yml b/data/working-groups/supply-chain-integrity.yml
index 40bbba2..e07133d 100644
--- a/data/working-groups/supply-chain-integrity.yml
+++ b/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.
diff --git a/data/working-groups/uncategorized.yml b/data/working-groups/uncategorized.yml
index 7fff9ba..c2a8fc9 100644
--- a/data/working-groups/uncategorized.yml
+++ b/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: >-
diff --git a/data/working-groups/vulnerability-disclosures.yml b/data/working-groups/vulnerability-disclosures.yml
index df009d8..ff40175 100644
--- a/data/working-groups/vulnerability-disclosures.yml
+++ b/data/working-groups/vulnerability-disclosures.yml
@@ -72,6 +72,29 @@ projects:
description: >-
An implementation of the Vulnerability Exploitability Exchange (VEX for short) that is designed to be minimal, compliant, interoperable, and embeddable.
kind: project
+ relationships:
+ - kind: implements
+ target: vex
+ status: needs-review
+ note: >-
+ OpenVEX is a concrete, minimal implementation of the CISA VEX concept.
+ personas:
+ - id: developer
+ note: >-
+ Generates OpenVEX documents to explicitly inform users that their project is not affected
+ by a specific vulnerability found in a dependency.
+ - id: security
+ note: >-
+ Adopts OpenVEX to standardize exploitability statements and coordinate incident response
+ and analysis.
+ - id: devops
+ note: >-
+ Automates the ingestion of OpenVEX statements in the pipeline to prevent false positive
+ vulnerability alerts from breaking builds.
+ - id: executive
+ note: >-
+ Reviews documented exploitability statements to understand which disclosed vulnerabilities
+ actually carry post-release risk.
problems:
- id: vulnerability-management
note: >-
@@ -85,6 +108,27 @@ projects:
description: >-
A standard interchange format for describing vulnerabilities in open source packages.
kind: publication
+ personas:
+ - id: ospo
+ note: >-
+ Adopts the OSV schema to standardize how vulnerability information is ingested and tracked
+ across all enterprise open source usage.
+ - id: security
+ note: >-
+ Adopts the OSV Schema to standardize vulnerability reporting and coordinate incident
+ response and analysis.
+ - id: devops
+ note: >-
+ Automates the ingestion of OSV data in the pipeline so dependency scans report against
+ one machine-readable schema.
+ - id: package-manager
+ note: >-
+ Serves OSV-formatted advisories directly from the registry to ensure package consumers
+ receive actionable, machine-readable vulnerability updates.
+ - id: executive
+ note: >-
+ Reviews standardized vulnerability data formats to clearly understand post-release risk
+ during procurement and auditing.
problems:
- id: vulnerability-management
note: >-
diff --git a/theme/_layouts/publication.html b/theme/_layouts/publication.html
index 70a7226..af87fb2 100644
--- a/theme/_layouts/publication.html
+++ b/theme/_layouts/publication.html
@@ -38,4 +38,26 @@
+{%- comment -%}
+ security-insights only: which records publish a Security Insights file is
+ already stated once, by each record's own `insights:` link — so the list is
+ derived from that field, never authored as produces-edges (which would be a
+ second place to state the fact).
+{%- endcomment -%}
+{%- if publication.id == "security-insights" -%}
+{%- assign pool = site.data.catalog.projects | concat: site.data.catalog.publications -%}
+
+{%- endif -%}
+
{% include record-detail.html record=publication base="publications" %}
diff --git a/theme/pages/about.md b/theme/pages/about.md
index 99b2bf0..1adaa9a 100644
--- a/theme/pages/about.md
+++ b/theme/pages/about.md
@@ -45,13 +45,13 @@ problem page surfaces the personas who care.
### Projects
{% for project in site.data.catalog.projects %}
-- **[{{ project.name }}]({{ '/projects/' | append: project.id | append: '/' | relative_url }})** — project site ↗
+- **[{{ project.name }}]({{ '/projects/' | append: project.id | append: '/' | relative_url }})**{% if project.url %} — project site ↗{% endif %}
{% endfor %}
### Publications
{% for pub in site.data.catalog.publications %}
-- **[{{ pub.name }}]({{ '/publications/' | append: pub.id | append: '/' | relative_url }})** — read it ↗
+- **[{{ pub.name }}]({{ '/publications/' | append: pub.id | append: '/' | relative_url }})**{% if pub.url %} — read it ↗{% endif %}
{% endfor %}
## How to use this site