Security policy

cratly is free and open-source software. Its source is public and its use is not charged for. cepharum GmbH develops it and supports it on a lasting basis, and in doing so acts as its open-source software steward under the EU Cyber Resilience Act (Regulation (EU) 2024/2847, Article 24). This page is the cybersecurity policy that Article asks a steward to keep: how vulnerabilities in cratly are found, reported, fixed and made known. The reasoning behind it is in ADR 0009.

Scope

Every project in the cratly group on gitlab.com: the editor, the reference adapter scavold, the site templates, the CI image and pipeline templates, cratly.stream, and the specifications published on this site.

Not in scope are the websites built with cratly. Their content, their hosting and the dependencies each of them adds are their owner's responsibility, as is keeping their dependency on cratly up to date.

Reporting a vulnerability

Please report it privately, not in a public issue:

• open a confidential issue in the affected project on gitlab.com — the checkbox sits below the description — or
• write to security@cepharum.de.

Useful to include: the affected project and version, what an attacker can achieve, and the steps that show it. A report of a vulnerability in one of cratly's dependencies is welcome too, when cratly is how it reaches its users; we pass it on upstream where that has not happened yet.

How a report is handled

1. Receipt. We confirm that the report arrived, and assess whether and how far it affects cratly.
2. Fix. A confirmed vulnerability is fixed in a release of its own, published without waiting for other changes. Until 1.0.0, only the latest release of a project receives fixes; there are no backports to earlier pre-releases.
3. Disclosure. Once the fixing release is published, its changelog names the vulnerability, the affected versions and, unless they prefer otherwise, the person who reported it. Where it helps users, a CVE is requested.

We keep the reporter informed along the way and agree with them before anything is disclosed earlier.

Actively exploited vulnerabilities

A vulnerability in cratly that is known to be actively exploited is notified through the single reporting platform that ENISA runs under Article 16, which forwards it to the CSIRT designated as coordinator — for cepharum, as an organisation established in Germany, the BSI:

• an early warning within 24 hours of becoming aware of it,
• a notification with a first assessment within 72 hours,
• a final report within 14 days of a corrective measure being available.

The same applies to a severe incident affecting the infrastructure cratly is developed on, with the final report due within one month. Users are informed of the vulnerability and of what they can do about it as soon as that is possible without endangering them further.

Knowing what cratly ships

• Dependencies are kept few and chosen for being maintained.
• Known vulnerabilities are looked for continuously. Projects distributed as packages check their runtime dependencies against the advisory database in every release pipeline and in a weekly scheduled pipeline; a finding is fixed by a release.
• Every release carries an SBOM. A CycloneDX software bill of materials of what a package brings along is kept with each release pipeline — for scavold from 0.2.0-rc.8 onwards. How to get it is in each project's SECURITY.md.

Authorities

cepharum cooperates with market surveillance authorities on request, to mitigate a cybersecurity risk posed by cratly.