Responsible Disclosure Policy

Explained

While we make every effort to keep our systems secure, a vulnerability may go unnoticed. If you discover a (potential) vulnerability that could cause issues or data leaks, please report it to us. This helps us better protect our customers and systems.

What we ask of you

When reporting a vulnerability, we kindly request the following from you:

Share your findings by sending an email, if you want to share screenshots or a formal write-up you can send them along in PDF format.
Do not misuse the vulnerability or the problem which you have found. For example, do not download or delete data and never modify the data of others.
Do not disclose the problem to others until it is corrected. We ask you also not to publish any information until it has been read and verified by us. In this way we can help prevent the accidental release of sensitive information.
Provide accurate information in your reporting, including: Details of the findings, the risk classification, the steps to reproduce and the possible solution/best practices.
Do not send unnecessary messages or address groups of people with requests for updates or ask for rewards, for example.
After concluding your findings, you should delete all the sensitive information obtained during testing.

What we promise

When you follow this responsible disclosure process, we promise to:

analyse your report and respond after no more than 5 business days.
not take any legal action if you follow the disclosure process.
treat your report with strict confidentiality and not share your information or your report with any third party except when we are required to do so by law.
to keep you updated about the progress involved with fixing the problem.

We do not currently have a reward programme for reporting vulnerabilities.

Definition of a vulnerability

Sibelga considers a security vulnerability to be a vulnerability in our websites or infrastructure which affects the confidentiality, integrity and/or availability of these systems. Because this is a broad definition, we understand that it may raise questions about what is and is not considered a vulnerability for Sibelga.

What is NOT considered a vulnerability?

Auto-completion enabled or disabled on forms.
Missing cookie attributes on non-critical cookies, for example, missing HTTP-only flags on analytics cookies.
The presence or absence of HTTP headers, such as: X-Frame-Options, CSP, no-sniff, etc. Unless this is part of a recommendation regarding another vulnerability.
DNS dangling and subdomain take-over.
Certain low-risk vulnerabilities, or vulnerabilities which are already known. While these are vulnerabilities in themselves, they have already been fixed by SIBELGA or are an accepted risk.
Vulnerabilities of the same type, which are reported separately. For example, XSS in multiple parameters or unvalidated redirects in different locations. These are seen as the same vulnerability.

What is considered a vulnerability?

Unauthorised access to customer data, including but not limited to names, order information and further personal data.
Remote Code Execution (RCE).
Server-Side Request Forgery (SSRF).
Cross-site Scripting (XSS).
Cross-site Request Forgery (CSRF).
Injection attacks, such as SQL Injection (SQLi).
XML External Entity Attacks (XXE).
Access Control vulnerabilities (Insecure Direct Object Reference vulnerabilities, etc.).
Path/Directory traversal vulnerabilities.

When in doubt, please feel free to report a (potential) vulnerability to our team.

Reporting vulnerability

If you have found something which you think that we consider a vulnerability, or if you would like to bring something else to our attention, we ask that you do so by email. Other options are currently being explored.
Please contact us at: responsibledisclosure@sibelga.be

Privacy

Consult our privacy policy for more information as to how we handle your personal information.