Vulnerability Disclosure Policy

Effective 10 September 2026 · Version 1.0

A company that sells security work should expect its own infrastructure to be examined. The rules below exist so that a researcher reporting an issue to us knows exactly where they stand, with nothing left to interpretation.

1. Scope

• ongsec.com and all of its subdomains
• Products built by ONGSEC: MonPulse, FilePhantom, PASI, Forensica, Onmetry, Denetchi
• Distribution packages, installation scripts and publicly reachable API endpoints of those products
• Corporate mail and DNS configuration operated on behalf of ONGSEC

2. Out of scope

The following are not covered and must not be tested:

• Client systems. Anything you believe belongs to an ONGSEC client is not ours. We have no authority to test it and cannot grant you any. See section 8.
• Denial of service (DoS/DDoS), load testing, brute force and password spraying
• Social engineering, phishing or physical access attempts against our staff or clients
• Issues in third-party services (hosting provider, CDN, mail provider) — report those to the provider directly
• Reports that show no demonstrated exploitability and consist only of scanner or browser-extension output: missing security headers, SPF/DMARC preference differences, TLS cipher suite choices, version disclosure, open redirect without impact
• Scenarios requiring implausible user interaction (for example, the victim pasting code into their own browser console)
• Findings already made public or sold to a third party before reaching us

3. Safe harbour

Research conducted under this policy is treated as authorised access. As long as you follow the rules:

• We will not initiate civil or criminal proceedings against you under Turkish computer-crime provisions, Law No. 5651, or on a contractual basis.
• If a third party takes action against you, we will state in writing that your work was authorised under this policy.
• An accidental overstep made in good faith is not treated as a breach. What matters is that you stop and tell us.

Safe harbour is conditional on the following:

• You access the minimum data needed to demonstrate the issue. If you reach personal data, you stop there — no copying, downloading or sharing.
• You do not delete, alter or encrypt data, degrade the service, or leave any persistent access behind.
• You do not disclose, sell or trade the finding before reporting it to us.
• Testing stays limited to accounts and data that are your own.
• You comply with applicable law, including sanctions and export rules.

If you are unsure whether a test is acceptable, ask first: security@ongsec.com. Asking beforehand beats arguing afterwards.

4. How to report

Send reports to security@ongsec.com. Please encrypt sensitive detail with PGP; our key and fingerprint are in the box beside this text and in security.txt.

A good report contains:

• Affected URL, hostname or component and version
• Issue class and a short technical description
• Step-by-step reproduction: request/response samples, proof of concept, screenshot or a short video
• Date and time of testing (with time zone) and the source IP you used, so we can separate you from hostile traffic in our logs
• Impact assessment: what an attacker could do with this
• Suggested remediation, if you have one
• The name or handle you would like on the acknowledgements page, if you want to appear there

Turkish or English are both fine.

5. What we commit to

If we consider a report invalid we will explain why, rather than closing it as “out of scope”. If you disagree with our assessment, say so and a second person will review it.

6. Remediation targets

Severity is set from the CVSS v3.1 base score together with real-world exploitability.

For a critical issue we aim to deploy a mitigation the same day, without waiting for the target above.

7. Disclosure timeline

We work to a coordinated disclosure model and are glad to publish jointly once a fix has shipped. Your name goes on our acknowledgements page if you want it there.

• 90 days. Ninety days after your report you are free to publish, whether or not a fix has shipped. We treat this as a ceiling, not as a gag.
• If a fix ships earlier, you may publish 7 days after release.
• If the issue is under active exploitation, we shorten the timeline together.
• If a complex architectural change is required we may ask for more time. That is a request with reasons attached, not a demand.

For issues in our own products we request a CVE identifier and credit the reporting researcher in the record. For findings that touch Turkish critical infrastructure we coordinate with USOM (TR-CERT).

8. Issues found in client systems

If you find an issue in a system belonging to an ONGSEC client, do not send us technical detail. Tell us only which organisation it concerns; we will point you to the right contact and mediate if needed. We cannot authorise you on client systems, and the safe harbour in this policy does not extend to them.

9. Rewards

We do not run a paid bounty programme at present; if that changes it will be announced here. For every valid report we offer:

• Credit on our acknowledgements page, under your name or handle
• On request, a signed letter describing the finding, usable for CVE submissions and job applications
• Researcher credit in the CVE record for issues in our own products
• Free admission to ONGSEC Academy training

10. Personal data

Contact details you send are processed only to run the disclosure process and to maintain the acknowledgements record; details are in our Personal Data Notice. You may report pseudonymously. If a vulnerability gave you access to personal data, say so in the report — we need to know in order to meet our own breach-notification duties on time.

11. Machine-readable information

We publish /.well-known/security.txt in line with RFC 9116. The file is PGP-signed with the key below, so you can verify that its contents came from us.

curl -s https://www.ongsec.com/.well-known/pgp-key.txt | gpg --import
curl -s https://www.ongsec.com/.well-known/security.txt | gpg --verify

Fingerprint: 6835 A816 CE74 7FEC 9D7D 6E1F B54E 4315 AEBE 1BA4

This policy is a commitment to the researcher who reports to us; ONGSEC will not narrow it retroactively. If the text is updated, the version number and date change and the previous version remains available on request.