Vulnerability Disclosure Policy
How we coordinate with vendors, when we publish and how external security researchers can obtain a CVE ID through us.
Last updated: November 1, 2026
Contact: [email protected]
Embargo: 90 days
Scope
This policy describes how turingpoint coordinates vulnerability disclosure and assigns CVE IDs. It covers:
- vulnerabilities turingpoint finds itself, in its own research or during penetration tests
- vulnerabilities external security researchers report to turingpoint so that we coordinate disclosure and assign a CVE ID
- vulnerabilities in turingpoint’s own systems
Reporting a Vulnerability
We accept reports by email only, at [email protected], in English or German. For encrypted reports, use one of the S/MIME certificates listed in our security.txt and write to the corresponding address directly.
Note: Once turingpoint is admitted as a CVE Numbering Authority (CNA), we will additionally provide a form for reports and CVE requests. We are seeking admission under the European root of the EU Agency for Cybersecurity (ENISA): vulnerabilities should be recorded and coordinated in Europe to strengthen Europe’s digital sovereignty.
A report should include:
- vendor and product, affected versions and, if known, the fixed version
- vulnerability type, ideally with a CWE
- reproduction: steps or proof of concept, preconditions and required privileges
- impact, optionally with a CVSS vector
- whether the vendor has already been notified
- whether a CVE ID has already been requested
- how you would like to be credited: name, handle, organization or anonymous
Requests come with no strings attached: no non-disclosure agreement, no transfer of rights, no engagement required.
Response Times
| Step | Time |
|---|---|
| Acknowledgement | 3 business days |
| Initial assessment: accepted, declined or follow-up questions | 10 business days |
| Status update to the reporter during coordination | at least every 30 days |
All responses are editorially reviewed.
Assessment
We request a CVE ID only if we were able to reproduce the vulnerability or the report contains sufficient evidence. In particular, we do not accept:
- reports without a reproducible proof of concept, as well as unverified scanner output or automatically generated reports
- behavior without security impact, such as missing security headers without a concrete attack
- denial of service by volume alone (brute force, resource exhaustion)
- attacks requiring physical access, unless the product is meant to protect against exactly that
- outdated dependencies without evidence that the product itself is vulnerable
- products that are not publicly available, such as custom software of individual companies
We explain every rejection.
Coordination with the Vendor
- First, we check whether the vendor is a CNA or the product falls within a CNA’s scope. If so, we report there or refer you to it.
- Otherwise, we notify the vendor through its security contact. If you have already contacted the vendor, we join the ongoing communication.
- We share your contact details with the vendor only with your consent and process them solely for coordination, see our privacy policy.
Embargo: 90 Days
We publish technical details once a fix is available, but no later than 90 days after first notifying the vendor.
- Fix before the deadline: publication is coordinated with the vendor, usually shortly after the release.
- Fix in progress: if the vendor is demonstrably working on a fix and names a date, we extend once by up to 30 days.
- No response: before publishing without a vendor response, we try to reach the vendor through at least two channels, such as security.txt, support or a responsible CERT.
- Active exploitation: if the vulnerability is demonstrably exploited or already public, we publish earlier so that affected users can protect themselves.
We ask reporters whose findings we coordinate to observe the same deadline.
CVE IDs
- If the vendor is a CNA or the product falls within a CNA’s scope, that CNA assigns the CVE ID. Otherwise, we request it from a suitable CNA, such as GitHub for open-source projects hosted there.
- Before every request, we check whether an ID has already been requested elsewhere to avoid duplicates.
- Each independently fixable vulnerability receives its own CVE ID.
- We share the CVE ID with the reporter and the vendor as soon as it is available.
- The public reference is the vendor’s advisory, the reporter’s advisory or our own under Advisories.
- On request, we credit reporters in the advisory and in the CVE request.
Findings from Client Engagements
Many of our findings come from penetration tests. Vulnerabilities in publicly available third-party products are disclosed under this policy, without reference to the client. We do not publish vulnerabilities in our clients’ custom software or systems.
Disagreements
If you disagree with a decision, such as a rejection or the content of a CVE Record, write to [email protected]. If we cannot reach agreement, the CVE Program’s dispute process applies.