From e2ab809534d5837dac61310451e7235ba714ee6a Mon Sep 17 00:00:00 2001 From: Michael Lieberman Date: Mon, 29 Jun 2026 11:41:06 -0400 Subject: [PATCH] Add architecture diagram and mapping to slsa threats The idea here is to map what we're doing in OpenSSF to the three main categories of personas: Producers, Distributors and Consumers. In addition we map SLSA threats to the TIs and associated projects and how they might help. Much of this was based on notes and diagrams fed into Claude to help with layout. Signed-off-by: Michael Lieberman --- .ruby-version | 1 + _data/architecture_records.yml | 954 +++++++++++++++++++++++++++ _data/artifacts.yml | 61 ++ _data/categories.yml | 42 ++ _data/navigation.yml | 4 + _data/projects.yml | 115 ++++ _data/sdlc_stages.yml | 33 + _data/sidebar.yml | 62 ++ _data/supply_chain_actors.yml | 24 + _data/threat_categories.yml | 26 + _data/threats.yml | 461 +++++++++++++ _includes/architecture-style.html | 690 +++++++++++++++++++ _includes/pillar-grid.html | 73 ++ _includes/relationships-section.html | 109 +++ _includes/threats-list.html | 76 +++ _layouts/artifact.html | 77 +++ _layouts/project.html | 2 + architecture/gaps.md | 119 ++++ architecture/index.md | 92 +++ architecture/overview.md | 66 ++ architecture/secure-consumption.md | 28 + architecture/secure-distribution.md | 28 + architecture/secure-production.md | 28 + architecture/slsa-threats.md | 46 ++ architecture/stewardship.md | 28 + architecture/tac-summary.md | 125 ++++ artifacts/in-toto-attestation.md | 7 + artifacts/index.md | 27 + artifacts/osv-record.md | 7 + artifacts/sarif.md | 7 + artifacts/sbom.md | 7 + artifacts/slsa-provenance.md | 7 + artifacts/vex.md | 7 + assets/js/architecture-filter.js | 66 ++ projects/fuzz-introspector.md | 8 + projects/fuzzingbrain.md | 8 + projects/in-toto.md | 8 + projects/openssf-model-signing.md | 8 + projects/oss-crs.md | 8 + projects/package-analysis.md | 8 + projects/secure-agentic-framework.md | 8 + projects/slsa-github-generator.md | 8 + projects/slsa-verifier.md | 8 + projects/zarf.md | 8 + 44 files changed, 3585 insertions(+) create mode 100644 .ruby-version create mode 100644 _data/architecture_records.yml create mode 100644 _data/artifacts.yml create mode 100644 _data/categories.yml create mode 100644 _data/sdlc_stages.yml create mode 100644 _data/supply_chain_actors.yml create mode 100644 _data/threat_categories.yml create mode 100644 _data/threats.yml create mode 100644 _includes/architecture-style.html create mode 100644 _includes/pillar-grid.html create mode 100644 _includes/relationships-section.html create mode 100644 _includes/threats-list.html create mode 100644 _layouts/artifact.html create mode 100644 architecture/gaps.md create mode 100644 architecture/index.md create mode 100644 architecture/overview.md create mode 100644 architecture/secure-consumption.md create mode 100644 architecture/secure-distribution.md create mode 100644 architecture/secure-production.md create mode 100644 architecture/slsa-threats.md create mode 100644 architecture/stewardship.md create mode 100644 architecture/tac-summary.md create mode 100644 artifacts/in-toto-attestation.md create mode 100644 artifacts/index.md create mode 100644 artifacts/osv-record.md create mode 100644 artifacts/sarif.md create mode 100644 artifacts/sbom.md create mode 100644 artifacts/slsa-provenance.md create mode 100644 artifacts/vex.md create mode 100644 assets/js/architecture-filter.js create mode 100644 projects/fuzz-introspector.md create mode 100644 projects/fuzzingbrain.md create mode 100644 projects/in-toto.md create mode 100644 projects/openssf-model-signing.md create mode 100644 projects/oss-crs.md create mode 100644 projects/package-analysis.md create mode 100644 projects/secure-agentic-framework.md create mode 100644 projects/slsa-github-generator.md create mode 100644 projects/slsa-verifier.md create mode 100644 projects/zarf.md diff --git a/.ruby-version b/.ruby-version new file mode 100644 index 0000000..b9b3b0d --- /dev/null +++ b/.ruby-version @@ -0,0 +1 @@ +3.3.11 diff --git a/_data/architecture_records.yml b/_data/architecture_records.yml new file mode 100644 index 0000000..6b8bb48 --- /dev/null +++ b/_data/architecture_records.yml @@ -0,0 +1,954 @@ +# ARCHITECTURE RECORDS — the projects + working groups overlaid on +# the SDLC × supply-chain-actor matrix on /architecture/* pages. +# +# Each entry: +# id: matches the slug of the corresponding /projects// page +# in projects.yml when has_community_page is true; otherwise +# a stable ours-only id imported from the sibling research catalog. +# name: display name on the pillar pages. +# kind: project | working-group. +# has_community_page: when true, the pillar pages wrap the name +# in so it links to the matching page. +# url: external URL for the upstream project. +# sdlc_stages: which SDLC stages this record applies to (see +# sdlc_stages.yml). +# supply_chain_actors: which actor positions this record applies to +# (see supply_chain_actors.yml). +# +# Imported 2026-06-28 from the sibling ossf-architecture research catalog. + +- id: ai-ml-security + name: AI/ML Security + kind: working-group + has_community_page: false + url: https://openssf.org/community/openssf-working-groups/ + sdlc_stages: [build, consumer, distribution] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: build + actor: software-consumer + status: needs-review + text: Some ML consumers run derivative builds; the WG's tooling carries forward to them. + note: Consumer-as-producer pattern; confirm scope. + - stage: build + actor: software-producer + status: confirmed + text: Coordinates standards and tooling — model signing, attestations, supply-chain hygiene — that ML producers run at training/packaging time. + - stage: consumer + actor: software-consumer + status: needs-review + text: Consumers apply WG runtime-security guidance when deploying ML systems. + note: Consumer-runtime focus partially documented; confirm scope. + - stage: consumer + actor: software-producer + status: needs-review + text: Producers re-evaluate model-runtime security (e.g., prompt injection, adversarial inputs) per WG guidance. + note: Consumer-runtime focus partially documented; confirm scope. + - stage: distribution + actor: software-consumer + status: needs-review + text: Consumers verify ML signatures and provenance at fetch time using WG-coordinated tooling. + note: Same caveat as distribution × producer. + - stage: distribution + actor: software-producer + status: needs-review + text: Coordinates how signed ML artefacts move through model hubs and registries, mirroring the supply-chain stories on the non-ML side. + note: Distribution-stage WG focus is implicit in the AI/ML supply chain story; confirm explicit framing. + categories: [governance] +- id: bear + name: BEAR (Belonging, Empowerment, Allyship, and Representation) + kind: working-group + has_community_page: false + url: https://openssf.org/community/openssf-working-groups/ + sdlc_stages: [producer] + supply_chain_actors: [other, software-producer] + cell_synopses: + - stage: producer + actor: other + status: confirmed + text: BEAR's work shapes the producer community itself — who feels welcome to participate, how mentorship operates, how representation is improved — rather than any specific technical control. + - stage: producer + actor: software-producer + status: needs-review + text: Producers benefit downstream from a broader, more sustainable contributor community. + note: Indirect framing; confirm whether this should be tagged as software-producer at all. + categories: [governance] +- id: best-practices-badge + name: Best Practices Badge + kind: project + has_community_page: true + url: https://openssf.org/projects/best-practices-badge/ + sdlc_stages: [producer, source] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: producer + actor: software-consumer + status: needs-review + text: Downstream consumers can read the badge to gauge a project's producer-side hygiene before adoption. + note: Consumer use is documented anecdotally rather than as a stated programme goal; confirm with upstream. + - stage: producer + actor: software-producer + status: confirmed + text: Defines a self-assessment programme that maintainers complete on behalf of their own project, encoding what the foundation expects responsible OSS producers to do. + - stage: source + actor: software-consumer + status: needs-review + text: Consumers use the badge as a screening signal alongside other source-layer metadata. + note: Consumer-side use of source-layer criteria isn't a stated programme goal; confirm with upstream. + - stage: source + actor: software-producer + status: confirmed + text: 'Most badge criteria operate at the source-repository layer: branch protection, code review, vulnerability reporting, and CI on commit. The badge effectively codifies source-stage producer hygiene.' + categories: [best-practices] +- id: best-practices-wg + name: Best Practices for Open Source Developers + kind: working-group + has_community_page: false + url: https://openssf.org/community/openssf-working-groups/ + sdlc_stages: [producer, source] + supply_chain_actors: [software-producer] + cell_synopses: + - stage: producer + actor: software-producer + status: confirmed + text: 'Educates the producer audience directly: developer training, the Concise Guide, course material, conference workshops.' + - stage: source + actor: software-producer + status: confirmed + text: Stewards source-layer best-practice work (Scorecard, Best Practices Badge, education materials) targeting open source maintainers and the repos they manage. + categories: [best-practices, governance] +- id: bomctl + name: Bomctl + kind: project + has_community_page: true + url: https://openssf.org/projects/bomctl/ + sdlc_stages: [dependencies, distribution] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: dependencies + actor: software-consumer + status: confirmed + text: Consumers feed SBOMs from multiple producers into bomctl to merge, deduplicate, and query the dependency graph of what they've installed. + - stage: dependencies + actor: software-producer + status: confirmed + text: 'bomctl''s central concern is the SBOM-as-dependency-graph: producers use it to construct, sign, and consolidate the per-component data their downstream consumers need to perform dependency analysis.' + - stage: distribution + actor: software-consumer + status: needs-review + text: Distributors and consumers can use bomctl to extract or transform SBOMs they received via a registry. + note: Same caveat as producer; the distribution stage tag is needs-review on the record. + - stage: distribution + actor: software-producer + status: needs-review + text: Producers use bomctl to manipulate SBOMs (e.g., translate between formats, sign, attach) at release time so the distributed artefact carries the SBOM the consumer expects. + note: Distribution-stage producer use case; bomctl is currently distribution-tagged needs-review on the record itself. + categories: [tooling] +- id: criticality-score + name: Criticality Score + kind: project + has_community_page: true + url: https://openssf.org/projects/criticality-score/ + sdlc_stages: [dependencies] + supply_chain_actors: [other, software-consumer] + cell_synopses: + - stage: dependencies + actor: other + status: needs-review + text: Funders and policy bodies use criticality scores to direct support to projects whose compromise would have outsized impact. + note: Funder / policy framing is documented in Alpha-Omega material; confirm direct upstream statement. + - stage: dependencies + actor: software-consumer + status: confirmed + text: Identifies the most critical OSS dependencies in an ecosystem (by influence and downstream reach) so consumers can prioritise auditing, monitoring, and Alpha-Omega-style investment. + categories: [tooling] +- id: fuzz-introspector + name: Fuzz Introspector + kind: project + has_community_page: true + url: https://openssf.org/projects/fuzz-introspector/ + sdlc_stages: [build, source] + supply_chain_actors: [software-producer] + cell_synopses: + - stage: build + actor: software-producer + status: needs-review + text: Fuzz Introspector typically runs inside the producer's CI/build pipeline alongside the fuzzer itself, where its reports are generated. + note: The build-stage placement is a deployment-pattern observation, not a stated upstream scope; confirm. + - stage: source + actor: software-producer + status: confirmed + text: Analyses the source code of fuzz harnesses (and the code they exercise) to expose untouched reachability, helping producers improve harness coverage rather than running fuzzers blind. + categories: [tooling] +- id: fuzzingbrain + name: FuzzingBrain + kind: project + has_community_page: true + url: https://docs.google.com/document/d/1OxjsWHO2v8SfzG4KkqyJEAy8yn1GA1yjgN7QCm6q85Q/edit + sdlc_stages: [source] + supply_chain_actors: [software-producer] + cell_synopses: + - stage: source + actor: software-producer + status: needs-review + text: 'Provisional: fuzzing-related projects historically operate on producer-controlled source repositories. Awaiting public docs to confirm the exact source-stage role.' + note: Formation-stage project; upstream documentation not yet available. + categories: [tooling] +- id: gemara + name: Gemara + kind: project + has_community_page: true + url: https://openssf.org/projects/gemara/ + sdlc_stages: [source] + supply_chain_actors: [other, software-producer] + cell_synopses: + - stage: source + actor: other + status: needs-review + text: Gemara models the categorical governance controls a project commits to in its repository (e.g., release policy, dependency policy, vulnerability disclosure) so reviewers and auditors can compare + across projects on the same axes. + note: Gemara's framing as repo-anchored governance modelling is recent; confirm scope with the project. + - stage: source + actor: software-producer + status: needs-review + text: Producers use Gemara to express their project's governance commitments in machine-readable form alongside the source they control. + note: Producer-side adoption is the design intent but documentation is sparse; confirm with upstream. + categories: [specification] +- id: gittuf + name: gittuf + kind: project + has_community_page: true + url: https://openssf.org/projects/gittuf/ + sdlc_stages: [source] + supply_chain_actors: [software-producer] + cell_synopses: + - stage: source + actor: software-producer + status: confirmed + text: 'Applies TUF-style signed metadata to a Git repository: refs, tags, and the policy that determines who can write what. Producers gain cryptographic attestation that the code they committed is + the code being built, mitigating source-forge compromise.' + categories: [specification] +- id: global-cyber-policy + name: Global Cyber Policy + kind: working-group + has_community_page: false + url: https://openssf.org/community/openssf-working-groups/ + sdlc_stages: [producer] + supply_chain_actors: [other] + cell_synopses: + - stage: producer + actor: other + status: needs-review + text: Tracks legislative and regulatory developments that shape the constraints open source producers operate under (NIS2, CRA, similar regimes). + note: SDLC-stage tagging is a shoehorn per the constitution v1.1.0 note on governance records; confirm whether persona/stage placement should evolve. + categories: [governance] +- id: governing-board + name: OpenSSF Governing Board + kind: working-group + has_community_page: false + url: https://openssf.org/about/board/ + sdlc_stages: [producer] + supply_chain_actors: [other] + cell_synopses: + - stage: producer + actor: other + status: confirmed + text: 'Strategic and resourcing oversight for the OpenSSF: priorities, funding, member engagement, public posture. Sets the scope within which the technical work happens.' + categories: [governance] +- id: guac + name: GUAC + kind: project + has_community_page: true + url: https://openssf.org/projects/guac/ + sdlc_stages: [consumer, dependencies] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: consumer + actor: software-consumer + status: needs-review + text: Consumers query GUAC at evaluation time (or as a periodic job) to triage their dependency graph against the latest vulnerability data. + note: The consumer-runtime tag overlaps with the dependencies-stage tag; both currently apply but the framing differs. + - stage: consumer + actor: software-producer + status: needs-review + text: Producers running their own GUAC instance also query it at evaluation time for their own outbound risk. + note: Loosely fits the consumer stage; confirm whether this is a separate cell from dependencies × producer. + - stage: dependencies + actor: software-consumer + status: confirmed + text: GUAC ingests SBOMs, vulnerabilities, provenance, and other supply-chain metadata into a unified graph so consumers can ask 'what depends on this?' and 'what is exploitable for me?' without stitching + the data themselves. + - stage: dependencies + actor: software-producer + status: needs-review + text: Producers can ingest their own SBOMs into a GUAC instance for outbound impact analysis on disclosures. + note: Producer use case is documented but less central than consumer-side analysis; confirm with upstream. + relationships: + - target: sbom + kind: consumes + status: confirmed + - target: slsa-provenance + kind: consumes + status: confirmed + categories: [tooling] +- id: in-toto + name: in-toto + kind: project + has_community_page: true + url: https://in-toto.io/ + sdlc_stages: [build] + supply_chain_actors: [software-producer] + relationships: + - target: in-toto-attestation + kind: produces + status: confirmed + categories: [specification] +- id: minder + name: Minder + kind: project + has_community_page: true + url: https://openssf.org/projects/minder/ + sdlc_stages: [source] + supply_chain_actors: [other, software-producer] + cell_synopses: + - stage: source + actor: other + status: needs-review + text: Compliance and security teams use Minder to express their corporate posture as enforceable policy on the source layer. + note: Compliance-team framing is documented in marketing material; confirm specific upstream framing. + - stage: source + actor: software-producer + status: confirmed + text: Continuously enforces policy across a producer's source repositories — branch protection, dependency review, secret scanning, vulnerability response — so the producer's policy is the actual policy + on every repo, not just the intended one. + categories: [tooling] +- id: open-bao + name: OpenBao + kind: project + has_community_page: true + url: https://openssf.org/projects/openbao/ + sdlc_stages: [build, consumer] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: build + actor: software-consumer + status: needs-review + text: A few consumer-operated build platforms also consume OpenBao for the build secrets they ingest. + note: Less common than producer-side build use; confirm whether to tag. + - stage: build + actor: software-producer + status: needs-review + text: Producers' build pipelines fetch credentials, signing keys, and short-lived tokens from OpenBao at build time so secret material never lives in the build environment longer than the job needs + it. + note: Build-stage role is the dominant deployment pattern but isn't framed as OpenBao's central concern by upstream. + - stage: consumer + actor: software-consumer + status: confirmed + text: Application operators (downstream consumers of the OpenBao image) deploy it to manage their own runtime secrets, key rotation, and certificate issuance. + - stage: consumer + actor: software-producer + status: confirmed + text: Producers run OpenBao to manage the secrets their applications consume at runtime, replacing static configuration with short-lived, audited credential leases. + categories: [tooling] +- id: openssf-model-signing + name: OpenSSF Model Signing + kind: project + has_community_page: true + url: https://openssf.org/projects/model-signing/ + sdlc_stages: [build, distribution] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: build + actor: software-consumer + status: needs-review + text: ML consumers who build derived models (fine-tuning, distillation) themselves take on the producer role and re-sign the derivative — a build-stage flow on the consumer side. + note: Consumer-as-producer pattern is real for ML but not the documented central use case; confirm. + - stage: build + actor: software-producer + status: confirmed + text: ML producers run the model-signing CLI/library as part of their model-publication pipeline, producing a signed manifest over the model artefacts and binding it to a Sigstore identity. + - stage: distribution + actor: software-consumer + status: confirmed + text: Consumers verify model signatures before loading, defending against tampered weights from compromised mirrors or model hubs. + - stage: distribution + actor: software-producer + status: confirmed + text: Signed model manifests travel with the model through Hugging Face, registries, and other ML distribution channels, so the signature is available wherever the model is fetched. + categories: [specification] +- id: openssf-scorecard + name: OpenSSF Scorecard + kind: project + has_community_page: true + url: https://openssf.org/projects/scorecard/ + sdlc_stages: [build, source] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: build + actor: software-consumer + status: needs-review + text: Consumers reading a Scorecard report see build-stage signals (signed releases, packaging) alongside source-stage signals. + note: Scorecard's build-stage coverage is partial within its overall check set; framing depends on which checks the consumer cares about. + - stage: build + actor: software-producer + status: needs-review + text: A subset of checks (Signed-Releases, Packaging, Token-Permissions, CI-Tests) reaches into the build/release stage, so a producer who runs Scorecard sees flags on build-stage hygiene too. + note: Scorecard's build-stage coverage is partial; framing depends on which checks the producer cares about. + - stage: source + actor: software-consumer + status: confirmed + text: 'Consumers use Scorecard scores as a fast screening signal when evaluating a third-party dependency: a low score on Code-Review or Branch-Protection means the producer hasn''t hardened the supply-chain + entry.' + - stage: source + actor: software-producer + status: confirmed + text: Runs automated checks against a project's source repository — branch protection, code review, dependency-update, vulnerability scanning, etc. — and assigns each a per-check score so the producer + can spot gaps. + relationships: + - target: osv-record + kind: consumes + status: needs-review + note: Scorecard reads vulnerability data via the OSV API; whether that counts as consuming OSV records or only querying the database is a curator judgement call. + - target: sarif + kind: produces + status: confirmed + categories: [tooling] +- id: orbit + name: ORBIT (Open Resources for Baselines, Interoperability, and Tooling) + kind: working-group + has_community_page: false + url: https://openssf.org/community/openssf-working-groups/ + sdlc_stages: [producer, source] + supply_chain_actors: [other, software-producer] + cell_synopses: + - stage: producer + actor: other + status: confirmed + text: Auditors and compliance teams reach back to producer-stage practices when grading a project against the Baseline. + - stage: producer + actor: software-producer + status: confirmed + text: Producer-stage guidance (development practices, contributor hygiene, supported toolchain) sits alongside the source-layer criteria. + - stage: source + actor: other + status: confirmed + text: Compliance/risk reviewers use ORBIT-coordinated material to map repository evidence to international frameworks and regulations. + - stage: source + actor: software-producer + status: confirmed + text: Stewards the OSPS Baseline and the source-layer evidence-gathering tooling producers run to demonstrate conformance. + categories: [governance] +- id: osps-baseline + name: OSPS Baseline + kind: project + has_community_page: true + url: https://openssf.org/projects/osps-baseline/ + sdlc_stages: [producer, source] + supply_chain_actors: [other, software-producer] + cell_synopses: + - stage: producer + actor: other + status: needs-review + text: Compliance and governance reviewers use the Baseline as an audit checklist when scoring producer-side practices. + note: Compliance/audit use pattern is documented in ORBIT material; confirm specific framing. + - stage: producer + actor: software-producer + status: confirmed + text: Defines the minimum set of practices an OSS project's maintainers MUST adopt on their development environment and project setup (account hygiene, signing, secret handling, supported toolchain). + Acts as the producer-stage 'floor'. + - stage: source + actor: other + status: needs-review + text: Compliance and governance reviewers map repo-level evidence to specific Baseline criteria when grading a project. + note: Same caveat as producer × other; confirm with the ORBIT WG. + - stage: source + actor: software-producer + status: confirmed + text: Baseline requirements that anchor at the repository — branch protection, signed commits, vulnerability disclosure metadata, contribution policies — live here and are graded by ORBIT-aligned tooling. + categories: [best-practices, specification] +- id: oss-crs + name: OSS-CRS + kind: project + has_community_page: true + url: https://openssf.org/projects/oss-crs/ + sdlc_stages: [source] + supply_chain_actors: [software-producer] + cell_synopses: + - stage: source + actor: software-producer + status: needs-review + text: OSS-CRS uses LLM-based reasoning to find and propose fixes for bugs in open source code, operating directly on the producer's source repository. + note: Sandbox-stage project; framing is in flux as the framework matures. + categories: [specification] +- id: osv-openvex + name: OpenVEX + kind: project + has_community_page: true + url: https://openssf.org/projects/openvex/ + sdlc_stages: [consumer, dependencies] + supply_chain_actors: [software-consumer, software-distributor, software-producer] + cell_synopses: + - stage: dependencies + actor: software-consumer + status: confirmed + text: Standardises the format of vulnerability data so consumers can ingest advisories from multiple databases (OSV.dev, GHSA, distro feeds) into a single deduplicated view over their dependencies. + - stage: dependencies + actor: software-distributor + status: confirmed + text: Package registries (npm, PyPI, distros) publish vulnerability information in OSV format so downstream consumers can consume it without per-source adapters. + - stage: dependencies + actor: software-producer + status: needs-review + text: Producers publish OSV records (often via their security advisory in the source repo) so downstream consumers see a vulnerability in a standard shape. + note: Producer-side publishing is a real flow; confirm specific upstream framing. + categories: [data-source, specification] +- id: osv-record + name: OSV Record (vulnerability record format) + kind: artifact + has_community_page: true + url: https://ossf.github.io/osv-schema/ + sdlc_stages: [dependencies] + supply_chain_actors: [software-consumer] + relationships: + - target: osv-openvex + kind: extends + status: confirmed + note: The artifact (the record format itself) is the concrete instance of what the OSV Schema project specifies. + categories: [data-source, specification] +- id: package-analysis + name: Package Analysis + kind: project + has_community_page: true + url: https://openssf.org/projects/package-analysis/ + sdlc_stages: [dependencies, distribution] + supply_chain_actors: [software-consumer, software-distributor] + cell_synopses: + - stage: dependencies + actor: software-consumer + status: confirmed + text: Consumers see fewer compromised dependencies in their graphs because Package Analysis flags malicious behaviour at upstream registries. + - stage: dependencies + actor: software-distributor + status: confirmed + text: Targets dependency-confusion and typosquat attacks at the distribution layer — vectors that exploit the dependency-resolution flow rather than the package itself. + - stage: distribution + actor: software-consumer + status: confirmed + text: 'Consumers benefit indirectly: a registry that runs Package Analysis catches malicious packages before they reach the consumer''s install step.' + - stage: distribution + actor: software-distributor + status: confirmed + text: Runs static and dynamic analysis on packages newly published to a registry, so the registry can detect malicious behaviour (network exfiltration, credential theft, backdoors) before consumers + download them. + categories: [data-source, tooling] +- id: protobom + name: Protobom + kind: project + has_community_page: true + url: https://openssf.org/projects/protobom/ + sdlc_stages: [build, distribution] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: build + actor: software-consumer + status: confirmed + text: Consumers that build derived artefacts (final binaries, container images) emit their own SBOMs at build time via the same library. + - stage: build + actor: software-producer + status: confirmed + text: Producers generate SBOMs via Protobom-backed tools as part of the build, getting format-agnostic SBOM emission (CycloneDX, SPDX) from one library. + - stage: distribution + actor: software-consumer + status: needs-review + text: Distributors and consumers read those SBOMs via Protobom on receipt, decoupling the consumer's tooling from the producer's chosen format. + note: Same caveat as the producer × distribution cell. + - stage: distribution + actor: software-producer + status: needs-review + text: Producers' build-time SBOMs are attached to the artefact and travel through distribution channels. + note: Distribution-stage tag is a flow observation, not Protobom's stated central scope. + categories: [specification, tooling] +- id: rstuf + name: Repository Service for TUF + kind: project + has_community_page: true + url: https://openssf.org/projects/repository-service-for-tuf/ + sdlc_stages: [distribution] + supply_chain_actors: [software-consumer, software-distributor] + cell_synopses: + - stage: distribution + actor: software-consumer + status: confirmed + text: Consumers' TUF clients verify RSTUF metadata before accepting an artefact, defending against compromised registries and downgrade attacks. + - stage: distribution + actor: software-distributor + status: confirmed + text: Registries and mirrors run RSTUF to add TUF-style signed metadata over the artefacts they serve, so downstream clients can detect tampering between the registry and themselves. + categories: [tooling] +- id: sarif + name: SARIF + kind: artifact + has_community_page: true + url: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html + sdlc_stages: [source] + supply_chain_actors: [software-producer] + categories: [specification] +- id: sbom + name: Software Bill of Materials + kind: artifact + has_community_page: true + url: https://www.cisa.gov/sbom + sdlc_stages: [consumer, distribution] + supply_chain_actors: [software-consumer, software-distributor] + categories: [specification] +- id: sbomit + name: SBOMit + kind: project + has_community_page: true + url: https://openssf.org/projects/sbomit/ + sdlc_stages: [build, distribution] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: build + actor: software-consumer + status: confirmed + text: Consumers building their own artefacts on top of SBOMit-using producers inherit the same attestation flow. + - stage: build + actor: software-producer + status: confirmed + text: Producers integrate SBOMit into the build pipeline to attest the components observed at build time (per the in-toto attestation model), tying the SBOM cryptographically to what the build actually + consumed. + - stage: distribution + actor: software-consumer + status: needs-review + text: Consumers receive the attested SBOM via the distribution channel and verify it before trusting the dependency list. + note: Same caveat as producer × distribution. + - stage: distribution + actor: software-producer + status: needs-review + text: Producers' attested SBOMs ride with the artefact through distribution channels, so consumers receive both the SBOM and the attestation that ties it to the build. + note: Distribution-stage tag is a flow observation; framing depends on whether the attestation is detached or inline. + categories: [tooling] +- id: secure-agentic-framework + name: Secure Agentic Framework + kind: project + has_community_page: true + url: https://docs.google.com/document/d/1OxjsWHO2v8SfzG4KkqyJEAy8yn1GA1yjgN7QCm6q85Q/edit + sdlc_stages: [producer] + supply_chain_actors: [other, software-producer] + cell_synopses: + - stage: producer + actor: other + status: needs-review + text: 'Provisional: AI safety and governance teams may use the framework as a policy/audit surface.' + note: Formation-stage project; upstream documentation not yet available. + - stage: producer + actor: software-producer + status: needs-review + text: 'Provisional: agentic-AI security tooling typically targets producers integrating AI agents into developer workflows. Awaiting public docs to refine.' + note: Formation-stage project; upstream documentation not yet available. + categories: [framework] +- id: securing-critical-projects-wg + name: Securing Critical Projects + kind: working-group + has_community_page: false + url: https://github.com/ossf/tac + sdlc_stages: [producer] + supply_chain_actors: [other, software-producer] + cell_synopses: + - stage: producer + actor: other + status: needs-review + text: Worked with funders and policy bodies (Alpha-Omega, governments) to direct support toward critical-project producers. + note: Archived WG; placement is historical context. + - stage: producer + actor: software-producer + status: needs-review + text: Historically supported producer-side hardening for the most critical OSS dependencies — funding, audits, maintainer support. Now archived; concerns absorbed by other WGs. + note: Archived WG; placement is historical context. + categories: [governance] +- id: securing-software-repositories + name: Securing Software Repositories + kind: working-group + has_community_page: false + url: https://openssf.org/community/openssf-working-groups/ + sdlc_stages: [distribution, source] + supply_chain_actors: [software-distributor, software-producer] + cell_synopses: + - stage: distribution + actor: software-distributor + status: confirmed + text: 'Directly works with registry operators (npm, PyPI, RubyGems, distros) on the controls they implement: 2FA, signing acceptance, dependency-confusion defences.' + - stage: distribution + actor: software-producer + status: needs-review + text: 'Producers benefit from registry-side controls: their published packages live in a more defended distribution channel.' + note: Producer-side benefit is indirect; framing is downstream of the WG's distributor focus. + - stage: source + actor: software-distributor + status: confirmed + text: Source-forge operators (GitHub, GitLab, Codeberg) participate in the WG when source-side repository security is the locus. + - stage: source + actor: software-producer + status: needs-review + text: Producers see source-forge improvements (e.g., signed commits, ref protection) emerge from WG-led work. + note: Producer-side benefit is downstream of the source-forge focus. + categories: [governance] +- id: security-insights + name: Security Insights + kind: project + has_community_page: true + url: https://openssf.org/projects/security-insights/ + sdlc_stages: [source] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: source + actor: software-consumer + status: confirmed + text: Consumers (and downstream tooling like Scorecard) read Security Insights to evaluate a producer's security posture without manually scanning the repo for clues. + - stage: source + actor: software-producer + status: confirmed + text: Producers publish a `SECURITY-INSIGHTS.yml` file in their source repository declaring contact points, response SLAs, signing policy, and dependency-management practices in a machine-readable form. + categories: [specification] +- id: security-tooling + name: Security Tooling + kind: working-group + has_community_page: false + url: https://openssf.org/community/openssf-working-groups/ + sdlc_stages: [build, source] + supply_chain_actors: [software-producer] + cell_synopses: + - stage: build + actor: software-producer + status: confirmed + text: Build-stage security tooling — fuzzing, SBOM generation, attestation flows, build-time SBOM (SBOMit, Protobom) — sits under this WG's umbrella. + - stage: source + actor: software-producer + status: confirmed + text: 'Coordinates source-layer security tooling targeted at OSS producers: GUAC, Scorecard, Bomctl, Protobom, fuzzing, SBOM tooling. Records under this WG generally appear in the source or build column.' + categories: [governance, tooling] +- id: sigstore + name: Sigstore + kind: project + has_community_page: true + url: https://openssf.org/projects/sigstore/ + sdlc_stages: [build, consumer, distribution] + supply_chain_actors: [software-consumer, software-distributor, software-producer] + cell_synopses: + - stage: build + actor: software-consumer + status: needs-review + text: Some consumers run reproducer builds to cross-check Sigstore-signed artefacts; this is a niche flow. + note: Not the central consumer-facing pattern; confirm if this should be tagged at all. + - stage: build + actor: software-distributor + status: needs-review + text: Distributors with their own CI may operate Sigstore infrastructure to sign artefacts they republish. + note: Distributor-side adoption pattern; confirm whether registries operate Sigstore in their own build path. + - stage: build + actor: software-producer + status: confirmed + text: Cosign and Fulcio let producers sign artefacts at build time with short-lived, identity-bound certificates, replacing the long-lived signing keys traditional CI/CD pipelines need to manage. + - stage: consumer + actor: software-consumer + status: confirmed + text: Cosign verify (or any Sigstore-compatible verifier) lets consumers prove an artefact's identity at install time without trusting the registry alone. + - stage: consumer + actor: software-distributor + status: needs-review + text: Some distributors verify signatures as part of admission control before serving downloads. + note: Distributor-side verification pattern; confirm scope. + - stage: consumer + actor: software-producer + status: needs-review + text: Producers occasionally verify their own published artefacts during release rehearsal. + note: Tangential to producer focus; confirm whether to tag. + - stage: distribution + actor: software-consumer + status: confirmed + text: Consumers receive Sigstore signatures alongside the artefact and can verify them before extraction or install. + - stage: distribution + actor: software-distributor + status: confirmed + text: Registries (npm, PyPI, container registries) verify Sigstore signatures and surface them to consumers, integrating signed-provenance flows into the distribution layer itself. + - stage: distribution + actor: software-producer + status: confirmed + text: Producers' Sigstore signatures (and Rekor inclusion proofs) ride with their artefacts through registries, so the signed claim survives intermediate hops in the distribution chain. + categories: [framework, service] +- id: slsa + name: SLSA + kind: project + has_community_page: true + url: https://openssf.org/projects/slsa/ + sdlc_stages: [build, distribution] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: build + actor: software-consumer + status: confirmed + text: Consumers verify SLSA provenance against expectations (expected source, expected builder, expected parameters) to detect tampering between the build and the artefact they install. + - stage: build + actor: software-producer + status: confirmed + text: Build levels L1–L3 mandate that producers generate signed build provenance (typically in-toto attestations) capturing the source, build platform, and build inputs that produced each artefact. + - stage: distribution + actor: software-consumer + status: needs-review + text: Consumers fetch the provenance alongside the artefact from the distribution channel and chain it back to the build. + note: Distribution-stage role for consumers is implicit; confirm framing with upstream. + - stage: distribution + actor: software-producer + status: needs-review + text: Producers ensure provenance travels with the artefact through their distribution channels (registries, mirrors) so the consumer-side verification step can find it. + note: Distribution-stage role is implicit in SLSA Build L1+ but not framed as a separate producer obligation by the spec. + relationships: + - target: slsa-provenance + kind: produces + status: confirmed + note: Conforming SLSA build-track implementations emit signed SLSA Provenance for every artefact they produce. + categories: [best-practices, specification] +- id: slsa-github-generator + name: slsa-github-generator + kind: project + has_community_page: true + url: https://github.com/slsa-framework/slsa-github-generator + sdlc_stages: [build] + supply_chain_actors: [software-producer] + relationships: + - target: slsa + kind: implements + status: confirmed + - target: slsa-provenance + kind: produces + status: confirmed + categories: [tooling] +- id: slsa-provenance + name: SLSA Provenance + kind: artifact + has_community_page: true + url: https://slsa.dev/spec/v1.0/provenance + sdlc_stages: [build] + supply_chain_actors: [software-producer] + categories: [specification] +- id: slsa-verifier + name: slsa-verifier + kind: project + has_community_page: true + url: https://github.com/slsa-framework/slsa-verifier + sdlc_stages: [build, distribution] + supply_chain_actors: [software-consumer, software-producer] + relationships: + - target: slsa-provenance + kind: consumes + status: confirmed + - target: slsa + kind: implements + status: confirmed + categories: [tooling] +- id: supply-chain-integrity + name: Supply Chain Integrity + kind: working-group + has_community_page: false + url: https://openssf.org/community/openssf-working-groups/ + sdlc_stages: [build, consumer, distribution] + supply_chain_actors: [software-consumer, software-producer] + cell_synopses: + - stage: build + actor: software-consumer + status: confirmed + text: Consumers ingest the build-stage provenance the WG's projects emit, completing the verification loop SLSA defines. + - stage: build + actor: software-producer + status: confirmed + text: Stewards SLSA, GUAC, gittuf, Zarf, S2C2F — producer-side controls that bind builds to verifiable provenance and source. + - stage: consumer + actor: software-consumer + status: needs-review + text: Consumers verify provenance at install or use time before trusting the artefact. + note: Consumer-stage tag is a flow observation; confirm framing. + - stage: consumer + actor: software-producer + status: needs-review + text: Producers re-verify provenance during release rehearsals. + note: Consumer-stage tag is a flow observation; confirm scope. + - stage: distribution + actor: software-consumer + status: confirmed + text: Consumers fetch provenance via distribution channels and verify it before install. + - stage: distribution + actor: software-producer + status: confirmed + text: Provenance and attestations have to travel through distribution channels; the WG's work covers that handoff. + categories: [governance] +- id: tac + name: OpenSSF Technical Advisory Council + kind: working-group + has_community_page: false + url: https://openssf.org/about/tac/ + sdlc_stages: [producer] + supply_chain_actors: [other] + cell_synopses: + - stage: producer + actor: other + status: confirmed + text: 'Provides technical oversight for the OpenSSF as a whole: project lifecycle approval, working-group charters, technical funding allocation, conflict resolution.' + categories: [governance] +- id: vex + name: Vulnerability Exploitability eXchange + kind: artifact + has_community_page: true + url: https://www.cisa.gov/resources-tools/resources/vulnerability-exploitability-exchange-vex-use-cases + sdlc_stages: [consumer] + supply_chain_actors: [software-consumer] + categories: [specification] +- id: vulnerability-disclosures + name: Vulnerability Disclosures + kind: working-group + has_community_page: false + url: https://openssf.org/community/openssf-working-groups/ + sdlc_stages: [dependencies] + supply_chain_actors: [software-consumer, software-distributor, software-producer] + cell_synopses: + - stage: dependencies + actor: software-consumer + status: confirmed + text: Consumers ingest WG-stewarded vulnerability formats (OSV, OpenVEX) to triage their dependency graph against the latest disclosures. + - stage: dependencies + actor: software-distributor + status: confirmed + text: Distributors propagate vulnerability metadata via OSV-formatted feeds, security advisories on their platforms, and triage flows. + - stage: dependencies + actor: software-producer + status: confirmed + text: Producers issue vulnerability data (CVE, GHSA, OSV) about their own software via WG-coordinated standards. The WG also stewards CVD Guides for the disclosure process itself. + categories: [governance] +- id: zarf + name: Zarf + kind: project + has_community_page: true + url: https://openssf.org/projects/zarf/ + sdlc_stages: [consumer, distribution] + supply_chain_actors: [software-consumer, software-distributor] + cell_synopses: + - stage: consumer + actor: software-consumer + status: confirmed + text: Operators in air-gapped or constrained environments deploy Zarf bundles into their local cluster, completing the supply chain without ever fetching from the public network. + - stage: consumer + actor: software-distributor + status: needs-review + text: Some distributors operate Zarf as a packaging/repackaging layer between upstream and their downstream consumers. + note: Distributor-side adoption pattern; confirm scope. + - stage: distribution + actor: software-consumer + status: needs-review + text: Consumers receive Zarf bundles and use them to seed their own local registry, decoupling the consumer from continuous upstream connectivity. + note: Consumer-side use is the dominant scenario; flagged needs-review because the distribution-stage tagging is fluid. + - stage: distribution + actor: software-distributor + status: confirmed + text: Bundles applications, their dependencies, and registry content into a single portable package that can be delivered to air-gapped or disconnected environments. Reshapes the distribution channel + around the bundle. + categories: [tooling] diff --git a/_data/artifacts.yml b/_data/artifacts.yml new file mode 100644 index 0000000..5f18f88 --- /dev/null +++ b/_data/artifacts.yml @@ -0,0 +1,61 @@ +# OpenSSF output formats (SLSA Provenance, SBOM, VEX, ...). Each +# entry maps to /artifacts//. Imported from sibling research catalog. + +- id: in-toto-attestation + name: "in-toto Attestation" + url: https://github.com/in-toto/attestation + description: >- + The signed-envelope format that SLSA Provenance and other supply-chain attestations ship in. Defines the predicate/statement structure and signature wrapper used by every conforming attestation. + sdlc_stages: [] + supply_chain_actors: [] + categories: ["specification"] + +- id: osv-record + name: "OSV Record (vulnerability record format)" + aliases: ["OSV Record"] + url: https://ossf.github.io/osv-schema/ + description: >- + The serialised vulnerability-record format produced by OSV-aligned databases (osv.dev, 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… + sdlc_stages: ["dependencies"] + supply_chain_actors: ["software-consumer"] + categories: ["data-source", "specification"] + +- id: sarif + name: "SARIF" + aliases: ["Static Analysis Results Interchange Format"] + url: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html + description: >- + An OASIS standard JSON format for representing static analysis tool results. Consumed by code-scanning UIs (e.g. GitHub Code Scanning) and produced by linters, scanners, and policy tools such as Scorecard. + sdlc_stages: ["source"] + supply_chain_actors: ["software-producer"] + categories: ["specification"] + +- id: sbom + name: "Software Bill of Materials" + aliases: ["SBOM"] + url: https://www.cisa.gov/sbom + description: >- + A machine-readable inventory of the components contained in a software artifact. Multiple authoritative formats exist (CycloneDX, SPDX); this record models the SBOM concept itself rather than any single format. + sdlc_stages: ["consumer", "distribution"] + supply_chain_actors: ["software-consumer", "software-distributor"] + categories: ["specification"] + +- id: slsa-provenance + name: "SLSA Provenance" + url: https://slsa.dev/spec/v1.0/provenance + description: >- + Cryptographically attested record of how a software artifact was built, including the build platform identity, source revision, build parameters, and the resulting artifact digest. + sdlc_stages: ["build"] + supply_chain_actors: ["software-producer"] + categories: ["specification"] + +- id: vex + name: "Vulnerability Exploitability eXchange" + aliases: ["VEX"] + url: https://www.cisa.gov/resources-tools/resources/vulnerability-exploitability-exchange-vex-use-cases + description: >- + 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 signal. + sdlc_stages: ["consumer"] + supply_chain_actors: ["software-consumer"] + categories: ["specification"] + diff --git a/_data/categories.yml b/_data/categories.yml new file mode 100644 index 0000000..323c082 --- /dev/null +++ b/_data/categories.yml @@ -0,0 +1,42 @@ +# Category enum (mirrors feature 005's 8-value enum). + +- id: specification + name: "Specification" + description: >- + A normative document defining an interface, format, or process. + +- id: tooling + name: "Tooling" + description: >- + An executable tool, library, or CLI that does work for a user. + +- id: best-practices + name: "Best Practices" + description: >- + Curated guidance and frameworks for adoption (not a normative spec). + +- id: framework + name: "Framework" + description: >- + A coordinated bundle of guidance, tooling, and processes — broader than a single spec. + +- id: service + name: "Service" + description: >- + A hosted offering — connect to rather than install. + +- id: data-source + name: "Data Source" + description: >- + A maintained dataset other tooling consumes. + +- id: education + name: "Education" + description: >- + Materials whose primary product is human learning. + +- id: governance + name: "Governance" + description: >- + Cross-cutting governance, risk, compliance, advocacy, or policy work. + diff --git a/_data/navigation.yml b/_data/navigation.yml index 118903c..f34ea35 100644 --- a/_data/navigation.yml +++ b/_data/navigation.yml @@ -6,5 +6,9 @@ url: /problems/ - title: Projects url: /projects/ +- title: Artifacts + url: /artifacts/ +- title: Architecture + url: /architecture/ - title: About url: /about/ diff --git a/_data/projects.yml b/_data/projects.yml index aceb8bf..17817f8 100644 --- a/_data/projects.yml +++ b/_data/projects.yml @@ -525,3 +525,118 @@ - sigstore compatible_with: - rstuf +# Append these to community/_data/projects.yml. +# Imported from sibling research catalog 2026-06-28. + +- id: bomctl + name: "Bomctl" + url: https://openssf.org/projects/bomctl/ + description: >- + Bridges the gap between SBOM generation tools and SBOM analysis/consumption tools, providing format-aware SBOM manipulation. + personas: [] + problems: [] + +- id: fuzz-introspector + name: "Fuzz Introspector" + url: https://openssf.org/projects/fuzz-introspector/ + description: >- + Improves the fuzzing experience for projects by providing visibility into fuzzer coverage and reachability. + personas: [] + problems: [] + +- id: fuzzingbrain + name: "FuzzingBrain" + url: https://docs.google.com/document/d/1OxjsWHO2v8SfzG4KkqyJEAy8yn1GA1yjgN7QCm6q85Q/edit + description: >- + An OSSF project approved by the TAC and currently in LF legal formation; public documentation is not yet available, so scope and classification are provisional. + personas: [] + problems: [] + +- id: gemara + name: "Gemara" + url: https://openssf.org/projects/gemara/ + description: >- + Models categorical layers of automated governance activities, providing a framework for expressing security and compliance controls in a machine-readable way. + personas: [] + problems: [] + +- id: gittuf + name: "gittuf" + url: https://openssf.org/projects/gittuf/ + description: >- + Applies TUF-style signing and metadata to Git repositories to protect repository contents from unauthorized or malicious changes. + personas: [] + problems: [] + +- id: in-toto + name: "in-toto" + url: https://in-toto.io/ + description: >- + A framework for cryptographically attesting supply-chain steps. Defines the in-toto attestation envelope that SLSA Provenance and other signed-statement formats ship in. + personas: [] + problems: [] + +- id: openssf-model-signing + name: "OpenSSF Model Signing" + url: https://openssf.org/projects/model-signing/ + description: >- + Provides a library and CLI for signing and verifying machine-learning models, extending supply-chain integrity practices to AI artifacts. + personas: [] + problems: [] + +- id: oss-crs + name: "OSS-CRS" + url: https://openssf.org/projects/oss-crs/ + description: >- + A framework for LLM-based bug-finding and bug-fixing systems applied to open source software, exploring autonomous vulnerability discovery and remediation. + personas: [] + problems: [] + +- id: package-analysis + name: "Package Analysis" + 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. + personas: [] + problems: [] + +- id: sbomit + name: "SBOMit" + url: https://openssf.org/projects/sbomit/ + description: >- + A format-independent component-attestation method that ties SBOM contents to verifiable build-time observations, improving SBOM trustworthiness. + personas: [] + problems: [] + +- id: secure-agentic-framework + name: "Secure Agentic Framework" + url: https://docs.google.com/document/d/1OxjsWHO2v8SfzG4KkqyJEAy8yn1GA1yjgN7QCm6q85Q/edit + description: >- + An OSSF project approved by the TAC and currently in LF legal formation; public documentation is not yet available, so scope and classification are provisional. + personas: [] + problems: [] + +- id: slsa-github-generator + name: "slsa-github-generator" + url: https://github.com/slsa-framework/slsa-github-generator + description: >- + Reference implementations of SLSA Level 3 build provenance generators for GitHub Actions. Produces signed in-toto attestations bound to the builder identity per the SLSA build track. + personas: [] + problems: [] + +- id: slsa-verifier + name: "slsa-verifier" + url: https://github.com/slsa-framework/slsa-verifier + description: >- + Reference implementation of the SLSA Provenance verifier. Consumes signed in-toto attestations, validates the builder identity, and enforces SLSA build-level expectations on incoming artefacts. + personas: [] + problems: [] + +- id: zarf + name: "Zarf" + url: https://openssf.org/projects/zarf/ + description: >- + Enables continuous software delivery onto air-gapped, disconnected, or otherwise constrained systems by bundling applications and their dependencies into portable packages. + personas: [] + problems: [] + diff --git a/_data/sdlc_stages.yml b/_data/sdlc_stages.yml new file mode 100644 index 0000000..123ae5f --- /dev/null +++ b/_data/sdlc_stages.yml @@ -0,0 +1,33 @@ +# Canonical SDLC stage enum (matches the SLSA stage taxonomy with a +# producer prefix for the engineer's workstation). + +- id: producer + name: Producer + description: >- + The engineer and their workstation — local tooling, dev environment, identity hygiene. + +- id: source + name: Source + description: >- + The source repository and the SCM platform that hosts it. + +- id: build + name: Build + description: >- + The CI/CD platform and the project's build configuration. + +- id: distribution + name: Distribution + description: >- + The artifact registry and the project's published artefacts. + +- id: consumer + name: Consumer + description: >- + The end-user environment and the project as it runs downstream. + +- id: dependencies + name: Dependencies + description: >- + The recursive supply-chain loop — every consumer is also a producer. + diff --git a/_data/sidebar.yml b/_data/sidebar.yml index 81eb7a3..ff8348b 100644 --- a/_data/sidebar.yml +++ b/_data/sidebar.yml @@ -74,5 +74,67 @@ url: /projects/sigstore/ - title: SLSA url: /projects/slsa/ + - title: bomctl + url: /projects/bomctl/ + - title: Fuzz Introspector + url: /projects/fuzz-introspector/ + - title: FuzzingBrain + url: /projects/fuzzingbrain/ + - title: Gemara + url: /projects/gemara/ + - title: gittuf + url: /projects/gittuf/ + - title: in-toto + url: /projects/in-toto/ + - title: OpenSSF Model Signing + url: /projects/openssf-model-signing/ + - title: OSS-CRS + url: /projects/oss-crs/ + - title: Package Analysis + url: /projects/package-analysis/ + - title: SBOMit + url: /projects/sbomit/ + - title: Secure Agentic Framework + url: /projects/secure-agentic-framework/ + - title: slsa-github-generator + url: /projects/slsa-github-generator/ + - title: slsa-verifier + url: /projects/slsa-verifier/ + - title: Zarf + url: /projects/zarf/ +- title: Browse by Artifact + url: /artifacts/ + children: + - title: in-toto Attestation + url: /artifacts/in-toto-attestation/ + - title: OSV Record + url: /artifacts/osv-record/ + - title: SARIF + url: /artifacts/sarif/ + - title: SBOM (Software Bill of Materials) + url: /artifacts/sbom/ + - title: SLSA Provenance + url: /artifacts/slsa-provenance/ + - title: VEX (Vulnerability Exploitability eXchange) + url: /artifacts/vex/ +- title: Browse by Architecture View + url: /architecture/ + children: + - title: SLSA v1.2 Threats × OSSF Coverage + url: /architecture/slsa-threats/ + - title: Secure Production (producer pillar) + url: /architecture/secure-production/ + - title: Secure Distribution (distributor pillar) + url: /architecture/secure-distribution/ + - title: Secure Consumption (consumer pillar) + url: /architecture/secure-consumption/ + - title: Stewardship (other / governance pillar) + url: /architecture/stewardship/ + - title: Overview — full catalog + url: /architecture/overview/ + - title: TAC summary + url: /architecture/tac-summary/ + - title: Architecture gaps + url: /architecture/gaps/ - title: About url: /about/ diff --git a/_data/supply_chain_actors.yml b/_data/supply_chain_actors.yml new file mode 100644 index 0000000..969d7d6 --- /dev/null +++ b/_data/supply_chain_actors.yml @@ -0,0 +1,24 @@ +# Canonical supply-chain actor enum. Distinct from the existing +# `personas` list (which is end-user-role-based); these are +# supply-chain position-based. + +- id: software-producer + name: "Software Producer" + description: >- + Maintainers, contributors — the humans and orgs producing software. + +- id: software-distributor + name: "Software Distributor" + description: >- + Package forges, source forges, registries — the systems that move software. + +- id: software-consumer + name: "Software Consumer" + description: >- + Manufacturers, end users — the humans and orgs that depend on software produced by others. + +- id: other + name: "Other (Governance / Risk / Compliance / Policy)" + description: >- + Cross-cutting governance, advocacy, policy, and compliance work. + diff --git a/_data/threat_categories.yml b/_data/threat_categories.yml new file mode 100644 index 0000000..269fb16 --- /dev/null +++ b/_data/threat_categories.yml @@ -0,0 +1,26 @@ +# SLSA v1.2 threat category headers. + +- letter: A + name: "Producer" +- letter: B + name: "Modifying the Source" +- letter: C + name: "Source Code Management" +- letter: D + name: "External Build Parameters" +- letter: E + name: "Build Process" +- letter: F + name: "Artifact Publication" +- letter: G + name: "Distribution Channel" +- letter: H + name: "Package Selection" +- letter: I + name: "Usage" +- letter: J + name: "Dependencies" +- letter: K + name: "Availability" +- letter: L + name: "Verification" diff --git a/_data/threats.yml b/_data/threats.yml new file mode 100644 index 0000000..bf59e86 --- /dev/null +++ b/_data/threats.yml @@ -0,0 +1,461 @@ +# SLSA v1.2 supply-chain threats taxonomy. Mitigations[] reference +# community project slugs. Imported 2026-06-28 from data/threat-mappings/. + +- id: slsa-v1-2-a1 + code: A1 + category_letter: A + label: "Software producer intentionally creates malicious revision" + description: "A producer deliberately creates harmful code targeting consumers. SLSA does not address this directly; the trust basis comes from open source community governance and organizational incentives." + mitigations: + - ref: best-practices-wg + status: needs-review + note: "OSSF Best Practices WG addresses producer trustworthiness indirectly through community-level guidance, but no direct technical control exists upstream." + - ref: best-practices-badge + status: needs-review + note: "Badge criteria signal a producer's commitment to vetted practices, which contributes to the trust basis SLSA references for this threat." +- id: slsa-v1-2-b1 + code: B1 + category_letter: B + label: "Submit change without review" + description: "Malicious code pushed directly to the source repository, bypassing approval processes. SLSA Source L4 mitigates by requiring two-party approval before acceptance." + mitigations: + - ref: openssf-scorecard + status: confirmed + - ref: slsa + status: confirmed + - ref: osps-baseline + status: needs-review + note: "OSPS Baseline includes review-related criteria; confirm whether they fully cover B1." +- id: slsa-v1-2-b2 + code: B2 + category_letter: B + label: "Single actor controls multiple accounts" + description: "One person uses multiple accounts to self-approve code changes, defeating two-party review." + mitigations: + - ref: openssf-scorecard + status: needs-review + note: "Scorecard does not currently detect multi-account control; the threat is identified but not automatically caught." +- id: slsa-v1-2-b3 + code: B3 + category_letter: B + label: "Use robot account to submit change" + description: "Exploit automated accounts with change submission privileges to push unreviewed code." + mitigations: + - ref: openssf-scorecard + status: confirmed +- id: slsa-v1-2-b4 + code: B4 + category_letter: B + label: "Abuse of rule exceptions" + description: "Circumvent policies through poorly defined exception clauses (e.g., branch protection bypass lists)." + mitigations: + - ref: minder + status: needs-review + note: "Minder enforces policies that could narrow rule exceptions; confirm whether existing rulesets cover this." +- id: slsa-v1-2-b5 + code: B5 + category_letter: B + label: "Highly-permissioned actor bypasses controls" + description: "Admin users disable protections to push unauthorized changes." + mitigations: [] +- id: slsa-v1-2-b6 + code: B6 + category_letter: B + label: "Alter change history" + description: "Force-push or rewrite commits to hide malicious activity. SLSA Source L2+ mitigates by preventing branch history alteration." + mitigations: + - ref: gittuf + status: confirmed + - ref: openssf-scorecard + status: confirmed +- id: slsa-v1-2-b7 + code: B7 + category_letter: B + label: "Replace tagged content with malicious content" + description: "Reassign release tags to point at compromised code. SLSA Source L2+ mitigates by protecting tags from being updated." + mitigations: + - ref: gittuf + status: confirmed +- id: slsa-v1-2-b8 + code: B8 + category_letter: B + label: "Skip required checks" + description: "Submit code without following documented development processes. SLSA Source L3+ mitigates by enforcing process via technical controls." + mitigations: + - ref: openssf-scorecard + status: needs-review + note: "Scorecard checks for required-status-checks settings; confirm coverage matches SLSA Source L3+." + - ref: osps-baseline + status: needs-review + note: "OSPS Baseline includes process-enforcement criteria; confirm coverage." +- id: slsa-v1-2-b9 + code: B9 + category_letter: B + label: "Modify code after review" + description: "Alter change contents after peer approval but before submission. SLSA Source L4 mitigates by invalidating approvals when changes are modified." + mitigations: + - ref: gittuf + status: confirmed +- id: slsa-v1-2-b10 + code: B10 + category_letter: B + label: "Submit unreviewable change" + description: "Craft changes appearing benign to reviewers but containing hidden malice. SLSA Source L4 requires review systems present intelligible representations." + mitigations: [] +- id: slsa-v1-2-b11 + code: B11 + category_letter: B + label: "Copy reviewed change to another context" + description: "Get approval in one environment, then apply in different context." + mitigations: [] +- id: slsa-v1-2-b12 + code: B12 + category_letter: B + label: "Commit graph attacks" + description: "Include malicious commits alongside reversing commits to obscure intent." + mitigations: + - ref: gittuf + status: needs-review + note: "gittuf's signed commit history makes graph manipulation auditable; confirm whether it detects this attack pattern specifically." +- id: slsa-v1-2-b13 + code: B13 + category_letter: B + label: "Collude with another trusted person" + description: "Two authorized reviewers work together to approve bad changes." + mitigations: [] +- id: slsa-v1-2-b14 + code: B14 + category_letter: B + label: "Trick reviewer into approving bad code" + description: "Construct deceptive changes (\"bugdoor\") that pass human review. Not currently addressed by SLSA." + mitigations: [] +- id: slsa-v1-2-b15 + code: B15 + category_letter: B + label: "Reviewer blindly approves changes" + description: "Approver rubber-stamps changes without substantive review. Not currently addressed by SLSA." + mitigations: [] +- id: slsa-v1-2-b16 + code: B16 + category_letter: B + label: "Forge change metadata" + description: "Misrepresent authorship, timestamp, or discoverability of a change. SLSA Source L2+ attributes changes only to authenticated identities." + mitigations: + - ref: gittuf + status: confirmed +- id: slsa-v1-2-c1 + code: C1 + category_letter: C + label: "Platform admin abuses privileges" + description: "Infrastructure administrator exploits access to bypass controls." + mitigations: [] +- id: slsa-v1-2-c2 + code: C2 + category_letter: C + label: "Exploit vulnerability in SCM" + description: "Leverage implementation flaws in source control system. Not currently addressed by SLSA." + mitigations: [] +- id: slsa-v1-2-d1 + code: D1 + category_letter: D + label: "Build from unofficial fork of code" + description: "Build using the expected process but from an unauthorized repository copy. Mitigated by verifying provenance source location matches expectations." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-d2 + code: D2 + category_letter: D + label: "Build from unofficial branch or tag" + description: "Checkout experimental or unprotected branches for release. Mitigated by verifying source revision reachability." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-d3 + code: D3 + category_letter: D + label: "Build from unofficial build steps" + description: "Execute custom build instructions outside official configuration. Mitigated by verifying build configuration source matches expected value." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-d4 + code: D4 + category_letter: D + label: "Build from unofficial parameters" + description: "Inject malicious behavior through build environment variables or flags. Mitigated by verifying all external parameters match expected values." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-d5 + code: D5 + category_letter: D + label: "Build from modified version after checkout" + description: "Build from local modifications not in the official repository. Mitigated when the build platform records the actual source repository in provenance." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-e1 + code: E1 + category_letter: E + label: "Forge provenance values" + description: "Generate false provenance and obtain a trusted platform signature. SLSA Build L2+ requires a trusted control plane generate provenance; L3+ hardens the control plane." + mitigations: + - ref: slsa + status: confirmed + - ref: sigstore + status: confirmed +- id: slsa-v1-2-e2 + code: E2 + category_letter: E + label: "Forge output digest of provenance" + description: "Set the artifact hash without platform verification of actual production. Not a security problem per the SLSA spec \u2014 provenance binds to whatever artifact carries the matching digest." + mitigations: [] +- id: slsa-v1-2-e3 + code: E3 + category_letter: E + label: "Compromise project owner" + description: "Gain project-owner permissions to influence the build or provenance. SLSA Build L2+ ensures the owner cannot influence the build process." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-e4 + code: E4 + category_letter: E + label: "Compromise other build" + description: "Run a malicious build affecting parallel or subsequent builds via shared infrastructure. SLSA Build L3 isolates builds from each other." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-e5 + code: E5 + category_letter: E + label: "Steal cryptographic secrets" + description: "Exfiltrate or misuse provenance signing keys. SLSA Build L3 isolates builds so only the control plane accesses secrets." + mitigations: + - ref: slsa + status: confirmed + - ref: sigstore + status: confirmed + - ref: open-bao + status: needs-review + note: "OpenBao manages secrets used by build pipelines; reduces the surface where keys can be stolen, but doesn't directly mitigate runtime compromise." +- id: slsa-v1-2-e6 + code: E6 + category_letter: E + label: "Poison the build cache" + description: "Inject malicious artifacts into a cache for reuse by benign builds. SLSA Build L3 isolates the cache and keys entries by transitive closure." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-e7 + code: E7 + category_letter: E + label: "Compromise build platform admin" + description: "Gain admin access to modify builds via debugging or SSH access. Mitigated by admin controls (two-person approvals, audit logging)." + mitigations: [] +- id: slsa-v1-2-f1 + code: F1 + category_letter: F + label: "Build with untrusted CI/CD" + description: "Use unofficial pipeline not meeting security standards. Mitigated by verifying the builder matches the expected value in provenance." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-f2 + code: F2 + category_letter: F + label: "Upload package without provenance" + description: "Publish artifact lacking cryptographic build attestation. SLSA Build L1 requires provenance before acceptance." + mitigations: + - ref: slsa + status: confirmed + - ref: sbomit + status: confirmed +- id: slsa-v1-2-f3 + code: F3 + category_letter: F + label: "Tamper with artifact after CI/CD" + description: "Modify benign artifact post-build, then re-upload with the original provenance. Mitigated by verifying the provenance subject hash matches the artifact." + mitigations: + - ref: slsa + status: confirmed + - ref: sigstore + status: confirmed +- id: slsa-v1-2-f4 + code: F4 + category_letter: F + label: "Tamper with provenance" + description: "Modify provenance metadata to pass expectations checks. SLSA Build L2 requires a valid cryptographic signature on provenance." + mitigations: + - ref: slsa + status: confirmed + - ref: sigstore + status: confirmed +- id: slsa-v1-2-g1 + code: G1 + category_letter: G + label: "Build with untrusted CI/CD (distribution)" + description: "Registry contains an artifact built on a non-compliant platform. Mitigated by verifying the builder or VSA matches expectations." + mitigations: + - ref: securing-software-repositories + status: needs-review + note: "Securing Software Repositories WG owns guidance for registries to enforce SLSA-aligned builder requirements; confirm specific recommendations." +- id: slsa-v1-2-g2 + code: G2 + category_letter: G + label: "Issue VSA from untrusted intermediary" + description: "An unauthorized entity issues a verification summary for a malicious package. Mitigated by verifying VSAs come from a trusted intermediary only." + mitigations: [] +- id: slsa-v1-2-g3 + code: G3 + category_letter: G + label: "Upload package without provenance or VSA" + description: "Package replaced without attestation in the registry. SLSA Build L1 requires provenance or a VSA before acceptance." + mitigations: + - ref: slsa + status: confirmed + - ref: rstuf + status: needs-review + note: "RSTUF can enforce attestation requirements at the repository layer; confirm exact policy hooks." +- id: slsa-v1-2-g4 + code: G4 + category_letter: G + label: "Replace package and VSA with another" + description: "Swap artifact and attestation, presenting a valid but mismatched VSA. Mitigated by verifying the VSA resourceUri matches the requested package." + mitigations: [] +- id: slsa-v1-2-g5 + code: G5 + category_letter: G + label: "Tamper with artifact after upload" + description: "Modify benign package post-publication while retaining attestation. SLSA Build L1 requires the subject hash match the served artifact." + mitigations: + - ref: slsa + status: confirmed + - ref: rstuf + status: confirmed +- id: slsa-v1-2-g6 + code: G6 + category_letter: G + label: "Tamper with provenance or VSA" + description: "Modify attestation to pass verification checks. SLSA Build L2 requires valid cryptographic signatures." + mitigations: + - ref: slsa + status: confirmed + - ref: sigstore + status: confirmed +- id: slsa-v1-2-h1 + code: H1 + category_letter: H + label: "Dependency confusion" + description: "Register a shadowing name in a public registry, misdirecting victim lookups. Mitigated by verifying internal package provenance against expectations." + mitigations: + - ref: package-analysis + status: confirmed + - ref: securing-software-repositories + status: needs-review + note: "Securing Software Repositories WG owns guidance against this attack class; confirm specific recommendations." +- id: slsa-v1-2-h2 + code: H2 + category_letter: H + label: "Typosquatting" + description: "Register a similar-looking package name to trick user installation. Not currently addressed directly by SLSA." + mitigations: + - ref: package-analysis + status: confirmed +- id: slsa-v1-2-i1 + code: I1 + category_letter: I + label: "Improper usage" + description: "Software used insecurely, enabling adversary compromise. Not addressed by SLSA; complemented by 'Secure by Design' practices." + mitigations: [] +- id: slsa-v1-2-j1 + code: J1 + category_letter: J + label: "Include vulnerable dependency" + description: "Statically bundle compromised library or base image in build output. Future SLSA Dependency track will address this; today, mitigated via vulnerability databases and SBOMs." + mitigations: + - ref: osv-openvex + status: confirmed + - ref: osv-openvex + status: confirmed + - ref: guac + status: confirmed + - ref: vulnerability-disclosures + status: confirmed +- id: slsa-v1-2-j2 + code: J2 + category_letter: J + label: "Use compromised build tool" + description: "Leverage a compromised compiler, utility, or OS package. Mitigated by recursively applying SLSA verification to build tooling." + mitigations: + - ref: slsa + status: confirmed + - ref: guac + status: needs-review + note: "GUAC can model build-tool provenance for analysis; confirm specific build-tool-tracking features." +- id: slsa-v1-2-j3 + code: J3 + category_letter: J + label: "Use compromised runtime dependency during build" + description: "Load a compromised runtime artifact during testing or linking. Mitigated by applying SLSA recursively and isolating tests from output artifacts." + mitigations: + - ref: slsa + status: confirmed +- id: slsa-v1-2-j4 + code: J4 + category_letter: J + label: "Use compromised dependency at runtime" + description: "Load a malicious artifact when the software executes. Not explicitly modeled by SLSA; each dependency is treated separately." + mitigations: + - ref: osv-openvex + status: confirmed + - ref: osv-openvex + status: confirmed + - ref: guac + status: confirmed + - ref: criticality-score + status: needs-review + note: "Criticality Score helps prioritize which runtime dependencies warrant the most monitoring." +- id: slsa-v1-2-k1 + code: K1 + category_letter: K + label: "Delete the code" + description: "Erase the source revision after the build, preventing inspection. Not currently addressed by SLSA." + mitigations: + - ref: gittuf + status: needs-review + note: "gittuf's signed history makes deletions auditable but does not prevent them at the platform layer." +- id: slsa-v1-2-k2 + code: K2 + category_letter: K + label: "Dependency becomes unavailable" + description: "Build cannot proceed due to missing transitive dependencies. Not currently addressed by SLSA." + mitigations: [] +- id: slsa-v1-2-k3 + code: K3 + category_letter: K + label: "De-list artifact" + description: "Package registry stops serving a published artifact. Not currently addressed by SLSA." + mitigations: + - ref: zarf + status: needs-review + note: "Zarf's air-gapped bundles preserve artifacts after registry de-listing for the consumer's local use; not a generalised mitigation." +- id: slsa-v1-2-k4 + code: K4 + category_letter: K + label: "De-list provenance" + description: "Package registry stops serving an attestation. Not currently addressed by SLSA." + mitigations: [] +- id: slsa-v1-2-l1 + code: L1 + category_letter: L + label: "Tamper with recorded expectations" + description: "Modify verifier's configuration to accept unauthorized artifacts. Mitigated by requiring two-party authorization for expectation changes." + mitigations: [] +- id: slsa-v1-2-l2 + code: L2 + category_letter: L + label: "Exploit cryptographic hash collisions" + description: "Leverage digest-algorithm weakness to substitute artifacts. Mitigated by using collision-resistant algorithms (SHA-256)." + mitigations: [] diff --git a/_includes/architecture-style.html b/_includes/architecture-style.html new file mode 100644 index 0000000..e79e18e --- /dev/null +++ b/_includes/architecture-style.html @@ -0,0 +1,690 @@ + diff --git a/_includes/pillar-grid.html b/_includes/pillar-grid.html new file mode 100644 index 0000000..3c22862 --- /dev/null +++ b/_includes/pillar-grid.html @@ -0,0 +1,73 @@ +{%- comment -%} + Pillar grid for /architecture/* pages. 6 columns (one per SDLC stage), + each listing the architecture_records whose sdlc_stages contains the + column's stage AND whose supply_chain_actors contains the actor + parameter passed to this include. + + Records with a matching cell_synopsis for the (stage, actor) cell + render as a
element — the summary holds the linked name, + the body holds the curated synopsis text + a needs-review badge when + applicable. Records without a synopsis render as plain hover-linked + text. + + Usage: + {% include pillar-grid.html actor="software-producer" %} +{%- endcomment -%} + +{% assign actor = include.actor %} +{% assign pillar_records = site.data.architecture_records | where_exp: "r", "r.supply_chain_actors contains actor" | sort: "id" %} + +
+ {% for stage in site.data.sdlc_stages %} + {% assign in_col = pillar_records | where_exp: "r", "r.sdlc_stages contains stage.id" %} +
+

