Glossary

Archive

A compressed file (tar.gz, tgz, tar.bz2, tar.xz, or zip) served over HTTP, HTTPS, or a file:// URL used as a dependency source. Declare it with vcs: archive in the manifest. Unlike Git or SVN projects, archives carry no VCS history; use the Integrity field to verify the download cryptographically.

Attestation

A cryptographic claim about a software artifact, signed by GitHub Actions via Sigstore and published in the dfetch attestation registry. Attestations are verifiable by anyone using gh attestation verify without trusting any private key. dfetch publishes four attestation types on every release: Build Provenance, SBOM (CycloneDX composition of the package), VSA, and in-toto Test Results (the CI test suite passed before any binary was produced). Source Provenance is published on every push to main rather than per-release. See Verify release integrity for per-artifact verification instructions.

Build Provenance

An SLSA attestation recording the exact source commit and GitHub Actions workflow that produced a release artifact. Lets consumers verify that a binary was built from the claimed source by the official CI workflow and was not injected or modified after the build. Required by supply-chain control C-037; verifiable with gh attestation verify (see Verify release integrity).

CRA

Cyber Resilience Act — Regulation (EU) 2024/2847, in force from 10 December 2024. It imposes cybersecurity requirements on manufacturers of Products with Digital Elements placed on the EU market. dfetch’s security model aligns with the 13 CRA Annex I essential requirements (ECR-a through ECR-m) using the EN 40000 harmonised standards and OSCAL machine-readable documentation.

CVE

Common Vulnerabilities and Exposures — a public catalogue of disclosed security vulnerabilities, each assigned a unique identifier (e.g. CVE-2024-12345). dfetch’s CI checks runtime dependencies against the OSV database (which aggregates CVEs and other advisories) as part of control C-043.

Destination

The local path, relative to the manifest file, where Dfetch places the fetched files of a subproject. Set with the dst: attribute; defaults to the project name: when omitted.

ECR

Essential Cybersecurity Requirement — one of the 13 product-security obligations (ECR-a through ECR-m) listed in Annex I Part I of the CRA. Each ECR maps to one or more EN 40000 Security Objectives (SO.*) that specify the technical controls needed to satisfy it. dfetch’s compliance track maps every ECR to the dfetch controls that implement it.

EN 40000

The CEN/CENELEC family of harmonised cybersecurity standards developed under the CRA by CEN/CLC/JTC 13. The relevant parts for dfetch are prEN 40000-1-2 (product security context), prEN 40000-1-3 (vulnerability handling), and prEN 40000-1-4 (security objectives SO.* that bridge CRA essential requirements to concrete controls). Once published in the OJEU, compliance with these standards gives a presumption of conformity with the corresponding CRA requirements. dfetch’s mapping is captured in CRA Compliance.

Freeze

The operation performed by dfetch freeze that replaces every loose branch: or open tag: reference in the manifest with the exact revision that is currently fetched. Produces a fully reproducible manifest where every dependency is pinned to a specific commit or archive URL.

Integrity

An optional cryptographic hash declared in the manifest under integrity.hash: for Archive dependencies. Format is <algorithm>:<hex-digest> (e.g. sha256:e3b0c4…). Dfetch verifies the downloaded archive against this hash before extracting it, and records it in the generated SBOM.

Manifest

The dfetch.yaml file that describes all dependencies of a Superproject. It lists Remote sources and the Subproject entries to fetch, together with their version pins, source paths, and patches. Dfetch searches upward from the current directory to locate the manifest automatically.

Metadata

The .dfetch_data.yaml file that Dfetch writes inside each fetched Subproject directory. It records the URL, VCS type, and exact revision that is currently present, allowing Dfetch to detect out-of-date or locally modified dependencies without re-contacting the remote.

OSCAL

Open Security Controls Assessment Language — a set of NIST-published JSON/XML schemas for machine-readable security control documentation. dfetch uses OSCAL 1.1.2 for security/cra_pren_4000014_oscal_catalog.json (the prEN 40000-1-4 catalog) and security/dfetch.component-definition.json (dfetch’s Component Definition, which maps the 46 dfetch controls to CRA ECRs via EN 40000 Security Objectives).

