Coordinated Vulnerability Disclosure (CVD) Policy

Last updated May 4, 2026

At Netsec, the security of our systems, the software we ship, and the customers who rely on us is a first-order concern. No technology is ever flawless, and we believe that working openly with skilled security researchers anywhere in the world is one of the best ways to find and fix weaknesses before they are abused. We want researchers to feel safe coming to us with what they find — this policy is how we make that concrete.

If you think you have found a security issue in something Netsec operates or publishes, please tell us. We will work with you to confirm and resolve the issue, give you credit if you want it, and disclose the details on a coordinated timeline.

This policy explains how to send us a vulnerability report, what is in and out of scope, what we ask of you while you are testing, and how long we ask you to hold off on publishing before we have a fix in place. Personal data you share with us while reporting is processed under our Privacy Policy, on the legal basis of our legitimate interest in keeping our systems and our customers' data secure.

Guidelines

While researching in scope, we ask that you:

  • Take all reasonable steps to avoid privacy violations, degradation of service for other users, disruption of production systems, and any destruction or modification of data.
  • Only run an exploit to the extent strictly necessary to confirm that a vulnerability exists. Do not use it to gain further access, exfiltrate data, establish persistence, deploy implants, or pivot to other systems — either ours or anyone else's. Once you have proof, stop testing and tell us.
  • Keep details of any vulnerability you find confidential until we have published an advisory, or until we have agreed otherwise with you in writing. See Coordinated Disclosure below for the full timeline.
  • Do not access, modify, or store data that does not belong to you. Use your own test accounts and your own data for research; if our platform does not let you create one, ask us and we will help.
  • If you inadvertently access, modify, or copy data belonging to someone else — even briefly — stop, document what happened, delete any copies you made, and tell us at security@netsec.it so we can investigate and notify whoever needs notifying.
  • If you are unsure whether something you are about to do is allowed under this policy, ask us first at security@netsec.it. A short email beats a complicated conversation later.

Scope

The following assets are in scope for this policy:

  • The Netsec marketing website at netsec.it and any subdomain Netsec operates directly.
  • Public source code we publish under github.com/netsec-it, and any released artefacts that originate from those repositories.
  • Email-related infrastructure for the @netsec.it domain (SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI).
  • DNS, TLS, and certificate hygiene for the domains above.
  • Browser-side hardening on the marketing website (CSP, response headers, similar controls) where you can demonstrate concrete impact.
  • Supply-chain issues that demonstrably affect software we ship — for example, a compromised release artefact or a malicious dependency we have pulled into a published project.

We also welcome reports of operational-security issues that materially affect Netsec or our customers even if they are not a classical technical bug: phishing kits impersonating us, credentials of Netsec staff appearing in public dumps, look-alike domains, and similar.

Reporting a vulnerability

Send your report by email to security@netsec.it. If your report contains sensitive details or working exploit code, ask us first and we will send you a one-time end-to-end-encrypted upload link so the material does not transit unprotected over email.

A useful report includes:

  • A description of the affected component and the impact you believe the vulnerability has.
  • Step-by-step instructions to reproduce, ideally with the smallest reliable proof of concept — payloads, request/response captures, screenshots, or a short screen recording all help. Please label and protect any exploit code carefully.
  • Any other technical details, configurations, or test data we would need to reproduce the behaviour locally.
  • Optional but appreciated: a CVSS v3.1 or v4.0 vector, your test signature (custom header / known string) and the approximate UTC timestamps of your tests so we can correlate with logs, and your preference for public credit (and the name or handle to use).

Please keep us informed of new information as it becomes available — reproduction steps that change, additional affected endpoints you discover, or third parties you have also reported the same issue to.

We acknowledge new reports within two business days (Europe/Paris), provide a triage decision within seven calendar days, and update you at least every fourteen days while remediation is in progress.

Exclusions

While researching, please refrain from:

  • Denial-of-service or resource-exhaustion attacks.
  • Spamming, mass mail, or abuse of contact forms.
  • Social engineering — including phishing, vishing, and smishing — of Netsec staff, contractors, customers, or our suppliers.
  • Physical attempts against Netsec offices, equipment, or any facility we use.
  • Any interaction with, or unauthorised access to, data that does not belong to you.

