Our Responsible Disclosure Policy

What is responsible disclosure?

Many hackers are simply enthusiasts that like to test security. They have no intention of hurting companies, but just want to test their skills and intelligence against real world systems. In most countries however, breaking into computer systems is illegal (trespassing or “computervredebreuk”), just like it is illegal to breaking into houses. The fact that you do not steal anything makes no difference. The fact that testing out security is illegal has made many hackers hesitant to come forward with information. They face the risk of prosecution if they report any important bugs they have found.

With a responsible disclosure policy, companies promise to not press charges against any hackers that disclose information in a responsible way. The policy thus gives explicit permission to security enthusiasts to test the IT security and cyber resilience of a company. Hackers get the opportunity to learn from real world systems. Companies with a responsible disclosure policy learn about weaknesses faster and earlier and gain a lot in security.

Our Disclosure Policy:

This policy outlines how the Project-Leraean (PL) handles responsible vulnerability disclosure to product vendors, customers, security vendors and the general public. PL will responsibly and promptly notify the appropriate product vendor of a security flaw with product(s) or service(s). The first attempt at contact will be through any appropriate contacts or formal mechanisms listed on the vendor Web site, or by sending an e-mail to security@, support@, info@, and [email protected] with the pertinent information about the vulnerability.

If a vendor fails to acknowledge PL initial notification within five business days, PL will attempt a second formal contact by a direct telephone call to a representative for that vendor. If a vendor fails to respond after an additional five business days following the second notification, PL may rely on an intermediary to try to establish contact with the vendor. If PL exhausts all reasonable means in order to contact a vendor, then PL may issue a public advisory disclosing its findings fifteen business days after the initial contact.

If a vendor response is received within the timeframe outlined above, PL will allow the vendor 4-months (120 days) to address the vulnerability with a security patch or other corrective measure as appropriate. At the end of the deadline, if a vendor is not responsive or unable to provide a reasonable statement as to why the vulnerability is not fixed, the PL will publish a limited advisory including mitigation in an effort to enable the defensive community to protect the user. We believe that by taking these actions, the vendor will understand the responsibility they have to their customers and will react appropriately. Extensions to the 120-day disclosure timeline will not be granted.

If a product vendor is unable to, or chooses not to, patch a particular security flaw, PL will offer to work with that vendor to publicly disclose the flaw with some effective workarounds. In no cases will an acquired vulnerability be “kept quiet” because a product vendor does not wish to address it. To maintain transparency into our process, we plan on publishing a summary of the communication we’ve had with the vendor regarding the issue. We hope that this level of insight into our process will allow the community to better understand some of the difficulties vendors have when remediating high-impact bugs. PL will make every effort to work with vendors to ensure they understand the technical details and severity of a reported security flaw.

PL will formally and publicly release its security advisories on our Web site. Only advisories listed on the website should be considered official PL advisories.