CRA Compliance

Note

dfetch is non-commercial open-source software and falls outside the mandatory scope of Regulation (EU) 2024/2847 (CRA): it is not placed on the market in the context of a commercial activity (CRA Article 3(1); Recital 18 provides interpretive context). This document is produced voluntarily to support downstream integrators who must account for open-source components in their own Article 13 conformity assessments.

This page provides three-tier traceability from the CRA Annex I essential requirements through the prEN 40000-1-4 Security Objectives to the concrete dfetch controls or documented gaps:

CRA Annex I Essential Requirement (ECR-a … ECR-m)
        ↓
prEN 40000-1-4 Security Objective (SO.*)
        ↓
dfetch control (C-001 … C-046) or documented gap

Machine-readable artifacts are kept alongside the source, encoded in OSCAL 1.2.2:

The full list of all controls is available on the Control Register page.

Status key

✓

Implemented — control satisfies the objective fully.

⚠

Partial — control exists but a gap remains (see Gaps column).

N/A

Not applicable — the objective does not apply to dfetch.

Classification Decision

Criterion

Decision / Basis

Product type

Software tool (CLI) — Python package distributed via PyPI

CRA classification

Non-commercial open-source software (Recital 18 exemption)

Legal basis

CRA Article 3(1) (scope — dfetch is not placed on the market in the context of a commercial activity); Article 3(14) (definition of open-source software steward, for reference); Recital 18 (interpretive context for the treatment of non-commercial FOSS)

Mandatory obligations

None — not a commercial product; no CE marking required

Voluntary alignment

This compliance document is produced voluntarily — dfetch has no legal obligation under the CRA — to support downstream integrators who must account for open-source components in their own Article 13 conformity assessments.

CRA Annex V — Technical Documentation Map

Annex V of Regulation (EU) 2024/2847 specifies the minimum content for a manufacturer’s technical documentation. The table below maps each Annex V element to the corresponding dfetch artifact or section. Because dfetch is outside mandatory CRA scope, this mapping is provided as a convenience for downstream integrators conducting their own Article 13 conformity assessments.

Annex V element

dfetch artifact / section

1. General description — intended purpose, product name and version, manufacturer address

Security Model § Product and manufacturer identification; Manifest (manifest schema and version field)

2. Design and development — software architecture; how components build on or feed into each other

Architecture (layer diagram and module overview); Security Documentation Pipeline § Threat model pipeline (security-relevant component relationships)

3. Production and monitoring — build pipeline, dependency management, CI/CD monitoring

Security Documentation Pipeline § Compliance pipeline and Release attestations; CI workflows in .github/workflows/

4. Cybersecurity risk assessment (Article 13(2)) — asset identification, threat analysis, risk treatment

dfetch Supply Chain (pre-install lifecycle); dfetch Runtime Usage (runtime invocation); see also Security Model § Risk Rating Methodology

5. Implemented security solutions and applied standards — list of harmonised standards applied; where not applied, description of how each Annex I requirement is met

This page (§§ Applicable Standards, Part I, Part II); Control Register (all 46 controls with references); OSCAL Component Definition security/dfetch.component-definition.json

6. EU Declaration of Conformity (Annex IV)

Not required. dfetch is outside mandatory CRA scope (see Classification Decision above). No CE marking is affixed.

Applicable Standards

Standard

Full title

Applies

Scope note

Gap

prEN 40000-1-2

Cyber Resilience Principles and Secure Development Lifecycle (working title; subject to change on publication)

Yes

Process standard covering risk-based product security across the lifecycle. The Product Security Context (§6.2) is documented in Security Model. Track A threat models (tm_supply_chain.py, tm_usage.py) implement §6.3–§6.6.

—

prEN 40000-1-3

Vulnerability Handling Requirements

Yes

Covers CRA Annex I Part II vulnerability handling obligations. Addressed in the Part II table below via SECURITY.md, SBOM (C-022), and dependency-review CI (C-016).

No formal patch SLA or LTS backport policy defined.

prEN 40000-1-4

Generic Security Requirements (draft, indicative publication October 2027)

Yes

Primary standard for this document. Maps CRA Annex I Part I Art. 2(a)–(m) to Security Objectives (SO.*) and Technical Controls (GEC-, SUM-, etc.). The catalog is included as security/cra_pren_4000014_oscal_catalog.json.

Standard is in draft; final clause numbering may change.

EN 18031-1/2:2024

Common security requirements for radio equipment (basis of prEN 40000-1-4)

Yes

prEN 40000-1-4 builds on EN 18031. Many technical controls (GEC-, SUM-, AUM-, SSM-, SCM-*) originate from EN 18031. dfetch’s applicability is assessed at the prEN 40000-1-4 SO level.

—

ETSI EN 303 645 V3.1.3

Cyber Security for Consumer Internet of Things

No

IoT-specific standard. dfetch is a developer CLI tool with no IoT device functionality, physical interfaces, or consumer IoT use case.

—

Part I — Product Security Requirements (ECR-a to ECR-m)

