# Coordinated vulnerability disclosure policy **Status:** normative, from 2026-08-28. Public. This is the document `/.well-known/security.txt` points at. **Baseline:** ISO/IEC 29147:2018 (*vulnerability disclosure* — how a report is received and how information is published) with severity scored on **CVSS v4.0**. The internal side of the pair, ISO/IEC 30111:2019 (*vulnerability handling* — what happens to a report after it arrives), is in [`vulnerability-handling.md`](vulnerability-handling.md), together with the statutory reporting clock. --- ## Reporting a vulnerability **security@ugix.io** Send it in English or Spanish. You will get a human reply — see the [commitments](#what-we-commit-to) below for how fast. Useful to include, none of it mandatory: - What the product is and which version — for Node Supply Chain System, the image digest or the release tag; the operator prints both. - What you did, in enough detail to repeat it. - What happened, and what you expected instead. - Why it matters: what an attacker gains, and what they need first. - How you would like to be credited, or that you would rather not be. Do not open a public issue for a suspected vulnerability. Do not include a working exploit in the first message; a description of the class of problem is enough to start, and we will ask if we need more. ## Scope **In scope:** Node Supply Chain System itself — the installable operator and the services it deploys, the monitoring surface, the release artefacts (images, SBOMs, signatures, manifests) and the pipeline that produces them. **Out of scope:** a customer's own deployment of the product. Under the BYOC model the software runs on infrastructure the vendor does not own and cannot reach, so findings about a *specific* customer installation belong to that customer. A finding about the product that happens to be *observed* on one is in scope, and welcome. Also out of scope: reports produced solely by a scanner with no demonstrated impact, missing headers with no exploit path, and anything requiring physical access to a customer's hardware. ## Safe harbour If you follow this policy, we will not pursue or support legal action against you for your research, and we will treat your report as authorised access for the purposes of any anti-hacking law we could otherwise invoke. That protection depends on your keeping to research that is proportionate: use only accounts and data that are yours, stop as soon as you have proved the finding, do not degrade a service or exfiltrate data, and give us the window below before you publish. We cannot grant safe harbour on behalf of a customer whose installation you test without their permission. Ask them, not us. ## What we commit to | Step | Within | |---|---| | Acknowledgement that a human has your report | **3 working days** | | First triage: in scope or not, and our severity | **10 working days** | | Progress update while it is open | every **14 days** | | Fix or documented mitigation — **Critical** (CVSS v4.0 ≥ 9.0) | **7 days** | | **High** (7.0–8.9) | **30 days** | | **Medium** (4.0–6.9) | **90 days** | | **Low** (0.1–3.9) | next scheduled release | Security updates are **free of charge** and are shipped **separately from feature releases**, so a customer can take the fix without taking anything else. ## Disclosure We disclose. Once a fix is available, the vulnerability is described in the CHANGELOG and in the release notes, with its severity and the versions affected — including the ones nobody reported. The default window is **90 days from acknowledgement**, or the day the fix ships, whichever is sooner. We will ask you to hold longer only with a reason we are willing to write down, and we will tell you if we intend to publish sooner because the flaw is already being exploited. If you tell us you plan to publish on a date, we will work to that date rather than argue about it. ## Credit Reporters are credited by name or handle in the release notes unless they ask not to be. There is no bug bounty: this is a small vendor and paying for reports would be a promise we cannot keep evenly. ## What this policy does not cover There is no PGP key yet, so a report may travel to us in the clear. If a finding is too sensitive for that, say so in a message with no detail in it and we will arrange a channel before you send anything. ## Why these two standards ISO/IEC 29147 and 30111 are the pair the EU Cyber Resilience Act assumes without naming: Annex I Part II point (5) requires a coordinated vulnerability disclosure policy, and point (6) a contact address for reports. 29147 is the outward half of that, 30111 the inward half. Choosing them over the CERT/CC guide — which is free and more readable — buys one thing: a citable answer to "which norm do you follow?" in a buyer's due diligence. Recorded in ADR-0059.