Vulnerability disclosure policy

This policy covers the assets we operate ourselves and can fix ourselves. Within those limits and on the conditions below, it amounts to authorisation to test.

• The domains nudibranches.tech and www.nudibranches.tech, and the pages they serve.
• The well-known endpoints of this site, including /.well-known/security.txt.
• The repositories published under github.com/nudibranches-tech and the packages released from them.
• The publication chain of this site: dependencies, continuous integration, deployment configuration.

Writing to us about something out of scope will not annoy us — we will point you the right way. But we will not be able to fix anything, and the authorisation to test does not extend there.

• Any infrastructure owned by a client or operated on their behalf. We have no standing to authorise you there, and an unauthorised test on a third party remains an intrusion.
• The Hyperfluid product and the hyperfluid.cloud domain, which fall under a separate ⟨product policy to be published⟩.
• The third-party services we use — host, audience measurement, form relay: please use their own programmes.
• Social engineering aimed at our staff, our clients or our suppliers, and physical intrusion.
• Any form of denial of service, load testing or automated bulk sending.
• Raw scanner output with no demonstrated impact: missing headers with no exploitation, mail configuration with no concrete abuse scenario, a library version flagged as outdated with no exploitation path.

Write to our contact address with SECURITY in the subject line. The message is read by an engineer, not by a qualification form.

A workable report states: the asset concerned and its exact address, the reproduction steps, the impact you demonstrate, the date and time of the test, and the source IP address if you know it — that lets us tell your traffic apart from the rest. A screenshot or a recording helps. French and English are handled equally.

We do not publish a public key for encrypted reports yet: ⟨PGP key to be published⟩. If your finding requires one, write to us first without technical detail and we will agree on a channel. ^▪

These are the times we aim for, counted in working days from receipt. They are written down so you can hold us to them. ^▪

• Acknowledge receipt within three working days, with a human reply.
• Tell you within ten working days whether we accept the report, with our severity assessment — and the reason if we do not accept it.
• Fix a critical vulnerability within thirty days, and others on a schedule we share with you.
• Update you at least once a month for as long as the matter is open.
• Tell you when the fix is deployed, and let you verify it.

The authorisation to test given above is conditional. These five points are the conditions.

• Stay in scope, and stop as soon as unintended access opens up.
• Do not read, copy, modify or delete any data that is not yours. A proof of concept is demonstrated on an account you control.
• Do not degrade the service, do not install a backdoor, do not leave anything behind.
• Give us ninety days before publishing, unless we agree to shorten that period.
• Do not make the details conditional on payment.

Research carried out in good faith and in line with this policy will lead to no civil action and no criminal complaint from us. We will treat it as authorised by the party responsible for the systems concerned, which removes its fraudulent character. ^§

We cannot bind the public prosecutor: criminal proceedings are not ours to waive. Nor does this commitment bind a third party, or a client whose infrastructure was touched. That is precisely why the scope above is written so narrowly. ^▪

If a third party threatened you over a report made in line with this policy, tell us: we will confirm in writing, without delay, that the work was authorised.

We pay no bounty, in cash or in kind, and we run no bug bounty platform. This is not a negotiating position: it is information given before you spend your time.

What we offer in return: a public, named credit in the fix note if you want one, and an engineer's answer on the substance of what you found.

We commit to publishing a fix note for any accepted vulnerability affecting an asset covered by this policy, with the report date, the fix date and the researcher's credit if they accept one. Publishing a fix is more useful to everyone than keeping quiet about it. ^▪

The ninety-day period runs from the acknowledgement of receipt. It can be shortened by agreement, or extended if the fix depends on a third party — in which case we tell you which one, and why.

This policy is declared at the root of the site under RFC 9116, at /.well-known/security.txt. The file carries the contact address, the languages handled, its canonical address, the address of this page and an expiry date. ⁽¹⁾

An expired file should be treated as unmaintained. If you are reading this after the expiry date above and it has not been pushed forward, write to us anyway — and tell us about the lapse, it is a report like any other.