Responsible disclosure policy

Our basic stance

Security vulnerabilities do not disappear because people keep quiet about them – and they do not become any safer because someone shouts them from the rooftops. Between the two lies coordinated disclosure: the vendor receives all the information first and in full, is given a fair deadline to fix the issue, and the public learns about it as soon as it can protect itself.

This policy describes our own procedure as the reporting party.

This policy is issued by Schweigert IT – owner: André Schweigert, Blumenstraße 27, 91481 Münchsteinach. Further details about the service provider can be found in the legal notice.

How we report vulnerabilities

In the course of our own security research, we come across vulnerabilities in third-party software, services and devices. In doing so, we follow a fixed, transparent procedure:

1. Initial report to the vendor We inform the vendor or operator first and exclusively – via the officially designated security contact, alternatively via security.txt, a security advisory programme or, if no such channel exists, via the general contact address. Encrypted transmission is offered.
2. Complete, reproducible description The report contains the affected version, preconditions, steps to reproduce, a technical classification and an assessment of the impact – everything needed for a fix.
3. Standard deadline of 90 days From the initial report, we generally grant the vendor 90 days until publication. If a fix is evidently complex, we extend this deadline by mutual agreement – provided there is demonstrable progress and open communication.
4. Publication only after a patch As a matter of principle, we publish details only once a patch, an update or at least an effective countermeasure is available and users can protect themselves.
5. No disclosure to third parties Until publication, we do not pass on information about the vulnerability to third parties. We do not sell vulnerabilities and do not take part in the trade in exploits.
6. No working exploits Publications contain the technical details needed for understanding and for independent verification, but no ready-to-use exploits, no weaponisation and no attack tools aimed at specific third parties.

Deadlines and publication in detail

The standard 90-day deadline is not applied automatically; it is a starting point. We weigh adjustments in both directions:

• An extension is granted if the vendor is actively working on a solution, a concrete schedule exists and communication remains open. An extension is agreed in writing.
• A shortening may be considered if the vulnerability is demonstrably already being actively exploited or becomes publicly known independently of us. In this case, the users’ interest in protection prevails; we inform the vendor of the shortening in advance.
• No response from the vendor does not release us from our duty of care. In that case, we first escalate via a coordinating body (e.g. a national CERT or the BSI) and only publish afterwards – and even then without a working exploit.

Publications take the form of an Advisory or a technical article on this website. On request, we coordinate the timing and wording with the vendor and reference the vendor’s own security notice.

Legal framework of our tests

schweigertIT carries out penetration tests, vulnerability assessments and comparable security audits exclusively on the basis of a written engagement with a defined scope. Without such an engagement, not a single system is touched.

This is not a formal precaution but a legal necessity: data espionage (§ 202a StGB), interception of data (§ 202b StGB), preparing data espionage and interception of data (§ 202c StGB), data tampering (§ 303a StGB) and computer sabotage (§ 303b StGB) are criminal offences. Acts that meet the elements of these offences are punishable without the consent of the entitled party. Only the effective consent of the party with authority to dispose of the target systems makes a security audit permissible.

Before testing begins, we therefore routinely clarify and document:

• Engagement and authorisation – a written test authorisation (“Authorization to Test”) from a person authorised to sign on behalf of the client.
• Authority to dispose – proof that the client is actually entitled to dispose of the systems, domains and IP ranges named in the scope.
• Third-party infrastructure – involvement and consent of the hosting provider or cloud provider if target systems are operated by third parties.
• Rules of Engagement – scope boundaries, testing time windows, permitted testing depth, escalation paths and emergency contacts.
• Handling of personal data – where necessary, a data processing agreement under Art. 28 GDPR.

The contractual details are governed by our General Terms and Conditions, which we send you together with our quotation.