Security and responsible disclosure

Reporting a vulnerability

If you believe you have found a security issue in Koruqan, email destek@koruqan.com with "Security" in the subject line. A useful report includes the affected component and version, reproduction steps, the impact you believe it has, and any proof-of-concept output. Reports in English or Turkish are both fine.

We ask that you give us a reasonable opportunity to remediate before publishing. We will not pursue legal action against researchers who act in good faith, stay within the scope below, and avoid actions that would harm users or their data.

Scope

Koruqan is deployed inside the customer's own infrastructure. That shapes what is in scope for a report to us.

In scope

The Koruqan platform itself: the scan engine, the exploitation modules, the pipeline designer, the web console, the report generator, the AI command gate, and the packaging and update mechanism.

Also in scope

This website and its contact endpoint.

Out of scope

Customer deployments. We do not operate customer instances and cannot authorise testing against them. If you have found an issue in a specific organisation's Koruqan instance, report it to that organisation, not to us.

Out of scope

Findings that require a compromised host, a malicious administrator, or physical access to the machine running the platform.

What we ask of researchers

The same rules we ask Koruqan operators to follow apply to anyone testing us.

Test only what you are permitted to test

This site and your own Koruqan instance. Not another organisation's deployment.

Do not degrade service

No denial of service, no resource exhaustion, no automated scanning at rates that affect availability.

Do not access data that is not yours

If you can demonstrate access, stop at the demonstration. Do not enumerate, download or retain third-party data.

Report promptly and privately

One report per issue, to the address above, before public disclosure.

How we handle reports

We acknowledge reports and keep the reporter informed while we investigate. Reports are triaged by impact rather than by report order: an issue that lets an unauthenticated user reach another tenant's scan data is handled before a missing header.

Where a fix requires customers to update, we describe the issue and the required action in the release notes. Because Koruqan is self-hosted, we cannot patch customer instances ourselves — remediation depends on operators updating, which makes clear communication part of the fix rather than an optional extra.

Security properties of the platform itself

Some of these matter to researchers assessing Koruqan, and to operators deciding how to deploy it.

Self-hosted by design

Targets, findings and proof-of-exploit artifacts stay inside the operator's network. There is no vendor-side copy of customer scan data because there is no vendor-side deployment.

Offensive tooling is isolated

The roughly 50 Kali tools run in a Docker sidecar rather than directly on the host, which bounds what a tool bug can reach.

AI commands are gated

Commands produced during AI-assisted exploitation are rejected by default if destructive or out of scope, rather than permitted unless blocked.

Scope is enforced in the platform

Targets are bounded before a scan runs, not by operator discipline during it.

security.txt

Machine-readable contact details are published at /.well-known/security.txt following RFC 9116. Automated tooling and researchers who check that path first will find the same contact address and this policy.