Security disclosure policy

Cuko Ltd welcomes reports of security weaknesses in cuko.uk and the open-source projects published under the github.com/Cuko-ltd organisation. This page sets out scope, safe harbour, submission steps, and the response timeline you can expect.

The machine-readable companion is published at /.well-known/security.txt, conforming to RFC 9116.

→ Scope

What is covered

In scope

cuko.ukThe static marketing site you are reading, including all sub-paths and the published machine-readable artefacts (sitemap, robots, llms.txt, security.txt).
Cuko AIP and related repositoriesPublic repositories under github.com/Cuko-ltd, including the protocol specification, anchor contracts, anchor service, SDKs, and worked examples.

Out of scope

GitHub Pages infrastructureVulnerabilities in GitHub Pages itself, GitHub authentication, or Microsoft hosting infrastructure should be reported to GitHub's bug-bounty programme.
Best-practice scoring without impactReports based purely on automated-scanner output (e.g. missing security headers, CSP recommendations) without a demonstrated impact path are valued but not eligible for prioritised response.
Social engineering of staff or clientsPhishing, vishing, or any social-engineering attempt against Cuko Ltd personnel, contractors, or clients is out of scope and not authorised.
Denial-of-service testingDoS, DDoS, or volumetric load testing is out of scope and not authorised.
Physical securityOffice, premises, or device-level physical access is out of scope.

→ Safe harbour

Good-faith research is welcome

Cuko Ltd will not pursue legal action against researchers who:

act in good faith and avoid privacy violations, destruction of data, and degradation of service; only test against assets explicitly listed in scope; report any vulnerability they discover promptly through the contact channel below; and give Cuko Ltd a reasonable opportunity to remediate before any public disclosure.

This policy is intended to be compatible with the safe-harbour provisions of the UK Computer Misuse Act 1990 (as proposed for amendment) and Article 6 of the EU Cyber Resilience Act. It does not, however, override third-party rights — researchers remain responsible for their interactions with services not owned by Cuko Ltd.

→ How to report

Submitting a vulnerability

Send a single email to [email protected] with the subject line beginning Security vulnerability report. Include:

Asset: Which in-scope asset is affected (URL, repository name, commit hash where relevant).
Description: What the vulnerability is, in plain language.
Reproduction: Step-by-step reproduction with minimal proof-of-concept.
Impact: What an attacker could achieve in practice. Theoretical impact is fine; demonstrated impact is better.
Mitigation: Optional — your suggestion for the fix.
Credit: Whether you want public credit on resolution. Default is no credit unless you opt in.

Encrypted communication is not currently supported. If you require encrypted submission, contact us first at the address above and we will arrange an alternative channel for that report.

→ What to expect

Service-level commitments

Acknowledgement: Within two working days of receipt
Initial assessment: Within five working days, including a preliminary severity rating
Remediation: Critical and high severity within 30 days; medium within 60 days; low within 90 days, where the underlying asset permits
Update cadence: Status update every fortnight while the report is open
Disclosure: Coordinated public disclosure no earlier than 90 days after initial report, or earlier by mutual agreement

→ Acknowledgements

Researchers credited

None to date. Researchers who give Cuko Ltd a reasonable opportunity to fix and who opt in to public credit will be listed here on resolution.

→ Meta

About this policy

Last updated: 2026-04-26
Review cadence: Annually and after any material incident
Machine-readable companion: /.well-known/security.txt (RFC 9116)