VayuPress Docs
Docs

EU Cyber Resilience Act — readiness assessment

Status: working assessment, not legal advice. Dates and obligations below should be checked against the current text of Regulation (EU) 2024/2847 before anything is relied on, and a lawyer consulted if VayuPress ever earns revenue in the EU beyond donations.

Assessment date: 2026-07

Why this document exists

The Cyber Resilience Act is the first regulation that attaches security obligations to software itself rather than to the organisation deploying it. It matters to VayuPress for two separate reasons, and the second is the one that will actually be felt.

First, VayuPress may or may not be in scope. The analysis below concludes it is most likely out of scope today, with one condition that could change that.

Second — and independent of the first — VayuPress's users are in scope. A company in the EU that deploys VayuPress on its own infrastructure has obligations of its own, and will discharge some of them by asking upstream: give me an SBOM, tell me your support period, show me your vulnerability-disclosure process, prove your releases are signed. A project that can answer those in one link wins deployments from projects that cannot. That is true whether or not the CRA ever applies to this repository directly.

So the useful posture is not "are we obliged" but "can we answer". Most of the answer already exists; this document says where the gaps are.

Timeline

Date What applies
10 December 2024 Regulation entered into force
11 June 2026 Provisions on notified bodies apply
11 September 2026 Reporting obligations for actively exploited vulnerabilities and severe incidents apply
11 December 2027 Full application — all remaining obligations

The September 2026 date is the near one and is the one to plan against.

Scope assessment

The CRA applies to "products with digital elements" made available on the EU market in the course of a commercial activity. Free and open-source software supplied outside a commercial activity falls outside the manufacturer regime.

The regulation also creates a lighter-touch category — the open-source software steward — for legal entities providing sustained support to open-source products intended for commercial use. That category is defined in terms of legal persons; a natural person publishing a project is a different situation again.

Applied to VayuPress today:

Factor Position
Published as open source under Apache-2.0 Yes
Sold, licensed for a fee, or offered as a paid service No
Paid support contracts No
Monetised through the software (ads, data, upsell) No — telemetry is opt-in, off by default, and transmits nothing about the operator
Funded by Donations
Published by A natural person, not a company

Conclusion: most likely outside the manufacturer regime. Donations given without an intention of profit generally do not constitute commercial activity for this purpose.

The condition that would change it. Charging for VayuPress in any form — hosted service, paid support, a paid tier, a commercial licence — very likely brings the offering inside scope as a manufacturer, with CE marking, conformity assessment and technical documentation attached. This is worth knowing before any decision to monetise, not after, because the compliance cost is a real input to that decision and is easy to discover too late.

Gap analysis

What the manufacturer regime asks for, and where VayuPress stands. Marked against what a downstream commercial user will ask for, since that is the binding constraint either way.

Requirement Status Where
Coordinated vulnerability disclosure policy Have SECURITY.md — contact, SLAs by CVSS band, no-public-issue rule, advisory process
Software bill of materials Have .github/workflows/sbom.yml — CycloneDX via cyclonedx-gomod, on every push and weekly
Vulnerability scanning in CI Have govulncheck on every push, weekly schedule, and as a release gate
Signed releases / integrity verification Have cosign signing in tag-release.yml and release.yml
Per-file licence identification Have SPDX headers on every Go file, gated in CI
Security-by-default configuration Have Deny-by-default posture recorded in GOVERNANCE-CONSTITUTION.md; no telemetry in core
Documented change history Have CHANGELOG.md, maintained per release
Defined support period Have SECURITY.md — current minor in full support, previous minor critical-only with an end date, and an explicit statement that the CRA's five-year default is not met, with the reasons it is not claimed
SBOM published with releases Have release.yml and tag-release.yml generate a CycloneDX SBOM per release, cosign-sign it, and attach both to the GitHub Release
Machine-readable security contact Have docs/site/.well-known/security.txt, RFC 9116, with the Expires field stamped at deploy time so it cannot go stale
Vulnerability reporting route to ENISA/CSIRT Gap, conditional Only applies if in scope, which on the assessment above it is not. No process exists for the 24-hour early-warning / 72-hour notification path that would apply from September 2026

Done

  1. Supported-versions policy rewritten (SECURITY.md). The table described the 1.0.x series while the project was at 3.15.x, which reads as neglect and is worse than saying nothing. It now names the real window — current minor in full support, previous minor critical-only with an end date — and states plainly that the CRA's five-year default is not met, because a single-maintainer donation-funded project should not claim a support term it cannot honour. What it offers instead is the thing that does not depend on goodwill: signed tags, an irrevocable Apache-2.0 grant, and an SBOM per release, so anyone needing a longer horizon can maintain a fork without asking permission.

  2. SBOM attached to every release, in both release.yml and tag-release.yml, and cosign-signed — an unsigned inventory beside a signed binary is a gap, because swapping it leaves the artefact still verifying.

  3. security.txt published at /.well-known/security.txt. RFC 9116 requires an Expires field, and an expired file is reported as stale by the scanners that read it, so a committed date would eventually become a finding rather than prevent one. deploy-site.yml stamps it 180 days out at deploy time and also runs daily on a schedule, so it refreshes itself.

Remaining

  1. Record the scope position. This document is that record. Revisit it if the funding model ever changes — that is the single trigger that moves VayuPress from "out of scope" to "in scope as a manufacturer".

  2. Do not pursue CE marking or conformity assessment. Not applicable to a non-commercial open-source project, and starting it would imply a manufacturer status that does not apply.

  3. No ENISA/CSIRT reporting path exists, and none is being built while the scope assessment holds. If VayuPress is ever monetised, this becomes required from the September 2026 date and is the largest single piece of work in this document.

What this does not cover

  • VayuMail-Mobile is a separate distributed product and would need its own assessment. A mobile application distributed through an app store has a different scope analysis to a self-hosted server binary.
  • Operators of VayuPress installations carry their own obligations under NIS2, the GDPR and potentially the CRA as deployers. Nothing here transfers to them or relieves them.
  • The legal question of what counts as commercial activity is genuinely unsettled at the margins, particularly for donation-funded projects with a single maintainer. The position taken above is the reasonable reading, not a settled one.

See also