Responsible Disclosure Policy

Effective September 29, 2026

Devence Lab, Inc. ("Devence Lab", "we", "our", or "us") welcomes reports of security vulnerabilities in the systems we operate. This policy describes what testing we authorise, what we ask you not to do, how to report a finding, and what you can expect from us in return.

We publish this policy because the alternative — leaving researchers to guess whether a report will be met with thanks or with a letter from a lawyer — makes everyone less safe.

1. Scope

In scope

• The public website at devencelab.com
• The public endpoints it serves, and the content, configuration, and response headers returned with them

Subdomains are not in scope unless we confirm in writing that a particular one is. Some are operated by third parties on our behalf, and we cannot authorise testing of a system we do not control.

Out of scope

• Any system operated by a third party, including the providers listed on our Subprocessors page. Report those to the provider concerned.
• Any domain not listed above, including any site that merely mentions or links to us.
• Physical security, and the personal accounts or devices of our staff.
• Social engineering of our staff, contractors, customers, or providers.

If you are unsure whether a target is in scope, ask at security@devencelab.com before testing.

2. Authorised testing

We authorise good-faith security research against the systems in scope, on the conditions in this policy. "Good faith" means testing carried out to identify and report a weakness, without harming the service, its users, or their data.

You may:

• probe for vulnerabilities using manual techniques and automated scanners, at a rate that does not degrade service;
• examine responses, headers, source, and client-side code;
• test input handling on our public endpoints with benign payloads; and
• access only your own data, or data you have created for the purpose of testing.

3. Prohibited activity

The following are not authorised, are excluded from the safe harbour in Section 6, and may be unlawful:

• Data exfiltration. Accessing, copying, downloading, retaining, or transmitting any data that is not yours. If you inadvertently obtain such data, stop, do not save it, tell us immediately, and delete every copy.
• Denial of service. Volumetric, application-layer, or resource-exhaustion attacks; stress or load testing; and any activity that degrades availability for others.
• Destruction or alteration. Modifying, corrupting, or deleting data or configuration; defacing content; or placing files on our systems beyond a minimal, clearly labelled, non-destructive proof of concept.
• Persistence. Installing a backdoor, web shell, implant, scheduled task, or any other means of maintaining access. Establish the vulnerability, then stop.
• Lateral movement or privilege escalation beyond the minimum needed to demonstrate the finding.
• Malware. Introducing malicious code, ransomware, cryptominers, or botnet clients.
• Phishing and social engineering of any kind, against anyone.
• Physical intrusion at any premises.
• Credential attacks. Brute force, password spraying, or credential stuffing against any account. Do not use credentials that are not yours, including credentials found in a public breach corpus.
• Third-party harm. Any activity that attacks, or uses our systems to attack, a third party.
• Extortion. Demanding payment as a condition of disclosing a finding, or threatening publication to obtain one. We treat this as extortion rather than research, and it forfeits the safe harbour entirely.

4. How to report

Send your report to security@devencelab.com.

A report is most useful when it contains:

1. The affected URL, endpoint, or component, and the date and time of your testing.
2. The vulnerability class, and its impact in practical terms.
3. Reproduction steps precise enough for us to follow, including any request or payload.
4. Supporting evidence — a request and response transcript, a screenshot, or a short recording.
5. The source IP addresses and user-agent strings you tested from, so we can distinguish your traffic from an actual attack in our logs.
6. How you would like to be credited, if at all, and whether you intend to publish.

Please report in English or French. One issue per report, please; separate findings in separate emails are easier for both of us to track.

Encryption

If your report contains sensitive detail, tell us in a first message and we will arrange an encrypted channel before you send it.

5. What you can expect from us

These are targets that describe how we intend to work, not contractual commitments, and they do not create an obligation enforceable by you or by anyone else. Some fixes depend on a third party and are not ours to schedule.

We will tell you when the issue is fixed, and we will tell you plainly if we decide not to fix it and why. We will not misrepresent your finding's severity to diminish it.

We do not operate a paid bug bounty programme. We are grateful for reports and will say so publicly, but we do not offer monetary rewards, and you should not test on the expectation of payment.

6. Safe harbour

If you conduct security research in accordance with this policy, we commit that:

• we will regard your activity as authorised under applicable computer misuse and unauthorised access law, and under the anti-circumvention provisions of copyright law;
• we will not initiate or support civil or criminal proceedings against you in respect of that research;
• we will not submit a complaint to law enforcement about it;
• if a third party brings proceedings against you for activity conducted in accordance with this policy, we will make it known that your activity was authorised by us; and
• we will not ask you to sign a non-disclosure agreement as a condition of us accepting or triaging your report.

This safe harbour is limited to us. It cannot and does not bind any third party — including our hosting provider and the other providers listed on our Subprocessors page — and it does not authorise you to act against their systems.

This safe harbour applies only to activity that is within the scope in Section 1, complies with Section 3, and is conducted solely to identify and report a weakness. If your activity departs from this policy, the safe harbour does not apply to it, and nothing here waives any right or remedy in respect of conduct outside this policy. Where a departure appears to have been an honest mistake made in good faith, and you tell us promptly, we will take that into account.

Nothing in this policy grants you any right in our intellectual property, any licence to use or retain data you encounter, or any authority to represent that your testing is endorsed by us.

7. Coordinated disclosure

We ask that you give us 90 days from acknowledgement before publishing, and that you coordinate the timing with us so that a fix is deployed first.

We will not use the disclosure timeline as a delaying tactic. If we need longer — because a fix requires a change by a third party, for example — we will explain why and propose a date. If we fail to respond within the timescales in Section 5, you are free to disclose after the 90 days, and we will not regard that as a breach of this policy.

Please do not include real user data in anything you publish.

8. Known and accepted issues

The following are known to us and are not eligible for report. Sending them will not receive a substantive response.

• Missing security headers with no demonstrated exploit path.
• Findings from an automated scanner with no proof of exploitability.
• Absence of DNSSEC, CAA, or a particular TLS cipher preference, absent a demonstrated attack.
• Email configuration findings — SPF, DKIM, DMARC — on domains we do not send mail from.
• Clickjacking on pages with no state-changing action.
• Self-XSS, or any issue requiring the victim to paste code into their own console.
• Rate limiting on endpoints that change no state.
• Version disclosure, banner grabbing, or the mere presence of a software version.
• Vulnerabilities requiring a rooted, jailbroken, or already-compromised device, or a physically present attacker.
• Issues in third-party services listed on our Subprocessors page. Report those to the provider.
• Reports consisting only of a description of a vulnerability class, without evidence that it exists here.

9. Privacy of reports

We process the Personal Data in your report — your name, contact details, and the content of your correspondence — on the basis of our legitimate interest in securing our systems, in accordance with our Privacy Policy. We retain reports for as long as needed to fix the issue and to keep a record of the assessment, and we do not use your contact details for marketing.

10. Contact

security@devencelab.com