Skip to content

Commit 91b13e3

Browse files
spoorccclaude
spoorcc
and
claude
authored
doc: add security documentation pipeline flow diagram (#1276)
* doc: add security documentation pipeline flow diagram Adds a PlantUML component diagram (security_doc_flow.puml) showing how the three security documentation pipelines produce their output artifacts — threat model RSTs (via tm_render.py + pytm), compliance RST and OSCAL JSON (via compliance.py), and runtime outputs (SARIF, SBOM, Code Climate, Jenkins JSON from dfetch check/report). References the diagram from a new "Security Documentation Pipeline" section in security.rst with prose explaining each pipeline. https://claude.ai/code/session_01P1dbJRTSn9LooBhp9Xwt7X * doc: add GitHub links to source files in security pipeline description https://claude.ai/code/session_01P1dbJRTSn9LooBhp9Xwt7X * doc: restructure security doc flow diagram after EU Blue Guide fig 4.1.2.2 Rebuilds security_doc_flow.puml to follow the four-column structure of figure 4.1.2.2 from the EU Blue Guide on product rules (OJ 2022/C 247): col 1 all requirements (CRA ECR-a…m + STRIDE catalog) col 2 risk & threat assessment step (dashed box, filter) col 3 applicable to dfetch (threats + controls + N/A gaps) col 4 output paths — solid arrows where STRIDE methodology or CRA compliance analysis provides coverage, dashed arrow for gaps with no harmonised standard Updates the security.rst prose to explain the Blue Guide analogy and links to the official EU Blue Guide PDF on EUR-Lex. https://claude.ai/code/session_01P1dbJRTSn9LooBhp9Xwt7X * doc: add artifact quick-reference table and runtime output cross-links Replaces the plain "Runtime outputs" sentence with proper :ref: cross-links to check-ci-github (SARIF), sbom (CycloneDX), check-ci-gitlab (Code Climate), and check-ci-jenkins (Jenkins JSON). Adds an "Artifacts at a glance" list-table covering all ten security documentation outputs — generated RST pages, manually maintained RST page, two OSCAL JSON files, and the four runtime reporting formats — with direct doc cross-references or GitHub source links for each. https://claude.ai/code/session_01P1dbJRTSn9LooBhp9Xwt7X * doc: add Further Reading section with references to CRA, EN 40000, OSCAL, STRIDE Adds a structured Further Reading section covering: - CRA: official text, EU overview, March 2026 draft guidance, BSI TR-03183-1 - EN 40000: CEN/CENELEC cybersecurity page, March 2025 webinar slides, EU Blue Guide 2022 (fig 4.1.2.2), OSCAL catalog provenance note - Threat modelling: STRIDE docs, pytm, BSI TR-03183-1, ENISA playbook - OSCAL: NIST OSCAL project, Catalog model, Component Definition model - Output formats: SARIF 2.1.0 (OASIS), CycloneDX, Code Climate spec Also updates the EN 40000 inline link from a single webinar PDF to the CEN/CENELEC cybersecurity overview page, and adds an explicit STRIDE link. https://claude.ai/code/session_01P1dbJRTSn9LooBhp9Xwt7X * doc: correct SBOM scope — release attestations about dfetch, not dfetch report The SBOMs relevant to dfetch's security model are the CycloneDX SBOM attestations generated by GitHub Actions about dfetch itself (signed by Sigstore, verifiable via gh attestation verify), not the SBOM output that dfetch generates for users' vendored dependencies. - diagram: replace "Runtime evidence (dfetch check/report)" with two separate clusters: "Release attestations (GitHub Actions, about dfetch)" containing CycloneDX SBOM · SLSA Build Provenance · Source Provenance · VSA · in-toto Test Results, connected from tm_out via controls C-026/C-037/C-039/C-040; and "Dependency-scanning outputs (dfetch check)" containing only SARIF · Code Climate · Jenkins JSON - prose: replace single "Runtime outputs" paragraph with "Release attestations" (five types, Sigstore-signed, gh attestation verify) and "Dependency-scanning outputs" (dfetch check formats for users) - artifacts table: replace dfetch report --sbom row with a "Release attestations" row referencing verify-integrity and the four controls - Further Reading: update CycloneDX note to clarify it is dfetch's own CI-generated SBOM, not a user-facing report --sbom output https://claude.ai/code/session_01P1dbJRTSn9LooBhp9Xwt7X * doc: add attestation, provenance and security standard terms to glossary New entries: Attestation — Sigstore-signed claims about dfetch release artifacts; links the five attestation types and verify-integrity Build Provenance — SLSA attestation for source-to-binary traceability CRA — Cyber Resilience Act (EU 2024/2847), 13 ECRs EN 40000 — CEN/CENELEC harmonised standard family under the CRA OSCAL — NIST Open Security Controls Assessment Language; both OSCAL artifacts (catalog + component-definition) explained SARIF — Static Analysis Results Interchange Format; links check-ci Sigstore — transparency-log code-signing infrastructure for attestations SLSA — Supply-chain Levels for Software Artifacts framework Source Provenance — SLSA attestation for governance controls on main STRIDE — threat-classification framework; links both threat model pages VSA — Verification Summary Attestation for binary installers Updated: SBOM — notes both user-facing dfetch report output and dfetch's own CI-generated CycloneDX release attestation https://claude.ai/code/session_01P1dbJRTSn9LooBhp9Xwt7X * doc: fix three accuracy issues in glossary and flow diagram Attestation entry (glossary): clarified that four attestation types are published per release (Build Provenance, SBOM, VSA, in-toto Test Results) and Source Provenance is published on every push to main — not per release. Verified against verify-integrity.rst line 239. Diagram producer nodes: replaced misleading arrows (tm_out→sc_out and appl_c→rt_out) with explicit producer nodes inside each output package: - "GitHub Actions release workflow" → sc_out and src_prov (Source Provenance split out as a separate node to reflect different trigger) - "dfetch check" → rt_out Arrows from the documentation pipeline are now dashed "requires/documents" links to the producer nodes, not solid "produces" arrows to the artifacts. control_register.rst removed from comp_out: the file is manually maintained and not generated by compliance.py (which outputs only compliance_track.rst and dfetch.component-definition.json). Verified by inspection of compliance.py output path and README commands. https://claude.ai/code/session_01P1dbJRTSn9LooBhp9Xwt7X --------- Co-authored-by: Claude <noreply@anthropic.com>
1 parent baba2ce commit 91b13e3

3 files changed

Lines changed: 405 additions & 8 deletions

File tree

‎doc/explanation/security.rst‎

Lines changed: 200 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -18,11 +18,12 @@ PyPI distribution, and runtime execution in developer and build
1818
environments.
1919

2020
The model is aligned with the `Cyber Resilience Act (CRA)`_ and the
21-
`EN 40000`_ series of cybersecurity standards, using STRIDE as the threat
21+
`EN 40000`_ series of cybersecurity standards, using `STRIDE`_ as the threat
2222
classification methodology. It is inspired by the `ENISA Security by Design and Default Playbook`_.
2323

2424
.. _`Cyber Resilience Act (CRA)`: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
25-
.. _`EN 40000`: https://www.cencenelec.eu/media/CEN-CENELEC/Events/Webinars/2025/2025-03-10_webinar_cyberresilience_act.pdf
25+
.. _`EN 40000`: https://www.cencenelec.eu/areas-of-work/cen-cenelec-topics/cybersecurity/
26+
.. _`STRIDE`: https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
2627
.. _`ENISA Security by Design and Default Playbook`: https://www.enisa.europa.eu/sites/default/files/2026-03/ENISA_Secure_By_Design_and_Default_Playbook_v0.4_draft_for_consultation.pdf
2728

2829
The threat model is split into two focused modules:
@@ -103,6 +104,119 @@ threat models below.
103104
manifest destination path, or hostile archive entries, could write, overwrite, or
104105
delete files outside the intended vendoring directory on the end-user machine.
105106

107+
Security Documentation Pipeline
108+
--------------------------------
109+
110+
The diagram below follows the structure of figure 4.1.2.2 in the
111+
`EU Blue Guide on the implementation of EU product rules (2022) <https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A52022XC0629%2804%29>`_:
112+
all requirements are on the left, a risk-and-threat assessment step (dashed box)
113+
selects which requirements apply, the applicable subset sits in the third column,
114+
and the right side shows two output paths — a solid-arrow path where coverage is
115+
provided by a recognised methodology (STRIDE / pytm), and a dashed-arrow path
116+
where no harmonised standard applies and the requirement is addressed directly as
117+
a documented gap or compliance artefact.
118+
119+
.. uml:: /static/uml/security_doc_flow.puml
120+
121+
**Threat model pipeline** —
122+
`security/tm_supply_chain.py <https://github.com/dfetch-org/dfetch/blob/main/security/tm_supply_chain.py>`_
123+
and
124+
`security/tm_usage.py <https://github.com/dfetch-org/dfetch/blob/main/security/tm_usage.py>`_
125+
define the model elements (actors, data flows, trust boundaries) using the
126+
*pytm* library.
127+
`security/threats.json <https://github.com/dfetch-org/dfetch/blob/main/security/threats.json>`_
128+
provides a catalog of 60+ STRIDE-classified threats.
129+
`security/tm_render.py <https://github.com/dfetch-org/dfetch/blob/main/security/tm_render.py>`_
130+
drives *pytm*, matches threats against model elements, and combines the output
131+
with
132+
`security/report_template.rst <https://github.com/dfetch-org/dfetch/blob/main/security/report_template.rst>`_
133+
to produce the two RST threat-model pages (:doc:`threat_model_supply_chain` and
134+
:doc:`threat_model_usage`), each containing an embedded data-flow diagram, a
135+
sequence diagram, and tables for assets, threats, and controls.
136+
137+
**Compliance pipeline** —
138+
`security/compliance_data.py <https://github.com/dfetch-org/dfetch/blob/main/security/compliance_data.py>`_
139+
defines the 46 dfetch controls and their mapping to CRA essential requirements
140+
and prEN 40000-1-4 security objectives.
141+
`security/compliance.py <https://github.com/dfetch-org/dfetch/blob/main/security/compliance.py>`_
142+
reads those definitions together with the static OSCAL catalog and generates
143+
:doc:`compliance_track` (human-readable RST mapping tables) and
144+
`security/dfetch.component-definition.json <https://github.com/dfetch-org/dfetch/blob/main/security/dfetch.component-definition.json>`_
145+
(machine-readable OSCAL 1.1.2 Component Definition). The
146+
:doc:`control_register` page is maintained manually and references controls
147+
defined in ``compliance_data.py``.
148+
149+
**Release attestations** — GitHub Actions generates five cryptographic attestation
150+
types *about dfetch itself* during every release, signed by Sigstore and verifiable
151+
by consumers with ``gh attestation verify`` (see :ref:`verify-integrity`):
152+
CycloneDX SBOM (composition of the published package), SLSA Build Provenance
153+
(source-to-binary traceability), SLSA Source Provenance (governance controls on
154+
``main``), Verification Summary Attestation (VSA), and in-toto Test Results
155+
(CI test suite passed before any binary was produced). These are required by
156+
supply-chain controls :ref:`C-026 <c-026>`, :ref:`C-037 <c-037>`,
157+
:ref:`C-039 <c-039>`, and :ref:`C-040 <c-040>`.
158+
159+
**Dependency-scanning outputs** — When users run ``dfetch check``, the reporting
160+
layer emits findings about outdated or missing vendored dependencies in the format
161+
of their choice:
162+
:ref:`SARIF <check-ci-github>` (for GitHub code scanning),
163+
:ref:`Code Climate JSON <check-ci-gitlab>` (GitLab merge-request quality reports), or
164+
:ref:`Jenkins JSON <check-ci-jenkins>` (Jenkins warnings-ng plugin).
165+
166+
**Artifacts at a glance**
167+
168+
.. list-table::
169+
:header-rows: 1
170+
:widths: 40 15 45
171+
172+
* - Artifact
173+
- Type
174+
- Purpose
175+
176+
* - :doc:`threat_model_supply_chain`
177+
- RST (generated)
178+
- Supply-chain threat model: DFD, sequence diagram, STRIDE tables, controls
179+
180+
* - :doc:`threat_model_usage`
181+
- RST (generated)
182+
- Runtime threat model: DFD, sequence diagram, STRIDE tables, controls
183+
184+
* - :doc:`compliance_track`
185+
- RST (generated)
186+
- CRA Annex I → prEN 40000-1-4 SO.* → dfetch control traceability tables
187+
188+
* - :doc:`control_register`
189+
- RST (maintained)
190+
- All 46 dfetch controls (C-001 to C-046) with references and status
191+
192+
* - `security/dfetch.component-definition.json <https://github.com/dfetch-org/dfetch/blob/main/security/dfetch.component-definition.json>`_
193+
- OSCAL 1.1.2 JSON
194+
- Machine-readable Component Definition; maps dfetch controls to CRA ECRs
195+
196+
* - `security/cra_pren_4000014_oscal_catalog.json <https://github.com/dfetch-org/dfetch/blob/main/security/cra_pren_4000014_oscal_catalog.json>`_
197+
- OSCAL 1.1.2 JSON
198+
- Static prEN 40000-1-4 catalog (input to compliance pipeline, not generated)
199+
200+
* - :ref:`Release attestations <verify-integrity>`
201+
- Sigstore-signed (GitHub Actions)
202+
- Five attestation types generated *about dfetch* on every release: CycloneDX
203+
SBOM, SLSA Build Provenance, SLSA Source Provenance, VSA, in-toto Test Results.
204+
Required by controls :ref:`C-026 <c-026>`, :ref:`C-037 <c-037>`,
205+
:ref:`C-039 <c-039>`, :ref:`C-040 <c-040>`;
206+
verifiable with ``gh attestation verify``.
207+
208+
* - :ref:`SARIF output <check-ci-github>`
209+
- JSON (SARIF 2.1.0)
210+
- ``dfetch check --output-type sarif``; upload to GitHub code scanning
211+
212+
* - :ref:`Code Climate JSON <check-ci-gitlab>`
213+
- JSON (Code Climate)
214+
- ``dfetch check --output-type code-climate``; GitLab MR quality widget
215+
216+
* - :ref:`Jenkins JSON <check-ci-jenkins>`
217+
- JSON
218+
- ``dfetch check --output-type jenkins``; Jenkins warnings-ng plugin
219+
106220
Threat Models
107221
-------------
108222

@@ -149,3 +263,87 @@ Machine-readable OSCAL 1.1.2 artifacts are kept alongside the source:
149263
- `security/dfetch.component-definition.json <https://github.com/dfetch-org/dfetch/blob/main/security/dfetch.component-definition.json>`_ — dfetch Component Definition
150264

151265
The complete list of all controls is on the :doc:`control_register` page.
266+
267+
Further Reading
268+
---------------
269+
270+
Cyber Resilience Act
271+
~~~~~~~~~~~~~~~~~~~~
272+
273+
- `Regulation (EU) 2024/2847 — Cyber Resilience Act <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847>`_ —
274+
the legislative text; Annex I Part I lists the 13 essential requirements (ECR-a … ECR-m)
275+
and Part II the seven vulnerability-handling requirements.
276+
- `EU Commission CRA overview <https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act>`_ —
277+
accessible summary of scope, obligations, timeline, and links to delegated and implementing acts.
278+
- `CRA draft guidance, March 2026 (Ares(2026)2319816) <https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act>`_ —
279+
Commission guidance on applying the CRA; covers free and open-source software, remote data
280+
processing, and support periods.
281+
- `BSI TR-03183-1: Cyber Resilience Requirements for Manufacturers <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-1.pdf>`_ —
282+
practical risk-based guidance aligned with CRA; used as the risk-context framework in
283+
dfetch's threat model pages.
284+
285+
EN 40000 harmonised standards
286+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
287+
288+
The EN 40000 family is being developed by CEN/CLC/JTC 13 to provide harmonised
289+
standards under the CRA. Once published in the OJEU, compliance with them confers a
290+
presumption of conformity with the corresponding CRA essential requirements.
291+
292+
- `CEN/CENELEC cybersecurity standards page <https://www.cencenelec.eu/areas-of-work/cen-cenelec-topics/cybersecurity/>`_ —
293+
overview of the EN 40000 work programme (prEN 40000-1-1 through 40000-1-4) and
294+
the CEN/CLC/JTC 13 committee.
295+
- `CEN/CENELEC CRA webinar slides (March 2025) <https://www.cencenelec.eu/media/CEN-CENELEC/Events/Webinars/2025/2025-03-10_webinar_cyberresilience_act.pdf>`_ —
296+
explains how each part of EN 40000 maps to CRA obligations, with an overview of
297+
the Security Objectives (SO.*) in prEN 40000-1-4.
298+
- `EU Blue Guide on the implementation of EU product rules (2022) <https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A52022XC0629%2804%29>`_ —
299+
explains how manufacturers identify applicable requirements, choose specifications,
300+
and demonstrate conformity; figure 4.1.2.2 inspired the security documentation
301+
flow diagram on this page.
302+
- `security/cra_pren_4000014_oscal_catalog.json <https://github.com/dfetch-org/dfetch/blob/main/security/cra_pren_4000014_oscal_catalog.json>`_ —
303+
dfetch's machine-readable OSCAL 1.1.2 representation of the prEN 40000-1-4 catalog,
304+
derived from the CEN/CLC/JTC 13 WG 9 deep-dive session (March 2026).
305+
306+
Threat modelling
307+
~~~~~~~~~~~~~~~~
308+
309+
- `STRIDE methodology <https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats>`_ —
310+
Microsoft's six-category threat classification (Spoofing, Tampering, Repudiation,
311+
Information Disclosure, Denial of Service, Elevation of Privilege); used to classify
312+
every entry in
313+
`security/threats.json <https://github.com/dfetch-org/dfetch/blob/main/security/threats.json>`_.
314+
- `pytm — Pythonic Threat Modeling <https://github.com/izar/pytm>`_ —
315+
the library used by ``tm_supply_chain.py`` and ``tm_usage.py`` to define model elements
316+
(actors, data flows, trust boundaries) and auto-generate threat findings.
317+
- `BSI TR-03183-1 <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-1.pdf>`_ —
318+
provides the risk-context chapter structure used in the threat model pages.
319+
- `ENISA Security by Design and Default Playbook <https://www.enisa.europa.eu/sites/default/files/2026-03/ENISA_Secure_By_Design_and_Default_Playbook_v0.4_draft_for_consultation.pdf>`_ —
320+
ENISA guidance on integrating security from the start; the overall model structure is
321+
inspired by this playbook.
322+
323+
OSCAL
324+
~~~~~
325+
326+
`OSCAL (Open Security Controls Assessment Language) <https://pages.nist.gov/OSCAL/>`_ is a
327+
set of NIST-published JSON/XML schemas for machine-readable security documentation.
328+
dfetch uses OSCAL 1.1.2 for two artifacts:
329+
330+
- `OSCAL Catalog model <https://pages.nist.gov/OSCAL/reference/latest/catalog/>`_ —
331+
used by ``cra_pren_4000014_oscal_catalog.json`` to represent the prEN 40000-1-4
332+
security objectives as a structured catalog.
333+
- `OSCAL Component Definition model <https://pages.nist.gov/OSCAL/reference/latest/component-definition/>`_ —
334+
used by ``dfetch.component-definition.json`` to describe how dfetch implements each
335+
control and maps it back to CRA essential requirements via SO.* objectives.
336+
337+
Security assessment output formats
338+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
339+
340+
- `SARIF 2.1.0 (OASIS standard) <https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html>`_ —
341+
Static Analysis Results Interchange Format; used by ``dfetch check --output-type sarif``
342+
for :ref:`GitHub code scanning integration <check-ci-github>`.
343+
- `CycloneDX specification <https://cyclonedx.org/specification/overview/>`_ —
344+
SBOM format used for the release attestation that GitHub Actions generates
345+
*about dfetch itself* on every release; verifiable with ``gh attestation verify``
346+
(see :ref:`verify-integrity`).
347+
- `Code Climate test coverage spec <https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md>`_ —
348+
JSON format used by ``dfetch check --output-type code-climate`` for
349+
:ref:`GitLab merge-request quality widgets <check-ci-gitlab>`.

