Security Policy

NEXUS - Manufacturing Intelligence Platform

NEXUS is a manufacturing intelligence platform used by UK engineering firms. If you have found a security vulnerability in it, this document tells you how to report it and what will happen next.

1. Why this exists - the Computer Misuse Act

This is the part a template copied from a US company will not tell you.

The Computer Misuse Act 1990 has no public-interest defence and no researcher safe harbour. Under s.1, causing a computer to perform a function with intent to secure unauthorised access is an offence, regardless of motive. A UK researcher who probes a system without permission commits that offence even if they intended only to report what they found and did no harm.

The practical consequence is not theoretical: without published authorisation, a researcher who spots something has two bad options - stay silent, or report it and hope. Many choose silence, and some choose disclosure elsewhere. A vulnerability disclosure policy is how an organisation removes that dilemma, by granting the permission that makes the testing authorised in the first place.

That is why section 3 is written as authorisation rather than as a request.

2. Scope

In scope

• The NEXUS web application and its API
• Authentication, session handling and access control
• The customer and supplier portals

Out of scope

• Denial of service, volumetric or resource-exhaustion testing
• Social engineering, phishing, or any approach to staff or customers
• Physical access
• Third-party services NEXUS depends on - MongoDB Atlas, Render, Vercel, Stripe, Xero, OpenAI. Report those to the provider; we will help if you tell us.
• Findings from automated scanners with no demonstrated impact
• Missing security headers, absent SPF/DMARC records, or TLS configuration preferences, unless you can show concrete exploitation

3. Authorisation

If you act within section 2 and follow section 4, we authorise your testing of NEXUS for the purpose of finding and reporting security vulnerabilities. We will not pursue or support any civil or criminal action against you for that work, and we will not ask you to sign a non-disclosure agreement as a condition of reporting.

This authorisation covers systems we operate. It cannot cover a customer's own deployment - NEXUS is single-tenant, each customer has their own instance, and only that customer can authorise testing of theirs.

4. How to report

Email security@nexusmes.co.uk. Please include:

• What you found and where - the URL, endpoint or parameter
• How to reproduce it, step by step
• What an attacker could actually do with it
• Any proof-of-concept, logs or screenshots

Please do not access, modify or download other people's data. If you reach a point where you could, stop - the fact that you got there is the finding, and demonstrating it further does not strengthen the report.

5. What to expect

NEXUS is built and maintained by one person, so these are what can honestly be met rather than what sounds impressive:

If a fix will take a while, you will be told why rather than left waiting. We will credit you by name in the release notes if you want that, and not if you do not.

There is no bug bounty - no payment is offered. Saying so plainly is fairer than leaving it ambiguous.

6. Personal data

If a vulnerability has exposed personal data, that is a personal data breach under UK GDPR and carries a 72-hour notification duty to the ICO from the point of awareness, plus notification to affected individuals where the risk is high. Say so explicitly in your report if you believe personal data was reachable - it changes the clock we are working to, not just the priority.

Our data retention schedule and processing detail are available to customers and prospective customers on request from the address in section 8.

7. Standards this follows

British and UK-applicable:

• NCSC Vulnerability Disclosure Toolkit - the UK government guidance for exactly this. It names three components: a communication route, a policy, and a security.txt file. This document is the policy; section 8 covers the other two.
• BS ISO/IEC 29147 - vulnerability disclosure - and BS ISO/IEC 30111 - vulnerability handling. Both are BSI-adopted British Standards.
• Computer Misuse Act 1990 - see section 1.
• UK GDPR / Data Protection Act 2018 - see section 6.
• RFC 9116 for the security.txt format. This is an IETF specification rather than a British standard, included because the NCSC toolkit explicitly recommends it - a file format, not a jurisdiction.

PSTI Act 2022 does not apply. The Product Security and Telecommunications Infrastructure regime mandates disclosure policies for consumer connectable products. NEXUS is business-to-business software and is out of its scope. Noted here so it is visibly considered rather than overlooked.

For reporting matters onward: the NCSC for national-level incidents, Action Fraud for criminal activity, and the ICO for personal data breaches.

8. Contact

All three components of the NCSC toolkit are in place:

• Reporting address - security@nexusmes.co.uk. A role address rather than a personal one, deliberately: this policy is read by researchers and by prime-contractor assurance teams, and an address that cannot be handed on later would have to be reissued along with the policy.
• This policy - the document you are reading, at /security-policy.html.
• security.txt - machine-readable, at /.well-known/security.txt, per RFC 9116.

There is no PGP key. If your report needs encryption before you will send it, say so at the address above and we will arrange a channel.

9. Review

Annually, and whenever the scope in section 2 changes - a new portal, a public API surface, or the first customer-operated deployment. The Expires field in security.txt carries the same anniversary, so a lapsed review shows up as an invalid file rather than as nothing at all.