Vulnerability handling policy ​
Status: Template — to be reviewed by the controller's DPO / counsel. Draft of 2026-10-13; not reviewed yet.
Quavon UG (haftungsbeschränkt), as manufacturer of CodeLotse, handles vulnerabilities according to this policy. It implements Annex I Part II of Regulation (EU) 2024/2847 (CRA) and the reporting duties of Art. 14. The operational steps are in the PSIRT runbook.
1. Scope ​
The CodeLotse source code in this repository, the released container images and deployment files (Compose, Helm), and the hosted edition. Third-party services CodeLotse connects to (Git hosts, model providers) are out of scope; vulnerabilities found in them are passed on to their owners.
2. Principles (Annex I Part II) ​
| # | Requirement | How CodeLotse meets it | Evidence |
|---|---|---|---|
| 1 | Identify and document components and vulnerabilities, including an SBOM | CycloneDX SBOM per image and for the source tree; dependency and image scanning | sbom-delivery.md, ci.yml |
| 2 | Address and remediate vulnerabilities without delay, including by security updates | Fix targets by severity (section 4); security fixes separate from feature releases where possible | psirt.md |
| 3 | Regular, effective tests and reviews of security | Threat model updated with every change that adds an entry point, write path or agent capability, with mitigations mapped to tests; red-team and isolation suites; secret, licence and vulnerability gates | threat-model.md |
| 4 | Publicly disclose fixed vulnerabilities once an update is available | GitHub security advisories with CVE, affected and fixed versions, severity and mitigations | advisory template |
| 5 | Coordinated vulnerability disclosure policy | SECURITY.md | — |
| 6 | Facilitate sharing of information, including a contact address | security@quavon.de and GitHub private vulnerability reporting | SECURITY.md |
| 7 | Secure distribution of updates | Images by digest; signing and provenance planned with the release pipeline | sbom-delivery.md |
| 8 | Security updates disseminated without delay, free of charge, with advisory messages | Patch releases within the supported lines; advisory per fix | support-period.md |
Dependency updates are proposed by Dependabot (dependabot.yml); known vulnerabilities in dependencies are tracked with OSV-Scanner and an expiring allowlist (vulnerabilities.yaml).
3. Receiving reports ​
- Reports go to
security@quavon.deor GitHub private vulnerability reporting. Acknowledgement within 2 business days, first assessment within 5 business days (SECURITY.md). - Reporters acting in good faith under this policy are not pursued; Quavon UG (haftungsbeschränkt) credits them in the advisory unless they prefer otherwise.
- Reports about third-party components are passed on to the maintainer (Art. 13(6)) and fixed in CodeLotse where possible.
4. Severity and fix targets ​
Severity is rated with CVSS v4.0 and adjusted for the deployment (self-hosted versus hosted, default configuration versus opt-in feature).
| Severity | Fix target (release available) | Hosted edition |
|---|---|---|
| Critical (9.0–10.0) or actively exploited | 7 days | Mitigation within 24 hours |
| High (7.0–8.9) | 14 days | Fix deployed before publication |
| Medium (4.0–6.9) | 45 days | Next deployment |
| Low (0.1–3.9) | Next regular release | Next deployment |
5. Reporting to authorities (Art. 14, applies since 11 September 2026) ​
For actively exploited vulnerabilities and severe incidents having an impact on the security of CodeLotse, Quavon UG (haftungsbeschränkt) notifies, through the ENISA Single Reporting Platform, the CSIRT designated as coordinator in the Member State of its main establishment (Germany: BSI) and ENISA at the same time:
| Report | Actively exploited vulnerability (Art. 14(2)) | Severe incident (Art. 14(4)) |
|---|---|---|
| Early warning | Within 24 hours of becoming aware; Member States where the product is made available | Within 24 hours; whether unlawful or malicious acts are suspected; Member States |
| Notification | Within 72 hours; general information on the product, the exploit and the vulnerability, corrective or mitigating measures taken and available to users, sensitivity of the information | Within 72 hours; nature of the incident, initial assessment, measures taken and available to users, sensitivity |
| Final report | No later than 14 days after a corrective or mitigating measure is available: description including severity and impact, information on any malicious actor, details of the security update or other measures | Within one month after the notification: detailed description including severity and impact, type of threat or root cause, applied and ongoing mitigation |
Affected users — and all users where appropriate — are informed about the vulnerability or incident and the measures they can take, where appropriate in a structured, machine-readable format (Art. 14(8)). Sources: Art. 14 (unofficial consolidation of the Official Journal text), ENISA: the CRA Single Reporting Platform is launched. ENISA states that the platform provides no API at this stage; reports are entered by hand.
6. Disclosure ​
Coordinated disclosure: Quavon UG (haftungsbeschränkt) publishes an advisory when a fixed release is available, or after 90 days if no fix is possible, with mitigations. The reporter is told the publication date in advance. Active exploitation can shorten the embargo.
7. Review of this policy ​
Yearly and after every post-incident review.