In an open source project everything happens in public: issues, discussions, reviews, commits. It is one of its strengths, but it becomes a problem when someone discovers a vulnerability. If the flaw is described in an open issue before a fix exists, anyone can exploit it against users. That is why even the smallest project needs a process, simple but written down, for receiving and handling security reports.
The SECURITY.md file
The starting point is a SECURITY.md file at the root of the repository. Many hosting platforms display it prominently. It should answer a few questions:
- which versions are supported and receive security fixes;
- how to report privately: a dedicated email address, a form or the platform's private reporting feature;
- what to include in the report;
- indicative timelines: how soon an acknowledgement will arrive;
- disclosure policy: how and when the vulnerability will be made public.
A minimal example:
## Supported versions
Versions 3.x and 2.9.x receive security fixes.
## Reporting a vulnerability
Do not open a public issue. Use the repository's private
reporting feature or write to the project's security address.
Include the version, steps to reproduce and estimated impact.
You will receive an acknowledgement within five working days.
Coordinated disclosure
The most common model is coordinated disclosure: whoever discovers the flaw reports it privately to the project, the project prepares a fix and, once it is released, both make the details public. A maximum deadline is often agreed, after which disclosure will happen anyway, so that a report cannot be ignored indefinitely.
The typical process has several stages:
- receiving and acknowledging the report;
- verification: reproducing the problem and assessing its severity;
- fixing in a private branch or a restricted repository;
- requesting an identifier, where applicable;
- releasing the fixed versions;
- publishing the advisory with a description, affected versions and the solution;
- crediting the reporter, if they wish.
Assessing severity
Not all vulnerabilities are equal. A few questions determine priority:
- is authenticated access required, or is an anonymous request enough?
- can the attack be carried out remotely, or does it need local access?
- what does the attacker gain: reading data, modifying it, executing code?
- is the default configuration vulnerable, or only a rare one?
There are standardised scoring systems, such as CVSS, that turn these questions into a number. They are useful for communicating consistently, but the judgement of those who know the code remains essential.
CVE identifiers and advisories
A CVE identifier gives the vulnerability a unique name, used by scanners, distributions and dependency management tools. Many hosting platforms and several foundations can assign one directly to the project.
The published advisory should contain:
| Field | Content |
|---|---|
| Description | What happens, without a ready-to-use exploit |
| Affected versions | Precise range |
| Fixed versions | Where the fix is |
| Severity | Rating and rationale |
| Mitigations | What to do if you cannot update right away |
| Credits | Who reported it, if they agree |
Mistakes to avoid
- Fixing silently: a commit saying «fix a small issue» with no advisory leaves users with no reason to update, while anyone reading the diffs understands exactly what is going on.
- Discussing the flaw publicly before the fix, even just in a comment.
- Ignoring the reporter: people who get no answer often end up publishing on their own.
- Having no plan for old versions: if a version is no longer supported, the advisory should say so clearly.
For reporters
If you discover a vulnerability in someone else's project, follow the stated procedure, provide enough information to reproduce the problem, respect the agreed timelines and do not exploit the flaw beyond the minimum needed to demonstrate it. If the project has no private channel, look for a direct contact for the maintainers or turn to the platform hosting it.
In my work I have seen that the difference between a contained incident and a serious one often lies in the first forty-eight hours after the report: already knowing who receives it and what to do avoids improvisation.
In short
- Every project needs a
SECURITY.mdwith supported versions and a private channel. - Coordinated disclosure protects users until a fix is available.
- Severity, a CVE identifier and a complete advisory help users react quickly.
- Never fix silently, and always reply to reporters.