Reports whose only finding is the output of an automated scanner with no demonstrated impact, missing best-practice headers on static assets, self-XSS, or low-impact issues on endpoints with no sensitive state will typically be closed as informational. We are still happy to discuss best-practice hardening — just don't expect a long investigation.

Third-party bugs

If a report turns out to affect a third-party library, an upstream project, or another vendor (for example, Cloudflare, Next.js, or a package we depend on), we reserve the right to forward the relevant details to that party so the fix can happen at the right layer. We will do our best to coordinate and keep you informed throughout, and we will not share your name or contact details with a third party without your explicit agreement.

Safe Harbor

To encourage good-faith reporting, Netsec will not bring or support legal action against you, and will not refer you for law-enforcement investigation, for activity carried out in compliance with this policy. We consider research conducted under this policy to be authorised in relation to applicable anti-hacking law (including the French Code pénal art. 323-1 et seq., EU Directive 2013/40/EU, the UK Computer Misuse Act 1990, and the US Computer Fraud and Abuse Act 18 U.S.C. § 1030).

You should be aware that our infrastructure is interconnected with third-party systems and services, and we can only offer this safe-harbor commitment with respect to the components we own and control. If a third party initiates legal action against you in connection with research conducted under this policy, we will take reasonable steps to make it known to that party — or to a court if necessary — that your activity was authorised under our policy.

Safe harbor does not apply if you wilfully exceed the scope of this policy, breach the guidelines above, or use any access you obtain for any purpose other than verifying and reporting the vulnerability.

Coordinated Disclosure

Netsec is committed to fixing vulnerabilities promptly and to publishing the details once a patch is available. We believe public disclosure is an essential part of vulnerability management — everyone benefits when the industry can learn from each other's mistakes. At the same time, disclosure without an available patch tends to put users at greater risk, not less, so we ask researchers to hold off on publishing until our fix is ready.

Our default coordination window is up to ninety (90) days from triage, extended where the fix legitimately depends on an upstream we don't control, and shortened to as soon as the fix lands for low-risk issues. We aim to mitigate critical issues within 7 days, fix high-severity within 30 days, medium within 60, and low within 90 or in the next planned release. If a vulnerability is being actively exploited, we may publish abbreviated guidance immediately and follow up with full details once the fix has shipped.

For software we publish, we will open a GitHub Security Advisory, request a CVE through GitHub's CNA, and publish the advisory with affected and fixed versions, CVSS, CWE, workarounds, and credits at the same time the patched release goes out. For infrastructure-only fixes that have no software artefact for downstream users to upgrade, we may fix silently and document the change internally without a public advisory; you will still receive credit if you want it.

If you believe other parties should be informed before our patch is ready — for example, an industry-wide coordination through CERT-FR or another national CSIRT — please tell us so we can arrange it. We may want to coordinate a joint advisory with you and publish it simultaneously with the fix. By default we prefer to disclose everything we know, but we will never publish your name or any of our communications with you without your permission, except where required by law or where a third party affected by the vulnerability needs to be informed as described above. There may also be sensitive details we ask you to redact from your own write-up, so please run your draft past us before publishing.

Recognition

Netsec does not currently run a paid bug-bounty program. We do maintain a public researcher acknowledgements list on this page and we are happy to provide a written letter of thanks for compliance or performance-review purposes if your employer needs one. If you would prefer to remain anonymous, just say so — we will keep your report confidential.

Acknowledgements

Thank you to the researchers below for working with us under this policy. The list is updated as advisories are published.

No public advisories yet — you could be the first.

Customer-affecting incidents

This policy covers vulnerabilities found in Netsec's own infrastructure and software. If you suspect Netsec is the source of an active security incident affecting one of our customers (for example, you are the customer's incident responder and you suspect a breach upstream of you), please email security@netsec.it and prefix the subject line with [INCIDENT]. The same triage commitments apply, but we will route the report to our incident-response on-call rather than to the regular advisory queue.

Updates to this policy

We may revise this CVD Policy as our scope, infrastructure, or applicable law changes. Substantive edits are tracked in the page's git history, and the “Last updated” date at the top of this page is bumped each time.

Contact

Thank you for helping keep Netsec and our users safe.