1. Introduction

At Billie, security and trust are fundamental to how we build and operate our services.

Despite our best efforts, security vulnerabilities may still occur. If you believe you have identified a vulnerability affecting a Billie service or application, we encourage you to report it to us responsibly so we can investigate and address it as quickly as possible.

This policy explains:

• how to report vulnerabilities to Billie;
• which systems are in scope;
• the rules for conducting security research;
• and how Billie handles reported vulnerabilities.

This policy forms part of Billie GmbH’s coordinated vulnerability disclosure framework established in accordance with applicable cybersecurity and operational resilience requirements, including the EU Cyber Resilience Act (CRA).

2. Reporting a Vulnerability

If you believe you have identified a security vulnerability, please contact us using one of the following channels:

• Email: [email protected]
• PGP Key: https://billie.io/.well-known/openpgpkey/hu/g5gwkdcmobphsnqnboxbhu1edf98x87x
• security.txt: https://billie.io/.well-known/security.txt

To help us investigate your report efficiently, please include:

• a clear description of the issue;
• the affected service, domain, API, or endpoint;
• potential impact and exploitation scenario;
• steps to reproduce the issue;
• and any relevant screenshots, logs, proof-of-concept code, or supporting material.

Optionally, you may also include:

• your preferred contact details;
• or a public researcher handle if you would like to be credited.

3. Scope

This policy applies to Billie-owned public-facing systems, applications, APIs, and services listed in Appendix 1.

Only assets explicitly listed in Appendix 1 are considered in scope.

The following are excluded from scope unless explicitly listed otherwise:

• internal systems and employee-only environments;
• development, staging, testing, and sandbox systems;
• third-party platforms and providers not operated by Billie;
• physical infrastructure and office environments;
• and systems requiring unauthorised access methods.

4. Rules for Security Research

We welcome good-faith security research that helps improve the security of our services.

When conducting research under this policy, we ask that you:

• act responsibly and avoid causing harm;
• only access data belonging to your own test accounts;
• avoid privacy violations, data destruction, or modification of information;
• avoid disrupting services or affecting other users;
• stop testing immediately if you encounter sensitive data;
• report findings promptly;
• and avoid public disclosure until the issue has been resolved or disclosure has been coordinated with Billie.

If sensitive data is accessed unintentionally during testing, it must not be stored, shared, or further processed and should be securely deleted once the issue has been reported.

5. What We Accept

We are primarily interested in vulnerabilities that could meaningfully impact the confidentiality, integrity, or availability of Billie systems or customer data.

Examples include:

• remote code execution (RCE);
• authentication or authorisation bypass;
• privilege escalation;
• sensitive data exposure;
• server-side request forgery (SSRF);
• cross-site scripting (XSS);
• cross-site request forgery (CSRF);
• significant business logic vulnerabilities, and
• security misconfigurations with demonstrable impact.

Reports should include a clear description of the issue, affected assets, potential impact, and steps to reproduce where possible.

6. Out of Scope Activities

The following activities are not permitted under this policy:

• denial of service (DoS/DDoS) testing;
• social engineering or phishing attacks;
• physical attacks against Billie employees or infrastructure;
• automated scanning that negatively impacts service availability;
• attempts to access, modify, or delete data belonging to other users;
• spam, resource exhaustion, or brute force attacks;
• or testing against third-party services not operated by Billie.

Additionally, the following findings are generally considered out of scope unless accompanied by a demonstrated security impact:

• missing security headers;
• SPF, DKIM, or DMARC issues;
• version disclosures or banner grabbing;
• low-risk clickjacking;
• self-XSS;
• or theoretical rate-limiting observations.

7. Our Commitment to Researchers

If you act in good faith and comply with this policy, Billie will:

• acknowledge receipt of your report within 2 business days;
• provide an initial triage assessment within 10 business days where possible;
• keep you informed throughout the remediation process;
• treat your personal information confidentially;
• and not initiate legal action against you for activities conducted in accordance with this policy.

We consider security research performed in line with this policy to be authorised.

This safe harbour applies only to lawful security research intended to identify and responsibly disclose vulnerabilities. It does not apply to:

• intentional service disruption;
• privacy violations;
• data destruction or modification;
• social engineering;
• extortion;
• unauthorised persistence or lateral movement;
• or activities exceeding what is reasonably necessary to validate a security issue.

8. Recognition and Rewards

Billie may, at its discretion, offer monetary rewards, public recognition, or other acknowledgements for valid and impactful security reports.

Any rewards are determined based on factors such as:

• severity and exploitability;
• quality and clarity of the report;
• potential business or customer impact;
• reproducibility;
• and compliance with this policy.

Examples of typical reward ranges:

Rewards are voluntary and are not guaranteed for all submissions.

9. Coordinated Disclosure

Billie supports coordinated vulnerability disclosure principles.

Researchers are requested not to publicly disclose vulnerabilities before:

• the issue has been resolved;
• Billie confirms that remediation is not required;
• or a mutually agreed disclosure timeline has been reached.

Where appropriate, Billie may coordinate:

• public security advisories;
• remediation guidance;
• CVE disclosures;
• and public acknowledgement of researchers.

10. Vulnerability Handling Process

Vulnerability reports submitted under this policy are handled through Billie’s internal vulnerability management and, where applicable, incident response processes, including:

• Intake and acknowledgement
• Validation and triage
• Severity assessment
• Remediation planning
• Testing and deployment of fixes
• Coordinated disclosure and closure

Vulnerabilities may be prioritised based on exploitability, business impact, exposure of sensitive data, operational resilience impact, and potential regulatory implications.

11. Regulatory Considerations

Billie may handle certain vulnerabilities in accordance with applicable legal and regulatory obligations, including obligations relating to actively exploited vulnerabilities under the EU Cyber Resilience Act.

Certain vulnerabilities may therefore be escalated through Billie’s internal incident management, operational resilience, and regulatory reporting processes.

12. Updates to This Policy

This policy may be updated periodically.

The latest version will always be published on this page.

---

Thank you for helping us keep Billie secure.

Security is a shared responsibility, and we appreciate the efforts of the security research community.

Appendix 1 – In-Scope Assets

The following public-facing Billie-owned assets are currently considered in scope for this policy:

• billie.io
• portal.billie.io
• partners.billie.io
• partners-sandbox.billie.io
• paella-sandbox.billie.io
• paella.billie.io
• fp.billie.io
• media.billie.io
• demoshop.billie.io
• bnpl.demo.billie.io
• *.bnpl.demo.billie.io
• transaction-monitoring.billie.io
• *.transaction-monitoring.billie.io
• tagging.billie.io
• debug.tagging.billie.io
• salesforce-api.billie.io
• salesforce-api-tmp.billie.io
• designated-survivor.billie.io

Additional explicitly designated Billie-owned public services or APIs may also be considered in scope where publicly accessible.

Appendix 2 – Typical Vulnerability Severity Classification

The examples below illustrate how Billie typically assesses the severity and potential impact of reported vulnerabilities.

Severity assessments are made on a case-by-case basis and may consider factors such as exploitability, affected systems, data sensitivity, business impact, and operational resilience implications.