Product security incident response (PSIRT) runbook

Status: Template — to be reviewed by the controller's DPO / counsel. Draft of 2026-10-13. The tabletop exercise in section 11 has not been run yet.

Quavon UG (haftungsbeschränkt) is the manufacturer of CodeLotse under Regulation (EU) 2024/2847 (CRA) and, for the hosted edition, a processor under the GDPR. This runbook covers vulnerabilities in CodeLotse and security incidents affecting the product or the hosted service. Policy and fix targets: vulnerability handling policy.

1. Roles

Role	Responsibilities
PSIRT lead	Owns the case: triage, severity, decisions, CRA reports, publication. Keeps the case log
Engineering owner	Reproduces, fixes on a private branch, writes regression tests, prepares the release
Operations lead (hosted)	Mitigates and deploys in the hosted edition; collects logs; checks for exploitation
Reporter liaison	Keeps the reporter informed (SECURITY.md commitments), agrees on the disclosure date and credit
Legal / DPO	Personal-data breaches (GDPR Art. 33: supervisory authority within 72 h, if Quavon UG (haftungsbeschränkt) is controller; as processor: notify the customer without undue delay per the DPA); reviews CRA reports and customer notices

One person can hold several roles. A deputy is named for the PSIRT lead. Contacts are kept in the internal on-call list, not in this repository.

2. Intake

1. Channels: security@quavon.de, GitHub private vulnerability reporting (POST /repos/{owner}/{repo}/security-advisories/reports, which creates a triage advisory), internal detection (scanners, alerts, tests, customer support).
2. Within 1 business day: open a draft repository security advisory (section 6) and the case log. Record the time of awareness in UTC. All CRA deadlines run from the moment Quavon UG (haftungsbeschränkt) becomes aware that a vulnerability is actively exploited or that a severe incident happened — not from the first report.
3. Acknowledge the report within 2 business days; first assessment within 5 business days (SECURITY.md).

3. Triage and severity

