Reporting a vulnerability, our open source assurance conformance, what an SBOM from us contains, and what we hold about you. One page rather than four policies nobody finds.
A supplier that asks to be trusted with a hazard analysis should be able to say, in one place, what it does with what you send it. This page is that statement, and the machine-readable parts of it are published at the addresses the standards expect to find them.
Report anything affecting this site, our published reference implementations, or a product we contributed to. Reports made in good faith will not be met with legal action.
| Channel | Detail |
|---|---|
| security@norxs.com, encrypted with our public key where the content warrants it | |
| Public key | /pgp-key.txt |
| Machine-readable | /.well-known/security.txt, per RFC 9116 |
| Full policy | Security policy |
Within two working days, from a human, saying who has it.
Severity, affected versions and an initial view within ten working days.
A fix or a documented mitigation, with the timeline shared as it moves rather than at the end.
Coordinated, with credit if you want it. We will tell you if a downstream integrator needs time first.
Two OpenChain specifications, self-certified. They are process conformance rather than a product certificate, and the difference matters.
| Specification | What it requires of us |
|---|---|
| ISO/IEC 5230 OpenChain licence compliance |
A documented programme for identifying, tracking and complying with the licences of open source we ship, with named responsibility and a defined process for resolving a licence question before delivery. |
| ISO/IEC 18974 OpenChain security assurance |
A documented programme for knowing what is in a product, tracking known vulnerabilities against it, and having a path from detection to response. This is the same discipline the EU Cyber Resilience Act now requires. |
It does not mean a product we touched is free of vulnerabilities, and it does not mean a third party audited us. It means the process exists, is written down, and is followed. If you need evidence of that for your own supplier qualification, ask and we will send the process description.
| Item | Position |
|---|---|
| Format | SPDX 2.3 by default, CycloneDX on request. Both are machine-readable and both are accepted by the platforms that consume them. |
| Scope | Every third-party component that reaches the binary, including transitive dependencies and build-time tooling that affects the output. |
| Versions | Every component carries a version. A version-less SBOM cannot be matched against an advisory, which makes it decorative. |
| Delivery | Generated by the build, not written by hand afterwards, and delivered with the baseline it describes. |
| Vulnerability status | Where a known CVE affects a listed component, a VEX statement says whether it is exploitable in this product and why. |
The published reference implementations ship their SBOM in the repository, so you can inspect the format before commissioning anything.
| Category | Handling |
|---|---|
| Programme material | Held under NDA for the engagement, on systems we control. Not placed into third-party services for processing. Returned or destroyed on request at the end of the engagement. |
| Files loaded into this site | Never uploaded. The FMEDA, SBOM, coverage, static-analysis and requirements importers on the demonstration platform parse in your browser. Nothing is transmitted, so there is nothing for us to hold. |
| Baselines you save in the platform | Stored in your own browser’s local storage. They are visible only to that browser profile and can be cleared from it at any time. |
| Contact form | Name, email, optional company, topic and message, transmitted to our mailbox and retained as correspondence. No tracking identifiers and no advertising identifiers are attached to it. |
| Site telemetry | Cloudflare Web Analytics, aggregate only. No cookie is set, no identifier is stored on your device, and no profile is built. See the note below for exactly what that covers. |
We measure how the site is used, because we cannot fix what we cannot see. We have chosen the option that collects the least while still answering that question, and this is what it does.
What is collected: page path, referrer, country, browser and device class, and
page-load timings — all aggregated. What is not: no cookie, no
localStorage entry, no device fingerprint, no visitor or session identifier, no
cross-site tracking, and no data sold or shared for advertising. Visitor uniqueness is computed at
the edge from the request headers, hashed, and discarded; it is never stored.
Why there is no consent banner: the banner requirement in the ePrivacy Directive (Article 5(3)) is triggered by storing or reading information on your device. Nothing here does either, so it does not apply. The GDPR still governs the momentary processing of an IP address at the edge; the lawful basis is legitimate interest under Article 6(1)(f), limited to aggregate site statistics, and you are being told about it here rather than in a policy nobody reads.
If your organisation’s own rules require this to be switched off for your visit, tell us and we will confirm in writing what was and was not recorded.
The site is served by Cloudflare Pages. The contact form is relayed by an email delivery provider. Those two see request metadata and, for the form, the message you submitted. Nothing else about you passes through a third party.
Where an engagement requires a different arrangement, for example an air-gapped environment for defence work, that is scoped rather than assumed impossible.
Certifications in this field are issued to individuals rather than to companies, so they are listed by name of qualification on the about page. Credential IDs and issuer verification links are provided during supplier qualification, along with the insurance certificate.
Ask for the specific document rather than a generic pack. We will send the one your form actually needs.