‎doc/reference/glossary.rst‎

Lines changed: 103 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -65,12 +65,15 @@ Glossary
6565
entries.
6666

6767
SBOM
68-
Software Bill of Materials. A machine-readable inventory of all vendored
69-
dependencies, generated by ``dfetch report -t sbom``. *Dfetch* produces
70-
SBOMs in `CycloneDX <https://cyclonedx.org/>`_ JSON format, including
71-
each dependency's URL, revision, auto-detected license, and — for
72-
:term:`Archive` sources — a cryptographic hash when an
73-
:term:`Integrity` field is present.
68+
Software Bill of Materials — a machine-readable inventory of software
69+
components and their licences. *Dfetch* uses CycloneDX JSON format
70+
in two contexts: (1) ``dfetch report -t sbom`` generates an SBOM of a
71+
project's vendored dependencies, listing each dependency's URL, revision,
72+
auto-detected licence, and — for :term:`Archive` sources — the
73+
cryptographic hash from the :term:`Integrity` field; (2) the dfetch
74+
release pipeline generates a CycloneDX SBOM *about dfetch itself* as a
75+
Sigstore-signed :term:`Attestation` on every release, verifiable with
76+
``gh attestation verify`` (see :ref:`verify-integrity`).
7477

7578
Source
7679
The subfolder inside an upstream repository to copy, declared with the
@@ -95,9 +98,103 @@ Glossary
9598
all :term:`Subproject` dependencies and is typically the repository that
9699
is committed to version control.
97100