The table below summarises dfetch’s implementation of each prEN 40000-1-4 Security Objective per CRA essential requirement.

CRA ECR

SO (prEN 40000-1-4)

dfetch controls

Gaps

Status

ECR-A — Be made available on the market without known exploitable vulnerabilities.

SO.VulnerabilityManagementProcess

C-015, C-016, C-017, C-022, C-040, C-043

—

✓ Implemented

ECR-B — Be made available on the market with a secure by default configuration, including the possibility to reset the product to its original state.

SO.SecureDefaultConfiguration

C-001, C-002

Integrity hash verification (C-005) is opt-in; manifest entries without an integrity field are fetched without hash verification by default

⚠ Partial

SO.SecureStartupConfig

—

—

— N/A

SO.FactoryReset

—

—

— N/A

ECR-C — Ensure that vulnerabilities can be addressed through security updates, including automatic updates enabled by default, with an opt-out mechanism, user notification, and the option to postpone updates.

SO.Updateability

C-010, C-039, C-043

—

✓ Implemented

SO.AutomaticUpdates

—

—

— N/A

SO.UserUpdateNotification

—

—

✓ Implemented

SO.PostponeUpdates

—

—

— N/A

ECR-D — Ensure protection from unauthorised access by appropriate control mechanisms including authentication, identity or access management systems, and report on possible unauthorised access.

SO.AccessControl

C-006, C-036

dfetch has no native authentication or authorisation layer; access control is fully delegated to the underlying VCS server and host OS. C-006 prevents interactive credential prompts, and C-036 strips credentials from persisted metadata — both are confidentiality controls, not access-control mechanisms in the authentication/authorisation sense

⚠ Partial

SO.AccessControlReport

C-045

No persistent log of unauthorised access attempts

⚠ Partial

ECR-E — Protect the confidentiality of stored, transmitted or otherwise processed data by state-of-the-art mechanisms such as encryption at rest and in transit.

SO.DataStoredConfidentiality

C-036

—

✓ Implemented

SO.DataProcessedConfidentiality

C-005, C-034

—

✓ Implemented

SO.DataTransmittedConfidentiality

C-045

C-045 warns on plaintext-scheme URLs but does not refuse to proceed; TLS/SSH confidentiality is provided by the underlying VCS client, not enforced by dfetch itself

⚠ Partial

SO.ComAuth

C-045

Server authentication (TLS certificate verification, SSH host-key checking) is delegated to the OS trust store and VCS client; dfetch does not independently authenticate remote endpoints and cannot enforce authenticated channels when C-045’s warning is overridden by the user

⚠ Partial

SO.SecureProvisioning

C-005

—

⚠ Partial

ECR-F — Protect the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against unauthorised manipulation or modification, and report on corruptions.

SO.DataStoredIntegrity

C-005

Integrity hash opt-in only; not enforced by default for git/svn

⚠ Partial

SO.DataProcessedIntegrity

C-005, C-034

—

✓ Implemented

SO.DataTransmittedIntegrity

C-005

C-005 provides end-to-end hash verification for archive sources only (opt-in); git and svn sources rely solely on VCS object integrity (SHA-1/SHA-256 object model) and TLS/SSH channel integrity — no dfetch-level hash verification

⚠ Partial

SO.IntegrityReport

C-045

No persistent integrity-violation log

⚠ Partial

ECR-G — Process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation).

SO.DataMinimization

C-044

—

✓ Implemented

ECR-H — Protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks.

SO.IncidentRecovery

—

—

— N/A

SO.IncidentResilience

C-002, C-007

No timeout on VCS operations (potential resource exhaustion)

⚠ Partial

ECR-I — Minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks.

SO.LimitExternalImpact

C-001, C-007

Archive HTTP operations time out at 15 s (reachability) and 60 s (download) via archive.py; git and svn subprocess calls have no timeout and can stall indefinitely

⚠ Partial

SO.PreventAttackPropagation

C-001, C-008

—

✓ Implemented

SO.MonitorExternalImpact

—

—

— N/A

ECR-J — Be designed, developed and produced to limit attack surfaces, including external interfaces.

SO.ReduceAttackSurface

C-001, C-003, C-004, C-007, C-008

No domain or URL-scheme allowlist constrains which remote URLs the manifest may reference; git and svn subprocess calls have no timeout (archive HTTP operations time out at 15 s / 60 s)

⚠ Partial

ECR-K — Be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques.

SO.ReduceImpactOfIncident

C-005, C-007, C-015, C-017, C-046

—

✓ Implemented

ECR-L — Provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user.

SO.LogSecurityRelevantActivities

—

No persistent structured security event log (LGM-1/2/3/4 gap). dfetch prints operational output to stderr but does not retain it, does not record which credentials were used, which files were modified, or when remote access occurred. C-036 ensures credentials are excluded from operational output but is not a logging control

⚠ Partial

SO.MonitorSecurityRelevantActivities

C-045

—

⚠ Partial

SO.OptionDisableDataLogging

—

—

— N/A

SO.OptionDisableDataMonitoring

—

—

