How to report a vulnerability#
Email security@narvy.io. This is the single channel for security reports. It reaches the founding team directly.
A useful report tells us:
- What the vulnerability is, and where (a URL, an API endpoint, a CLI command, a specific version).
- How to reproduce it, step by step. A short proof of concept is worth more than a long description.
- What an attacker could actually do with it, so we can judge severity honestly.
- Whether you believe it is already being exploited, or has been disclosed anywhere else.
Write in English or French, whichever is easier for you. If you are not sure something counts as a vulnerability, send it anyway. We would rather read one report too many than miss the one that mattered.
Scope#
In scope means anything we build and operate:
- The web platform at
narvy.ioand its API. - The Narvy command-line tool and the analysis engines it ships.
- Our authentication, billing, tenant-isolation and report-storage logic.
- Our published infrastructure that directly serves the product.
Out of scope, and please do not test these:
- Denial-of-service, volumetric or load testing, and anything that degrades service for other users.
- Social engineering, phishing, or physical attacks against our team, our users, or our providers.
- Third-party services we merely rely on (for example our hosting, payment or email providers). Report those to the third party; tell us too if it affects our users.
- Findings that require a compromised device, a rooted browser, or a person willingly acting against their own account.
- Reports from automated scanners with no demonstrated, reproducible impact.
Test against your own account
Use a free account you control, or data you own. Never access, modify or exfiltrate another customer's code, scans or reports. If a vulnerability would expose someone else's data, prove it against your own two accounts and stop there. Tell us what you found rather than how far you could have gone.
What we commit to, and when#
These are commitments, not aspirations. If we ever slip one, we will tell you why.
| Step | Target |
|---|---|
| Acknowledge your report | Within 72 hours (3 business days). |
| Confirm whether we can reproduce it, and a first severity | Within 10 business days. |
| Keep you updated on the fix | At least every 14 days until it is resolved. |
| Agree a coordinated public disclosure date | Default 90 days from acknowledgement, sooner if a fix ships sooner, later only by mutual agreement. |
Separately, and regardless of your report, if a vulnerability in a shipped Narvy component turns out to be actively exploited, or we suffer a severe security incident, we are legally required as an EU manufacturer to notify the authorities on a much faster clock: a first warning within 24 hours. Section 7 explains that obligation. It runs in parallel with, and does not replace, our commitment to you as the reporter.
Safe harbour for good-faith research#
We will not initiate or support legal action against you for security research that is carried out in good faith and stays within this policy. Specifically, if you:
- stay within the scope in section 2 and follow the rules in section 5,
- act to avoid harm to people, data and service availability,
- only ever access data that is your own, and stop at the first sign you could reach someone else's,
- give us a reasonable chance to fix the issue before you tell anyone else,
then we consider your research authorised, we will not treat it as a breach of our Terms of Service, and we will not report you to law enforcement or pursue a civil claim over it. If a third party brings action against you for research that followed this policy, tell us and we will make clear, in writing, that your activity was authorised by us.
The limits of this promise
This safe harbour is a commitment from LIMITLESS KNOWLEDGE about how we will treat you. It cannot waive rights that belong to third parties, and it is not legal advice about French or EU law. Good faith is the whole of it: acting in bad faith, causing avoidable harm, or going outside this policy takes you outside the protection.
What we ask of you#
- Give us a reasonable time to investigate and fix before any public disclosure. Our default is 90 days; talk to us if you think it should be shorter.
- Do not use, sell, publish or retain any data you come across. Delete anything you pulled as soon as you have reported it.
- Keep the details of the vulnerability confidential until we have agreed it is fixed and a disclosure date has passed.
- One issue per report where you can. It keeps the fix and the credit clean.
On rewards, honestly: we do not run a paid bug-bounty programme today, and we will not imply one we cannot fund. What we offer is a fast, respectful process, public credit if you want it, and a standing intention to introduce a funded programme as we grow. If that matters to you, say so, and we will be straight with you about where we are.
Coordinated disclosure and credit#
We practise coordinated disclosure. We fix the issue, we agree a date with you, and only then do either of us go public. If you would like credit, we will name you (or your chosen handle) in the release notes or an advisory. If you would rather stay anonymous, that is equally fine.
Where a vulnerability warrants it, we will request a CVE identifier so that our users and the wider ecosystem can track the fix. If your finding affects a third-party component we ship, we will coordinate with that project's maintainers as well, and keep you in the loop.
Regulated reporting under the Cyber Resilience Act#
Narvy is a product with digital elements placed on the EU market, and LIMITLESS KNOWLEDGE is its manufacturer. Under Regulation (EU) 2024/2847, the Cyber Resilience Act, the reporting obligations for manufacturers in Article 14 start to apply on 11 September 2026. This section describes the process we have documented to meet them. It is our stated process, to be confirmed with counsel; it is not a legal interpretation you should rely on for your own obligations.
Two things trigger a mandatory notification from us:
- An actively exploited vulnerability contained in a shipped Narvy product (the platform or the CLI); and
- A severe incident having an impact on the security of a Narvy product.
When one of those is confirmed, we notify both ENISA and the CSIRT designated as coordinator for our Member State, through the single reporting platform that ENISA operates under Article 16 of the Regulation. Because our establishment is in France, the coordinating CSIRT is the French national CSIRT, CERT-FR, operated by ANSSI. We report on the following cadence, measured from the moment we become aware:
| Deadline | What we submit |
|---|---|
| Within 24 hours | An early warning: that an actively exploited vulnerability or severe incident has occurred, including, where known, whether it is suspected to be caused by unlawful or malicious acts. |
| Within 72 hours | A notification: general information about the affected product, the general nature of the exploit or incident and its severity, and any corrective or mitigating measures taken or that users can take. |
| Within 14 days (vulnerability) or 1 month (incident) | A final report: for a vulnerability, within 14 days of a corrective or mitigating measure becoming available, describing the vulnerability, its severity and impact and the fix; for a severe incident, within one month of the notification, with a detailed description, severity, impact and the mitigations applied. |
If you have reported a vulnerability to us that turns out to be actively exploited, this obligation is why you may see us move fast and, in parallel, notify a public authority. It does not change our commitment to coordinate the public disclosure with you.
What this page does not claim
This is our own manufacturer reporting process. It is separate from what the Narvy product does for your compliance work. We do not claim any CRA certification, and we do not claim the product maps the Cyber Resilience Act clause by clause. Where our reports reference regulatory frameworks, we say what is measured and what is derived.
Contact and encryption#
- Security reports
- security@narvy.io
- Everything else security-adjacent
- founders@narvy.io
- Privacy and data protection
- privacy@narvy.io
Encryption: we do not publish a PGP key today, and we would rather say so than list a key we do not actively use. If your report is sensitive and you need to send it encrypted, email security@narvy.io first, with no sensitive detail, and we will agree an encrypted channel and share a key with you.
A machine-readable security.txt pointing here is on our list to publish under
/.well-known/security.txt.
Related documents: Privacy Policy, Terms of Service, legal notice.