101+
Attestation
102+
A cryptographic claim about a software artifact, signed by GitHub Actions
103+
via :term:`Sigstore` and published in the `dfetch attestation registry
104+
<https://github.com/dfetch-org/dfetch/attestations>`_. Attestations are
105+
verifiable by anyone using ``gh attestation verify`` without trusting any
106+
private key. dfetch publishes four attestation types on every release:
107+
:term:`Build Provenance`, :term:`SBOM` (CycloneDX composition of the
108+
package), :term:`VSA`, and in-toto Test Results (the CI test suite passed
109+
before any binary was produced). :term:`Source Provenance` is published
110+
on every push to ``main`` rather than per-release. See
111+
:ref:`verify-integrity` for per-artifact verification instructions.
112+
113+
Build Provenance
114+
An :term:`SLSA` attestation recording the exact source commit and GitHub
115+
Actions workflow that produced a release artifact. Lets consumers verify
116+
that a binary was built from the claimed source by the official CI workflow
117+
and was not injected or modified after the build. Required by supply-chain
118+
control C-037; verifiable with ``gh attestation verify`` (see
119+
:ref:`verify-integrity`).
120+
121+
CRA
122+
Cyber Resilience Act — Regulation (EU) 2024/2847, in force from
123+
10 December 2024. It imposes cybersecurity requirements on manufacturers
124+
of *Products with Digital Elements* placed on the EU market. dfetch's
125+
:ref:`security model <security>` aligns with the 13 CRA Annex I essential
126+
requirements (ECR-a through ECR-m) using the :term:`EN 40000` harmonised
127+
standards and :term:`OSCAL` machine-readable documentation.
128+
129+
EN 40000
130+
The CEN/CENELEC family of harmonised cybersecurity standards developed
131+
under the :term:`CRA` by CEN/CLC/JTC 13. The relevant parts for dfetch
132+
are prEN 40000-1-2 (product security context), prEN 40000-1-3
133+
(vulnerability handling), and prEN 40000-1-4 (security objectives SO.*
134+
that bridge CRA essential requirements to concrete controls). Once
135+
published in the OJEU, compliance with these standards gives a presumption
136+
of conformity with the corresponding CRA requirements. dfetch's mapping
137+
is captured in :doc:`/explanation/compliance_track`.
138+
139+
OSCAL
140+
Open Security Controls Assessment Language — a set of NIST-published
141+
JSON/XML schemas for machine-readable security control documentation.
142+
dfetch uses OSCAL 1.1.2 for
143+
``security/cra_pren_4000014_oscal_catalog.json`` (the prEN 40000-1-4
144+
catalog) and ``security/dfetch.component-definition.json`` (dfetch's
145+
Component Definition, which maps the 46 dfetch controls to :term:`CRA`
146+
ECRs via :term:`EN 40000` Security Objectives).
147+
148+
SARIF
149+
Static Analysis Results Interchange Format — an OASIS standard
150+
(version 2.1.0) for exchanging static-analysis findings.
151+
``dfetch check --output-type sarif`` produces a SARIF file that can be
152+
uploaded to GitHub code scanning to surface out-of-date or missing
153+
dependencies as security alerts in pull requests. See
154+
:ref:`check-ci-github`.
155+
156+
Sigstore
157+
An open-source project providing transparency-log-backed code-signing
158+
without long-lived private keys. GitHub Actions signs dfetch's
159+
:term:`Attestation` artifacts via Sigstore; the signatures are anchored
160+
in a public, append-only transparency log (Rekor) so that forgery is
161+
detectable by anyone.
162+
163+
SLSA
164+
Supply-chain Levels for Software Artifacts — a security framework defining
165+
increasing levels of supply-chain integrity guarantees. dfetch publishes
166+
two SLSA attestation types per release: :term:`Build Provenance`
167+
(source-to-binary traceability) and :term:`Source Provenance` (governance
168+
controls on the ``main`` branch).
169+
170+
Source Provenance
171+
An :term:`SLSA` attestation recording which branch-protection, code-review,
172+
and ancestry-enforcement controls were active when a commit was merged to
173+
``main``. Lets consumers verify that dfetch source code went through the
174+
required governance process before being included in a release. Required
175+
by control C-037; published on every push to ``main`` via
176+
``slsa-framework/source-actions``. See :ref:`verify-integrity`.
177+
178+
STRIDE
179+
A threat-classification framework developed by Microsoft: Spoofing,
180+
Tampering, Repudiation, Information Disclosure, Denial of Service,
181+
Elevation of Privilege. Every threat in ``security/threats.json`` is
182+
classified by STRIDE category to identify which security property it
183+
violates and which controls address it. See
184+
:doc:`/explanation/threat_model_supply_chain` and
185+
:doc:`/explanation/threat_model_usage`.
186+
98187
Vendoring
99188
The practice of copying third-party source code directly into your own
100189
repository rather than relying on a package manager to fetch it at build
101190
time. *Dfetch* automates the fetch, version-pinning, patching, and
102191
update lifecycle of vendored dependencies. See :ref:`Vendoring <vendoring>`
103192
for a detailed discussion of the trade-offs.
193+
194+
VSA
195+
Verification Summary Attestation — an :term:`SLSA` attestation attached
196+
to binary installer artifacts that records the source archive was itself
197+
attested and verified before the binary was produced. It links
198+
source-level trust to the installed binary so consumers can confirm the
199+
full source-to-installer chain without re-verifying the source separately.
200+
See :ref:`verify-integrity`.

0 commit comments

Comments
 (0)