PUBLIC INTAKE
Researchers report. They are not treated as attackers.
The public CVD intake is separated from internal management. Reports are validated, bounded and admitted with a unique tracking and receipt structure.
COORDINATED VULNERABILITY DISCLOSURE · GOVERNANCE · PROOF
A vulnerability report is not an inbox event. It is a provable security process.
Security research needs a safe intake path. Institutions also need durable evidence of when a report arrived, how it was assessed, who authorized each state transition, when remediation was verified, and under which conditions coordinated disclosure occurred. immo.quick binds that lifecycle as governed CVD & Proof Closure.
Attack ≠ vulnerability report. Report ≠ confirmation. Status ≠ truth. Every stronger claim requires an authorized, proof-bound transition.
GOVERNED STATE
No free-form status field.
State changes follow a server-enforced transition graph. Invalid jumps are denied; valid transitions create immutable transition receipts or governance events.
PROOF CLOSURE
Not only when. Also what and why.
Canonical submission hash, policy and receipt version, integrity binding, transition authority, reason and chain link turn the process into a forensic proof path.
REPORT → ADMISSION → FORENSIC RECEIPT → GOVERNED STATE → AUTHORIZED TRANSITION → REMEDIATION → VERIFICATION → COORDINATED DISCLOSURE
IMMO.QUICK CORE
Governed CVD State & Causality
Core treats a vulnerability report as governed institutional state. Immutable governance events bind each relevant transition to actor, authorization basis, prior state, next state and a cryptographic event chain. Reporter claims remain separated from internally validated facts.
- Hard gates and advisory checks remain semantically separate.
- Manufacturer-first is routing, not automatic rejection.
- Severity: reporter ≠ machine triage ≠ binding internal classification.
- Official reporting channels are abstracted rather than replicated.
SERVERLESS EDITION
CVD Governance & Proof Closure
The Serverless Edition physically separates public CVD intake from internal management, enforces state transitions server-side, and binds each valid transition to an immutable receipt. Public submissions are hardened; tracking requires both report ID and a high-entropy token.
- 100 KB body limit, per-field limits, enum and control-character validation.
- HMAC-based IP pseudonymization with a server-side secret.
- Server-enforced transition graph; invalid state jumps are rejected.
- Forensic receipt binds content, policy version, receipt version and integrity.
Why this matters to regulators and supervisors.
Regulatory value does not come from software replacing a regulator. It comes from an institution not having to merely assert that a vulnerability was handled correctly. Intake, case governance, authorization of critical transitions, remediation, fix verification and actual use of an official reporting channel can be treated as separate, inspectable states.
Claim boundary: The CVD infrastructure is aligned with the BSI CVD principles. This does not constitute testing, certification, recognition, a conformity statement or any other endorsement by the BSI. BSI coordination status may only be asserted when the BSI is actually involved. The Serverless architecture was demonstrably submitted to the BSI on 28 July 2026; immo.quick Core was not submitted to the BSI.
RESPONSIBLE DISCLOSURE
Security research needs a safe, traceable disclosure path.
Operational CVD submission is designed as a separate public system path and is isolated from internal management. This website explains the governance and proof model; it does not replace the operational submission interface of the system.
FAQ · CVD GOVERNANCE
In brief
What is CVD Governance & Proof Closure?
An evidence-bound lifecycle for intake, triage, authorized state transitions, remediation, fix verification and coordinated disclosure of a vulnerability report.
Is a CVD report an attack?
No. Attack forensics and cooperative vulnerability disclosure are separate processes and separate event models.
Is the CVD infrastructure certified by the BSI?
No. It is aligned with BSI CVD principles. This does not constitute testing, certification, recognition or a conformity statement by the BSI.
What can be externally verified?
The architecture separates intake receipt, canonical submission hash, policy and receipt versions, transition authority and immutable state sequence. Which artifacts are made public remains a separate disclosure decision.