Security

Security and responsible disclosure

We find and fix vulnerabilities for a living, so we hold ourselves to the standard we ask of others. This page covers how to report a weakness in our systems, what you can expect from us in return, and the rules under which our own offensive work is carried out. A machine-readable version is published at /.well-known/security.txt.

Last updated: 9 October 2026

1. Reporting a vulnerability

If you believe you have found a security issue in cyberlinksec.com, our APIs or any system we operate, email info@cyberlinksec.com with the subject line “Security report”. Include the affected system, steps to reproduce, the impact you observed and, if relevant, your IP address at the time of testing so we can match it in our logs. Encrypted submissions are welcome; ask us for a current PGP key by email first.

2. What you can expect from us

  • Acknowledgement of your report within three business days.
  • An initial assessment and a point of contact within ten business days.
  • Remediation of confirmed issues as quickly as severity warrants, with a target of ninety days for the most complex fixes, and progress updates along the way.
  • Public credit for your finding if you want it, once a fix is in place.
  • No legal action against researchers who follow this policy in good faith (see safe harbour below).

3. Safe harbour and ground rules

Research conducted under this policy is authorised, and we will not pursue or support legal action against you for it, provided you:

  • Test only systems we own and operate, and stop as soon as you have enough evidence to demonstrate the issue.
  • Do not access, modify, exfiltrate or retain data that is not your own beyond what is strictly needed to prove the finding.
  • Do not degrade our services: no denial-of-service testing, automated scanning at disruptive rates, or physical or social-engineering attacks on our people.
  • Give us a reasonable opportunity to fix the issue before any public disclosure, and coordinate the timing with us.

Third-party services we rely on (for example our hosting, email and form providers) have their own disclosure programmes and are out of scope here.

4. Rules of engagement for our offensive work

Penetration testing, red teaming and adversary emulation are performed only for clients who have engaged us, and only within these constraints:

  • Written authorisation first. No testing starts without a signed statement of work and a rules-of-engagement document naming the authorising officer, the systems in scope, the testing window and emergency contacts.
  • Scope is a hard boundary. Systems, accounts and data outside the agreed scope are never touched, and any accidental exposure is reported to the client immediately.
  • Evidence, not exploitation for its own sake. We demonstrate impact with the minimum necessary action and never deploy destructive payloads, ransomware or persistence that outlives the engagement.
  • Client data is protected. Findings and evidence are handled under the engagement’s confidentiality terms, stored encrypted and deleted on the agreed schedule.
  • Coordinated disclosure. Previously unknown vulnerabilities in third-party products discovered during an engagement are reported to the vendor through coordinated disclosure, with the client’s agreement.
  • Lawful and compliant tooling. Our tooling, including the AI assistance described on our AI page, is used in line with applicable law and with each provider’s usage policy.

5. If you are under attack

This page is for reporting weaknesses in our own systems. If your organisation is experiencing an active incident, use the 24/7 incident line on our contact page.