From 38581cd4cc9d8faa42b86125c44763a498c18e76 Mon Sep 17 00:00:00 2001 From: Eddie Knight Date: Tue, 22 Sep 2026 10:12:28 -0500 Subject: [PATCH 1/2] fix: repair the catalog references upstream left dangling The 2026 remap (#38) and publications import (#39) landed with four references to records that no longer exist, so main does not build -- `jekyll build` aborts in catalog_pages.rb's validate!. osv-openvex was split into `openvex` (project) and `osv-schema` (publication), leaving three referrers behind: - guac and protobom dropped it from `compatible_with`. No information lost: both new records already declare `compatible_with: [guac, protobom]`, and related records render the union of both directions, so the pages are unchanged. - osv-record's `extends` edge is dropped. Re-authoring it against the split records is relationship-mapping work and belongs with #42, not with unbreaking the build; the pinned comment above the record says so and the open question is unchanged. gemara-whitepaper was deleted while a reference to it was added. Restored into orbit.yml rather than uncategorized.yml, where it used to sit: #38 placed gemara itself in ORBIT, which confirms the placement the holding pen's header had flagged as likely but unconfirmed. Separately, #38 added malicious-packages and package-analysis without a `url`, and about.md rendered `` for them, failing htmlproofer. Added both urls, and guarded the two loops so a record without a url renders no link at all -- the same `{% if %}` guard the project and publication layouts already use. `make test` passes. The CI that enforces this lands separately, on top. Signed-off-by: Eddie Knight --- data/definitions/publications.yml | 24 ++++++++----------- data/working-groups/orbit.yml | 8 +++++++ .../securing-software-repositories.yml | 2 ++ .../working-groups/supply-chain-integrity.yml | 2 +- data/working-groups/uncategorized.yml | 2 +- theme/pages/about.md | 4 ++-- 6 files changed, 24 insertions(+), 18 deletions(-) diff --git a/data/definitions/publications.yml b/data/definitions/publications.yml index 615a6c5..5d0a2fd 100644 --- a/data/definitions/publications.yml +++ b/data/definitions/publications.yml @@ -26,17 +26,20 @@ kind: publication # 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. # +# This record carried an `extends` edge pointing at `osv-openvex` until that +# record was split into `openvex` and `osv-schema`. The edge is dropped here +# rather than guessed at — re-authoring it is relationship-mapping work, not +# part of unbreaking the build. +# # 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. - id: osv-record @@ -48,13 +51,6 @@ GHSA, PyPA, Go vuln DB) and consumed by vuln scanners and SCA tools. Distinct from the `osv-schema` project, which is the authoring effort defining the f… kind: publication - relationships: - - kind: extends - target: osv-openvex - status: confirmed - note: >- - The artifact (the record format itself) is the concrete instance of what the OSV Schema - project specifies. - id: sarif name: SARIF aliases: [Static Analysis Results Interchange Format] diff --git a/data/working-groups/orbit.yml b/data/working-groups/orbit.yml index a475c80..9b6c0e1 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 diff --git a/data/working-groups/securing-software-repositories.yml b/data/working-groups/securing-software-repositories.yml index e5ec207..ba5db72 100644 --- a/data/working-groups/securing-software-repositories.yml +++ b/data/working-groups/securing-software-repositories.yml @@ -26,12 +26,14 @@ 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 diff --git a/data/working-groups/supply-chain-integrity.yml b/data/working-groups/supply-chain-integrity.yml index 40bbba2..7f2a5d7 100644 --- a/data/working-groups/supply-chain-integrity.yml +++ b/data/working-groups/supply-chain-integrity.yml @@ -131,7 +131,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/ diff --git a/data/working-groups/uncategorized.yml b/data/working-groups/uncategorized.yml index 7fff9ba..02bb914 100644 --- a/data/working-groups/uncategorized.yml +++ b/data/working-groups/uncategorized.yml @@ -116,7 +116,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/ 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 From 303870115b82a7493288be32a099bcc58bd6cae6 Mon Sep 17 00:00:00 2001 From: Eddie Knight Date: Fri, 28 Aug 2026 08:39:39 -0500 Subject: [PATCH 2/2] data: map publications to personas, problems, and project relationships Publications rendered persona/problem sections and relationship edges identically to projects since the 4P's reorg, but most of the data feeding those sections was missing. This fills the gaps: - needs-review produces/consumes/implements edges touching sbom, vex, osv-record, in-toto-attestation, and osps-baseline, authored on the declaring records (bomctl, protobom, sbomit, GUAC, Zarf, Minder, Package Analysis, OpenVEX) - curator-drafted persona and problem mappings for the six externally-owned specs in data/definitions/publications.yml - a derived 'Published by' list on /publications/security-insights/, built from each record's own insights: link rather than authored edges, so the fact stays stated in one place Rebased off d84d647 onto the post-remap catalog, which moved three things: - bomctl, protobom, and sbomit left security-tooling.yml when #38 deleted it; their sbom and in-toto-attestation edges move with them into uncategorized.yml. - the osv-openvex record was split by #39 into openvex (project) and osv-schema (publication). Its `implements: vex` edge is authored on openvex, whose note already named OpenVEX. Its six persona notes were written for the combined record: three name one side and are assigned accordingly, three described both and are split into a record-specific note each, staying close to the original wording. - osv-record's `extends` edge is authored here against osv-schema, the record that replaced its former target. Five edges from the original branch are gone with their declaring records: #38 removed in-toto, slsa-github-generator, and slsa-verifier from the catalog entirely, so there is nowhere left to author them. slsa-provenance still has two incoming edges and is not orphaned. `vex` was the only record in definitions/publications.yml without a `kind:`, so relationships-section.html routed it to /projects/vex/ and htmlproofer failed. Latent until this branch authored the first edge pointing at it; fixed here because nothing before this needed it. Build and link check pass. Signed-off-by: Eddie Knight --- data/definitions/publications.yml | 159 +++++++++++++++++- data/working-groups/orbit.yml | 7 + .../securing-software-repositories.yml | 7 + .../working-groups/supply-chain-integrity.yml | 16 ++ data/working-groups/uncategorized.yml | 34 ++++ .../vulnerability-disclosures.yml | 44 +++++ theme/_layouts/publication.html | 22 +++ 7 files changed, 284 insertions(+), 5 deletions(-) diff --git a/data/definitions/publications.yml b/data/definitions/publications.yml index 5d0a2fd..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,6 +29,27 @@ 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-schema` record in @@ -35,13 +61,12 @@ # 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. # -# This record carried an `extends` edge pointing at `osv-openvex` until that -# record was split into `openvex` and `osv-schema`. The edge is dropped here -# rather than guessed at — re-authoring it is relationship-mapping work, not -# part of unbreaking the build. +# 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] @@ -51,6 +76,36 @@ GHSA, PyPA, Go vuln DB) and consumed by vuln scanners and SCA tools. Distinct from the `osv-schema` project, which is the authoring effort defining the f… kind: publication + relationships: + - kind: extends + target: osv-schema + status: needs-review + note: >- + The artifact (the record format itself) is the concrete instance of what the OSV Schema + 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] @@ -60,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] @@ -69,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 @@ -77,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] @@ -85,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] @@ -308,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 9b6c0e1..82b47a6 100644 --- a/data/working-groups/orbit.yml +++ b/data/working-groups/orbit.yml @@ -81,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 ba5db72..e52b6e9 100644 --- a/data/working-groups/securing-software-repositories.yml +++ b/data/working-groups/securing-software-repositories.yml @@ -39,6 +39,13 @@ projects: 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 7f2a5d7..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: >- @@ -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 02bb914..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: >- @@ -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 @@

{{ publication.name }}

+{%- 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 -%} +
+

Published by

+

Catalog records shipping a Security Insights file, derived from each record's own insights link.

+
+ {%- for r in pool -%} + {%- if r.insights and r.id != publication.id -%} + {%- if r.kind == "publication" -%}{%- assign b = "/publications/" -%}{%- else -%}{%- assign b = "/projects/" -%}{%- endif -%} + {{ r.name }} + {%- endif -%} + {%- endfor -%} +
+
+{%- endif -%} + {% include record-detail.html record=publication base="publications" %}