# KXCO Publishes a Coordinated Vulnerability Disclosure Programme

A published policy with named response times, safe harbour for security researchers, and CERT’s SSVC model for prioritisation. Plus what KXCO finds broken in the estates it examines, and why the cryptography of a live chain is the one thing that cannot be fixed later.

Canonical HTML: https://www.livetradingnews.com/kxco-publishes-a-coordinated-vulnerability-disclosure-programme
Last modified: 2026-07-30

---

By Shayne Heffernan · 2026-07-30
Tags: KXCO, coordinated vulnerability disclosure, CVD, security.txt, RFC 9116, SSVC, CERT/CC, CISA, safe harbour, vulnerability disclosure policy, Executive Order 14412, FAR, post-quantum cryptography, ML-DSA-65, NIST, self-custody, KXCO Purse, CSAF, cyber security, Shayne Heffernan
Signed: ML-DSA-65, anchored on Armature L1.
Nothing in this article is investment advice.

KXCO has published a formal coordinated vulnerability disclosure programme, setting out how external security researchers reach the company, what response they are entitled to, and how findings are prioritised. The technical write-up is here: [How we secure KXCO, and how we can help you fix yours](https://kxco.ai/developers/blog/how-we-secure-kxco-and-how-we-fix-yours).

The short version: if you sell software that other people's security depends on, you need a published route for strangers to tell you when it is broken, and you need to know which cryptography you are actually running. Most companies have neither. KXCO has now built both for itself, and does the same work for customers.

## What was published

The policy lives at [kxco.ai/security](https://kxco.ai/security), with a machine-readable contact file at `/.well-known/security.txt` under RFC 9116, the standard that lets a researcher or an automated tool find a vendor's security contact without guessing.

The commitments are specific rather than aspirational. Acknowledgement of any report within two business days, from a named person rather than an auto-responder. A triage decision within five business days, including whether the issue was reproduced, what the assessed impact is, and a target fix date. An update at least every fourteen days while a case stays open, including when the update is that nothing has changed. A ninety-day default disclosure window, sooner where the fix ships sooner.

It also includes a safe harbour statement. Security researchers do unpaid work that reduces a vendor's risk, under laws that could be read to criminalise it. The policy says plainly that good-faith research is authorised, that KXCO will not pursue or support legal action against a researcher who follows it, and that KXCO will say so publicly if a third party tries.

Three things the policy rules out, because each is a common vendor habit that damages the relationship with researchers: no blanket non-disclosure agreements as a condition of reporting, no silent fixes shipped as routine releases, and no advisories behind a paywall.

## Prioritisation by decision, not by score

KXCO prioritises using the Stakeholder-Specific Vulnerability Categorization model published by the CERT Coordination Center at Carnegie Mellon University's Software Engineering Institute, rather than a severity score on its own.

The distinction matters commercially. A CVSS score tells you how bad a vulnerability is in the abstract. SSVC produces a decision about what happens next, which is the part a customer actually experiences. The four outcomes each carry a service level: Immediate means a patch or mitigation inside forty-eight hours, Out-of-cycle means engineers come off current work for a release inside seven days, Scheduled means the normal release cycle inside thirty days, and Defer means logged with reasoning and no commitment, with the reporter told why.

One local rule sits on top. Anything touching cryptographic correctness, signature verification, replay windows or key custody starts at Out-of-cycle or higher by default, and is only downgraded with a written reason. In a signing and verification product those are not ordinary bugs.

## What is still in progress

The write-up publishes the work that is not finished at its current state rather than its intended state: independent cryptographic review, where the position today is self-attested and a published audit scope document lets a reviewer see exactly what an audit would need to cover; formal certification, with SOC 2 and ISO 27001 on the roadmap ahead of enterprise procurement and neither claimed until an external party has signed something; the CERT/CC vendor record, where registration is under way and no badge goes on the trust page until the coordinator completes verification; and the rollout of the disclosure surface across the remaining product domains. The reasoning given is that an institutional reviewer establishes all of this in due diligence anyway, and the only variable is whether they hear it from the vendor first.

One item is explicitly not on that list. The cryptography of the Armature L1 chain is settled rather than pending, and the write-up makes the point that it had to be. The chain has signed with ML-DSA-65 since block zero, which is a property of every block in the record rather than a feature enabled at some later date. A live chain's history cannot be re-signed: whatever cryptography secured a block when it was written secures it permanently, so a network that began on classical signatures carries that exposure in its record for as long as the record exists, whatever its validators run tomorrow. It is the one part of a post-quantum migration with no migration path, which is why the chain was built that way from the start rather than adapted.

## Why now

There is a regulatory clock as well as a security argument.

On 15 July 2026, CISA, the National Security Agency, the United Kingdom's National Cyber Security Centre, the Netherlands' National Cyber Security Centre and JPCERT/CC jointly published guidance on establishing a coordinated vulnerability disclosure programme. It sets a common baseline across four allied nations for how software vendors should work with external researchers.

Separately, United States Executive Order 14412, signed 22 June 2026, requires at section 6(d) that the Federal Acquisition Regulatory Council publish a proposed rule within 270 days obliging covered contractors to run vulnerability disclosure policies that specifically accept reports of cryptographic vulnerabilities. Section 6(c) of the same order sets a contractor deadline of 31 December 2030 for compliance with the NIST post-quantum standards. Any company selling into the US federal market, or selling to someone who does, is already inside both windows.

The write-up sets out what KXCO finds broken in nearly every estate it examines, having started with its own. A published reporting address that forwards to someone who left. Security reports landing in the customer support queue, where a vulnerability gets triaged as a complaint. No safe harbour, so the researchers who read the legal position carefully are the ones who decline to help. Severity scores with no decision attached, so prioritisation collapses into whoever is loudest. And, most consequential of all, no inventory of which cryptographic algorithms are running where, which is why most 2030 migration roadmaps are fiction: you cannot schedule the replacement of something you have not located.

That last item is where KXCO does the work rather than describing it. KXCO Sentinel scans repositories and endpoints and produces a signed cryptographic bill of materials in the CycloneDX CBOM format: which algorithms, in which components, on which hosts, and what has to change before the deadline. The disclosure programme is the other engagement, and the shape of it is now known well enough to stand up in days rather than the quarter most organisations budget.

## The company position

KXCO is a software company. It holds no financial licences, does not custody assets, and does not operate regulated services. Licensed institutions that deploy KXCO software operate under their own licences and hold their own customer relationships.

The clearest expression of that is the wallet. KXCO Purse is self-custodial across EVM chains, Bitcoin and Tron: keys are generated on the user's own device, and in the default mode KXCO holds no key material at all. There is no omnibus account, no pooled balance and no internal ledger sitting between a user and their assets, which means there is no honeypot to steal and nothing for the operator to lose on a customer's behalf. The strongest security property a wallet can offer is that the operator is not able to move your money, and in this design that is an architectural fact rather than a promise about conduct.

Recovery is usually where self-custody quietly turns back into custody, with a provider holding a seed phrase just in case. Purse does not do that. Managed accounts use a 2-of-3 guardian scheme, so a lost device is not a lost balance and no single party, KXCO included, can move funds alone. The wallet ships white-label, which is the commercially relevant part: an institution can put self-custody in front of its own customers without becoming a custodian itself, and without inheriting the safeguarding obligations that attach to holding client assets.

That boundary is the reason the security posture has to be legible rather than merely asserted. Customers inherit the vendor's cryptography, and they are the ones examined on it. A claim a buyer cannot check is worth nothing to a buyer who will be audited.

The full technical write-up, including what runs in production, the five things anyone can verify without KXCO's cooperation, the work still in progress, and what remediation involves, is at [How we secure KXCO, and how we can help you fix yours](https://kxco.ai/developers/blog/how-we-secure-kxco-and-how-we-fix-yours).

---

This Markdown mirrors https://www.livetradingnews.com/kxco-publishes-a-coordinated-vulnerability-disclosure-programme. The HTML page is canonical.
Site index for AI clients: https://www.livetradingnews.com/llms.txt