1. Reproduce on the latest release and on main. Identify affected versions and editions.
2. Score with CVSS v4.0; record the vector. Adjust for defaults (opt-in features, edition).
3. Answer and record immediately, with the reasons:
   • Is the vulnerability actively exploited (reliable evidence that a malicious actor exploited it in a system without the owner's permission)?
   • Is this a severe incident having an impact on the security of CodeLotse (for example compromise of the release pipeline, signing keys, the image registry or the hosted service, which affects the ability to protect data or functions, or leads to malicious code in the product)?
   • Is personal data affected (GDPR breach assessment)?
4. Fix targets: Critical or exploited 7 days, High 14, Medium 45, Low next release (policy, section 4).

4. CRA reporting (Art. 14, applies since 11 September 2026)

Applies to actively exploited vulnerabilities in CodeLotse and severe incidents having an impact on its security. Reports go through the ENISA Single Reporting Platform (SRP) to the CSIRT designated as coordinator in the Member State of the main establishment (Germany: BSI) and to ENISA at the same time. ENISA states that the SRP has no API at this stage: reports are entered by hand by a registered person. Register the PSIRT lead and a deputy before they are needed (<registration status>).

Step	Exploited vulnerability (Art. 14(2))	Severe incident (Art. 14(4))
Early warning	24 h from awareness. Include the Member States where CodeLotse is made available, where known	24 h. Include whether unlawful or malicious acts are suspected, and Member States
Notification	72 h from awareness (unless already given). General information on the product, the exploit and the vulnerability; corrective or mitigating measures taken and those users can take; how sensitive the information is	72 h. Nature of the incident, initial assessment, measures taken and available to users, sensitivity
Final report	≤ 14 days after a corrective or mitigating measure is available. Description including severity and impact; information on any malicious actor, where available; details of the security update or other measures	≤ 1 month after the notification. Detailed description including severity and impact; type of threat or root cause; applied and ongoing mitigation

Also, after becoming aware, inform affected users (and all users where appropriate) about the vulnerability or incident and the measures they can take, where appropriate in a structured, machine-readable format (Art. 14(8)). The published advisory (section 6) serves as the machine-readable notice; the customer notice (section 9) covers hosted customers and known self-hosted operators.

Sources: Art. 14 and Art. 71(2) of Regulation (EU) 2024/2847 (unofficial consolidation; Official Journal text on EUR-Lex); ENISA: the CRA Single Reporting Platform is launched. Re-check ENISA's SRP guidance before each report.

The SRP is not the place for vulnerabilities that are not exploited; those follow coordinated disclosure (section 7).

5. Containment and fix

1. Hosted edition: mitigate first (feature switch, configuration, WAF or network rule, key rotation with quavon keys rotate, revoking app credentials), then fix.
2. Fix on a private branch: a temporary private fork of the advisory (POST /repos/{owner}/{repo}/security-advisories/{ghsa_id}/forks) or a private branch in the internal repository. Include regression tests; add the class of issue to the threat model.
3. Review by a second engineer. Run the full gate set (lint, typecheck, unit, integration, red-team, secrets, licences, vulnerabilities).

6. GitHub security advisory workflow

REST endpoints (GitHub REST API "Repository security advisories"). The caller must be a repository admin or security manager (collaborators on an advisory can read and update it). Classic tokens need repo or repository_advisories:write; the fine-grained permission name is not stated on the reference page and is unverified ("Repository security advisories", read and write, is expected). Prefer the web interface for one-off actions; use the API for scripted steps.

Step	Call	Result
Draft advisory	POST /repos/{owner}/{repo}/security-advisories with summary, description, vulnerabilities[] (package.ecosystem, package.name, vulnerable_version_range, patched_versions), cwe_ids, severity or cvss_vector_string, credits	201, ghsa_id
Private fork for the fix	POST …/security-advisories/{ghsa_id}/forks	202; ready within minutes
Request a CVE	POST …/security-advisories/{ghsa_id}/cve (public repositories only)	202; GitHub as CNA assigns the CVE
Update	PATCH …/security-advisories/{ghsa_id} (credits replaces the whole array; collaborating_users, collaborating_teams)	200
Publish	PATCH …/security-advisories/{ghsa_id} with "state": "published"	Advisory public, GitHub Advisory Database review
Close without publishing	"state": "closed"	—

CodeLotse ships container images and a Helm chart; use ecosystem other with the image name unless an ecosystem fits (for example npm for a published package). Advisory text: advisories/template.md. Reference: GitHub REST API — repository security advisories.

7. Embargo and coordinated disclosure

• Agree the publication date with the reporter. Default: when the fixed release is available; at most 90 days after the report; earlier when exploitation is active.
• Until publication: details only in the advisory, the private fork and the case log. No public issues, commits with telling messages, or release notes before the release.
• If a third-party component is affected, notify its maintainer (CRA Art. 13(6)) and coordinate dates.

8. Release and publication

Order of steps:

1. Hosted edition: deploy the fix before publication (or at the latest at the same time), and verify it in production.
2. Release patched images and code for every supported line (support period); SBOMs attached (SBOM delivery).
3. Publish the advisory with affected and fixed versions, severity, mitigations and credit; the CVE appears with it.
4. Send the customer notice (section 9).
5. CRA final report when due (section 4).

9. Customer notification template

Subject: CodeLotse security advisory <GHSA id / CVE id> — <severity>

We have fixed a <severity> vulnerability in CodeLotse that affects <editions and versions>.

What happened: <one-paragraph description without exploit details>Impact: <what an attacker could do, preconditions>Exploitation: <we are not aware of exploitation / we are aware of active exploitation since …>Hosted edition: <fixed on <date, UTC>; no action needed / action needed: …>Self-hosted: upgrade to <version> or later. Until you can upgrade: <mitigation>. Your data: <no personal data affected / assessment and next steps under the data processing agreement>Details: <advisory URL>

Quavon UG (haftungsbeschränkt) — security team, security@quavon.de

10. After the incident

• Post-incident review within 10 business days: timeline (UTC), root cause, which controls failed or worked, follow-up issues with owners.
• Update the threat model and tests so the class of issue is covered; update this runbook if a step failed.
• Keep the case log, reports and evidence for at least 10 years (technical documentation, CRA Art. 13(13)).

11. Tabletop exercise

Duration about 90 minutes. Participants take the roles of section 1. A facilitator reads the injects and records decisions and times. No real reports are sent; the SRP steps are simulated with prepared forms.

Scenario: Monday 09:00 UTC, a researcher reports to security@quavon.de that a crafted pull request title makes the reply feature post a link to a foreign host despite the publisher's link allowlist (bypass of LLM05 controls). At 14:00 UTC, a hosted customer reports such links in three repositories that were not opened by the researcher.

Time (simulated)	Inject	Expected decisions
T+0 (09:00)	Report arrives with a proof of concept	Acknowledge; open draft advisory; case log; record awareness of the vulnerability (not yet exploitation); assign engineering owner
T+1 h	Engineering reproduces on main and the latest release; CVSS draft	Severity (likely High); affected versions; hosted check started
T+5 h (14:00)	Hosted customer reports links in repositories the researcher did not touch	Decide whether this is active exploitation — evidence from audit log and publish intents; if yes, record the new awareness time; the 24 h early-warning clock starts now
T+6 h	Operations proposes switching replies to approval mode for all hosted tenants	Mitigation decision; customer impact; audit entries
T+20 h	Early warning due at T+29 h	Early warning content drafted and "submitted" (Member States, suspicion of malicious acts)
T+2 days	Fix ready on the private fork with a regression test	Review; deploy to hosted first; release for supported lines; CVE request
T+3 days (≤ 72 h from exploitation awareness)	Notification due	Notification content: product, exploit, measures, sensitivity
T+3 days	Publication	Advisory published; customer notice sent; GDPR assessment (were personal data disclosed via links?)
T+17 days	Final report due (14 days after the fix became available)	Final report: severity, root cause, malicious actor information, update details
T+3 weeks	Post-incident review	Root cause in sanitiser; red-team corpus updated; threat-model row updated

Record: for each inject, who decided, when, and deviations from this runbook. The facilitator records the outcome.

Pass criteria: awareness times recorded; the three CRA deadlines computed correctly from the exploitation awareness time; hosted deployment before publication; customer notice and advisory consistent; GDPR assessment done.