Patch

A .patch file that captures local modifications to a vendored Subproject. Declared with the patch: attribute in the manifest, patches are automatically re-applied by dfetch update after each upstream fetch. Created with dfetch diff and reformatted for upstream submission with dfetch format-patch.

Remote

A named entry in the manifest that provides a common url-base for multiple projects. Instead of repeating a full URL for every Subproject, projects can reference the remote by name and supply only their repo-path:.

Repo-path

The path appended to a Remote’s url-base to form the full repository URL of a Subproject. Use it together with a remote: reference to avoid repeating the URL base across many entries.

SARIF

Static Analysis Results Interchange Format — an OASIS standard (version 2.1.0) for exchanging static-analysis findings. dfetch check --output-type sarif produces a SARIF file that can be uploaded to GitHub code scanning to surface out-of-date or missing dependencies as security alerts in pull requests. See GitHub Actions (SARIF).

SBOM

Software Bill of Materials — a machine-readable inventory of software components and their licences. Dfetch uses CycloneDX JSON format in two contexts: (1) dfetch report -t sbom generates an SBOM of a project’s vendored dependencies, listing each dependency’s URL, revision, auto-detected licence, and — for Archive sources — the cryptographic hash from the Integrity field; (2) the dfetch release pipeline generates a CycloneDX SBOM about dfetch itself as a Sigstore-signed Attestation on every release, verifiable with gh attestation verify (see Verify release integrity).

SDLC

Software Development Lifecycle — the full sequence of phases from planning and design through development, testing, deployment, and maintenance of a software product. dfetch’s security model documents controls across the complete SDLC: from source contribution and CI/CD through PyPI distribution to runtime execution.

Sigstore

An open-source project providing transparency-log-backed code-signing without long-lived private keys. GitHub Actions signs dfetch’s Attestation artifacts via Sigstore; the signatures are anchored in a public, append-only transparency log (Rekor) so that forgery is detectable by anyone.

SLSA

Supply-chain Levels for Software Artifacts — a security framework defining increasing levels of supply-chain integrity guarantees. dfetch publishes two SLSA attestation types per release: Build Provenance (source-to-binary traceability) and Source Provenance (governance controls on the main branch).

Source

The subfolder inside an upstream repository to copy, declared with the src: attribute. Only the files under that path are placed in the Destination; the rest of the upstream repository is ignored. License files are always retained regardless of the src: setting.

Source Provenance

An SLSA attestation recording which branch-protection, code-review, and ancestry-enforcement controls were active when a commit was merged to main. Lets consumers verify that dfetch source code went through the required governance process before being included in a release. Required by control C-037; published on every push to main via slsa-framework/source-actions. See Verify release integrity.

STRIDE

A threat-classification framework developed by Microsoft: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Every threat in security/threats.json is classified by STRIDE category to identify which security property it violates and which controls address it. See dfetch Supply Chain and dfetch Runtime Usage.

Sub-manifest

A dfetch.yaml found inside a fetched Subproject. After fetching, Dfetch inspects sub-manifests and reports any further dependencies they declare, so you can decide whether to vendor those transitively. Pass --no-recommendations to dfetch update to skip this check.

Subproject

A dependency declared in the Manifest that Dfetch copies into the Superproject. A subproject can be sourced from a Git repository, an SVN repository, or a plain Archive URL.

Superproject

The top-level project that owns the Manifest. It coordinates all Subproject dependencies and is typically the repository that is committed to version control.

Vendoring

The practice of copying third-party source code directly into your own repository rather than relying on a package manager to fetch it at build time. Dfetch automates the fetch, version-pinning, patching, and update lifecycle of vendored dependencies. See Vendoring for a detailed discussion of the trade-offs.

VSA

Verification Summary Attestation — an SLSA attestation attached to binary installer artifacts that records the source archive was itself attested and verified before the binary was produced. It links source-level trust to the installed binary so consumers can confirm the full source-to-installer chain without re-verifying the source separately. See Verify release integrity.