{{ stage.name }}

+ {% if in_col.size == 0 %} +

(none)

+ {% else %} +
+ {% endif %} +
+ {% endfor %} +
diff --git a/_includes/relationships-section.html b/_includes/relationships-section.html new file mode 100644 index 0000000..a4ab28d --- /dev/null +++ b/_includes/relationships-section.html @@ -0,0 +1,109 @@ +{%- comment -%} + Relationships section — given a record_id, render outgoing edges + (this record's explicit `relationships` list) and incoming edges + (other records whose `relationships[].target` is this record id). + + Verbs: implements / produces / consumes / extends / superseded-by. + Incoming forms invert the verb (implemented by / produced by / etc.). + + Each rendered target / source is a link to its /projects// or + /artifacts// page depending on the record's kind. + + Usage from a layout: + {% include relationships-section.html record_id=page.project_id %} + {% include relationships-section.html record_id=page.artifact_id %} +{%- endcomment -%} + +{%- assign rec_id = include.record_id -%} +{%- assign this_rec = nil -%} +{%- for r in site.data.architecture_records -%} + {%- if r.id == rec_id -%}{%- assign this_rec = r -%}{%- endif -%} +{%- endfor -%} + +{%- comment -%} Determine if any incoming exists, by scanning all records. {%- endcomment -%} +{%- assign has_incoming = false -%} +{%- for r in site.data.architecture_records -%} + {%- if r.relationships -%} + {%- for rel in r.relationships -%} + {%- if rel.target == rec_id -%}{%- assign has_incoming = true -%}{%- endif -%} + {%- endfor -%} + {%- endif -%} +{%- endfor -%} + +{%- assign has_outgoing = false -%} +{%- if this_rec and this_rec.relationships and this_rec.relationships.size > 0 -%} + {%- assign has_outgoing = true -%} +{%- endif -%} + +{%- if has_outgoing or has_incoming -%} +

Relationships

+ +{%- if has_outgoing -%} +
+

Outgoing

+
    + {%- for rel in this_rec.relationships -%} + {%- assign target = nil -%} + {%- for r in site.data.architecture_records -%} + {%- if r.id == rel.target -%}{%- assign target = r -%}{%- endif -%} + {%- endfor -%} + {%- assign verb_text = rel.kind -%} + {%- if rel.kind == "superseded-by" -%}{%- assign verb_text = "superseded by" -%}{%- endif -%} +
  • + {{ verb_text }} + {%- if target -%} + {%- if target.kind == "artifact" -%}{%- assign tgt_path = "/artifacts/" -%}{%- else -%}{%- assign tgt_path = "/projects/" -%}{%- endif -%} + {%- if target.has_community_page -%} + {{ target.name }} + {%- else -%} + {{ target.name }} + {%- endif -%} + {%- if target.kind == "artifact" %}artifact{%- endif -%} + {%- if target.kind == "working-group" %}WG{%- endif -%} + {%- else -%} + {{ rel.target }} + {%- endif -%} + {%- if rel.status == "needs-review" -%}needs-review{%- endif -%} + {%- if rel.note -%}

    {{ rel.note }}

    {%- endif -%} +
  • + {%- endfor -%} +
+
+{%- endif -%} + +{%- if has_incoming -%} +
+

Incoming

+
    + {%- for r in site.data.architecture_records -%} + {%- if r.relationships -%} + {%- for rel in r.relationships -%} + {%- if rel.target == rec_id -%} + {%- assign verb_text = rel.kind -%} + {%- if rel.kind == "implements" -%}{%- assign verb_text = "implemented by" -%} + {%- elsif rel.kind == "produces" -%}{%- assign verb_text = "produced by" -%} + {%- elsif rel.kind == "consumes" -%}{%- assign verb_text = "consumed by" -%} + {%- elsif rel.kind == "extends" -%}{%- assign verb_text = "extended by" -%} + {%- elsif rel.kind == "superseded-by" -%}{%- assign verb_text = "supersedes" -%} + {%- endif -%} +
  • + {{ verb_text }} + {%- if r.kind == "artifact" -%}{%- assign src_path = "/artifacts/" -%}{%- else -%}{%- assign src_path = "/projects/" -%}{%- endif -%} + {%- if r.has_community_page -%} + {{ r.name }} + {%- else -%} + {{ r.name }} + {%- endif -%} + {%- if r.kind == "artifact" %}artifact{%- endif -%} + {%- if r.kind == "working-group" %}WG{%- endif -%} + {%- if rel.status == "needs-review" -%}needs-review{%- endif -%} + {%- if rel.note -%}

    {{ rel.note }}

    {%- endif -%} +
  • + {%- endif -%} + {%- endfor -%} + {%- endif -%} + {%- endfor -%} +
+
+{%- endif -%} +{%- endif -%} diff --git a/_includes/threats-list.html b/_includes/threats-list.html new file mode 100644 index 0000000..e8745b2 --- /dev/null +++ b/_includes/threats-list.html @@ -0,0 +1,76 @@ +{%- comment -%} + SLSA v1.2 threats list — native HTML rendering of the threat taxonomy + with mitigation links. Replaces the baked SVG variant. Each threat + expands inline (
) to show its description + mitigations. + + Categories from threat_categories.yml, threats from threats.yml. + Mitigations' `ref` fields are resolved against architecture_records + for kind-aware URL construction (artifacts → /artifacts/, projects → + /projects/). +{%- endcomment -%} + +
+ {%- for cat in site.data.threat_categories -%} + {%- assign cat_threats = site.data.threats | where: "category_letter", cat.letter -%} + {%- if cat_threats.size > 0 -%} +
+

+ {{ cat.letter }} + {{ cat.name }} + {{ cat_threats.size }} threat{% if cat_threats.size != 1 %}s{% endif %} +

+
    + {%- for t in cat_threats -%} + {%- assign covered = false -%} + {%- if t.mitigations and t.mitigations.size > 0 -%}{%- assign covered = true -%}{%- endif -%} +
  1. +
    + + {{ t.code }} + {{ t.label }} + {%- if covered -%} + {{ t.mitigations.size }} mitigation{% if t.mitigations.size != 1 %}s{% endif %} + {%- else -%} + no current OSSF coverage + {%- endif -%} + +
    + {%- if t.description -%}

    {{ t.description }}

    {%- endif -%} + {%- if covered -%} +

    Mitigated by:

    +
      + {%- for m in t.mitigations -%} + {%- assign mrec = nil -%} + {%- for r in site.data.architecture_records -%} + {%- if r.id == m.ref -%}{%- assign mrec = r -%}{%- endif -%} + {%- endfor -%} +
    • + {%- if mrec -%} + {%- if mrec.kind == "artifact" -%}{%- assign m_path = "/artifacts/" -%}{%- else -%}{%- assign m_path = "/projects/" -%}{%- endif -%} + {%- if mrec.has_community_page -%} + {{ mrec.name }} + {%- else -%} + {{ mrec.name }} + {%- endif -%} + {%- if mrec.kind == "working-group" %}WG{%- endif -%} + {%- if mrec.kind == "artifact" %}artifact{%- endif -%} + {%- else -%} + {{ m.ref }} + {%- endif -%} + {%- if m.status == "needs-review" -%}needs-review{%- endif -%} + {%- if m.note -%}

      {{ m.note }}

      {%- endif -%} +
    • + {%- endfor -%} +
    + {%- else -%} +

    No OpenSSF project or working group currently lists this threat in its scope. This is a real coverage gap and a worklist for the TAC.

    + {%- endif -%} +
    +
    +
  2. + {%- endfor -%} +
+
+ {%- endif -%} + {%- endfor -%} +
diff --git a/_layouts/artifact.html b/_layouts/artifact.html new file mode 100644 index 0000000..6f41cc4 --- /dev/null +++ b/_layouts/artifact.html @@ -0,0 +1,77 @@ +--- +layout: default +--- +{%- comment -%} Resolve this page's artifact from the master list. {%- endcomment -%} +{%- assign artifact_id = page.artifact_id -%} +{%- assign artifact = nil -%} +{%- for a in site.data.artifacts -%} + {%- if a.id == artifact_id -%}{%- assign artifact = a -%}{%- endif -%} +{%- endfor -%} + +
+

OpenSSF artifact

+

{{ artifact.name }}

+ {%- if artifact.aliases -%} +

Also known as: {{ artifact.aliases | join: ", " }}

+ {%- endif -%} +

{{ artifact.description }}

+ +
+ +{%- comment -%} Categories (Bundle 5 will surface these as chips). {%- endcomment -%} +{%- if artifact.categories and artifact.categories != empty -%} +

+ Categories: + {%- for c in artifact.categories -%} + {%- assign cat = nil -%} + {%- for cand in site.data.categories -%}{%- if cand.id == c -%}{%- assign cat = cand -%}{%- endif -%}{%- endfor -%} + {% if cat %}{{ cat.name }}{% else %}{{ c }}{% endif %} + {%- endfor -%} +

+{%- endif -%} + +{%- comment -%} Matrix placement (where this artifact flows in the SDLC × actor matrix). {%- endcomment -%} +{%- if artifact.sdlc_stages and artifact.sdlc_stages != empty -%} +

Where it flows in the supply chain

+
+

SDLC stages: + {%- for sid in artifact.sdlc_stages -%} + {%- assign s = nil -%} + {%- for cand in site.data.sdlc_stages -%}{%- if cand.id == sid -%}{%- assign s = cand -%}{%- endif -%}{%- endfor -%} + {%- if s -%}{{ s.name }}{%- unless forloop.last %}, {% endunless -%}{%- endif -%} + {%- endfor -%} +

+

Supply-chain actors: + {%- for aid in artifact.supply_chain_actors -%} + {%- assign act = nil -%} + {%- for cand in site.data.supply_chain_actors -%}{%- if cand.id == aid -%}{%- assign act = cand -%}{%- endif -%}{%- endfor -%} + {%- if act -%} + {%- if aid == "software-producer" -%}{{ act.name }} + {%- elsif aid == "software-distributor" -%}{{ act.name }} + {%- elsif aid == "software-consumer" -%}{{ act.name }} + {%- elsif aid == "other" -%}{{ act.name }} + {%- else -%}{{ act.name }}{%- endif -%} + {%- unless forloop.last %}, {% endunless -%} + {%- endif -%} + {%- endfor -%} +

+
+{%- else -%} +

+ This artifact is referenced by other records but doesn't itself inhabit a single (stage, actor) cell. It appears in projects' "produces" or "consumes" relationships only. +

+{%- endif -%} + +{%- comment -%} Relationships (Bundle 3 fills this section). {%- endcomment -%} +{% include relationships-section.html record_id=artifact.id %} + + diff --git a/_layouts/project.html b/_layouts/project.html index e8c23b0..54586bb 100644 --- a/_layouts/project.html +++ b/_layouts/project.html @@ -143,6 +143,8 @@ {%- endif -%} {%- endfor -%} +{% include relationships-section.html record_id=project.id %} +