— N/A

ECR-M — Provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner.

SO.SecureDataDeletion

—

—

✓ Implemented

SO.DataTransmittedConfidentiality

—

—

— N/A

SO.DataTransmittedIntegrity

—

—

— N/A

SO.ComAuth

—

—

— N/A

Notes on “Implemented” rows

ECR-C SO.Updateability — SUM-1/SUM-2 require the manufacturer to make security updates available through a secure channel. dfetch publishes every release to PyPI (TLS-protected, OIDC-authenticated via C-010) and GitHub Releases (with release attestations per C-039). The CVE gate (C-043) blocks release if known vulnerabilities are present in runtime dependencies. Providing the update mechanism is the manufacturer’s obligation under SUM-1/SUM-2; delivery to the end user is the responsibility of the user’s package manager.

ECR-C SO.UserUpdateNotification — dfetch check and dfetch environment both call newer_version_available() (dfetch/util/github_version_check.py), which polls the GitHub releases API and prints a notice if a newer dfetch release exists. dfetch check suppresses the call when the CI environment variable is set (check.py line 102: if not os.environ.get("CI")); dfetch environment does not apply this guard and always performs the check.

ECR-M SO.SecureDataDeletion — No dfetch-specific control is needed. DLM-1 is satisfied by design: dfetch stores no personal data, credentials, or cryptographic keying material on disk. The only on-disk state is .dfetch_data.yaml (non-sensitive dependency metadata — credentials stripped by C-036) and vendored source files (third-party code). Standard OS file deletion (rm / del) is sufficient to remove all dfetch data; no secure-wipe facility is warranted.

Part II — Vulnerability Handling (prEN 40000-1-3)

Part II requirements are addressed via prEN 40000-1-3. pii-04 is not applicable under Recital 18.

CRA ref

Requirement

dfetch controls

Gaps

Status

Part II §1

Identify and document vulnerabilities and components (SBOM).

C-021, C-022

—

✓ Implemented

Part II §2

Address vulnerabilities without delay; provide free security updates.

C-015, C-016, SECURITY.md

No LTS backport policy (latest release only — documented in SECURITY.md)

⚠ Partial

Part II §3

Apply effective coordinated vulnerability disclosure (CVD) policy.

SECURITY.md

—

✓ Implemented

Part II §4

Report actively exploited vulnerabilities to national CSIRT and ENISA.

—

—

— N/A

Part II §5

Publish coordinated vulnerability disclosure policy.

SECURITY.md

—

✓ Implemented

Part II §6

Share information on vulnerabilities in integrated components.

C-022, C-016

No proactive downstream notification process

⚠ Partial

Part II §7

Provide security updates free of charge for the support period.

MIT licence, PyPI, SECURITY.md

—

✓ Implemented

Gap Analysis — Compliance-Only Controls

3 compliance-only controls address CRA requirements not independently covered by the Track A risk models.

C-043 — Release-gate CVE check (ECR-a, SO.VulnerabilityManagementProcess → GEC-1)

dfetch’s CI detects vulnerabilities at commit time (C-015, C-016, C-017). C-043 completes the coverage: the publish workflow runs pip-audit against the project’s runtime dependencies via the OSV database and blocks the release if any known vulnerability is found.

C-044 — Data minimisation policy (ECR-g, SO.DataMinimization → DTM-1)

dfetch processes dependency metadata only. The .dfetch_data.yaml file stores: remote_url (credentials stripped by C-036), revision, optional integrity.hash, and last_fetch timestamp. Each field is functionally necessary for dfetch check and dfetch freeze. No personal data is collected; no telemetry is sent. C-044 formalises this assertion as a documented policy.

C-046 — Exploit mitigation inventory (ECR-k, SO.ReduceImpactOfIncident → GEC-11)

prEN 40000-1-4 ECR-k requires documenting applicable exploit mitigation techniques. For dfetch (pure Python):

  • ASLR / DEP / stack canaries: provided by CPython and the OS; not in dfetch’s control but inherited.

  • No eval/exec of remote content: dfetch never evaluates fetched content as code.

  • Constant-time comparison (C-005): HMAC-based integrity hash uses hmac.compare_digest.

  • No shell injection (C-007): all subprocess calls use shell=False.

  • Input validation (C-008): URL scheme, path, and revision inputs are validated.

  • Static analysis (C-015, C-017): CodeQL and bandit gate every commit.

  • CFI, sandboxing, and signed-execution policies are not applicable to a pure-Python tool.

OSCAL Artifacts

OSCAL (Open Security Controls Assessment Language) is a NIST-published JSON/XML schema set for machine-readable security documentation. It lets GRC tools, conformity-assessment toolchains, and downstream integrators ingest dfetch’s control evidence programmatically — rather than reading prose — and map it to their own compliance frameworks.

dfetch ships two OSCAL 1.2.2 artifacts alongside the source:

Both files are regenerated with:

python -m security.compliance \\
    --component security/dfetch.component-definition.json \\
    --version 0.15.0 \\
    --rst > doc/explanation/compliance_track.rst