A VDP for Open Source Maintainers: SECURITY.md, Private Reporting, GHSA

ENISA's Single Reporting Platform went live on 11 September 2026, and its FAQ says obligations on open-source software stewards under the EU Cyber Resilience Act start on 11 December 2027. If you maintain a library, that date is not your deadline unless you are a steward as the regulation defines the term. But manufacturers who ship your code will have to report flaws they find in it to you (Article 13(6)), so reports are about to arrive more often and from more professional senders.

A maintainer VDP can be three files and one setting. No budget, no portal, no legal team.

What's affected

Anyone maintaining a public repository that other people depend on. The CRA text matters here in three ways:

• Article 13(6) tells manufacturers who find a vulnerability in a component, including an open source one, to report it to the person or entity that maintains the component, and to share any fix code with them where appropriate.
• Article 24(1) requires open-source software stewards to document, in a verifiable manner, a cybersecurity policy that covers vulnerability handling and promotes voluntary reporting and information sharing within the community. The ENISA FAQ puts the start of steward obligations at 11 December 2027.
• Article 24(3) applies the Article 14(1) notification duty to stewards only to the extent they are involved in developing the products concerned.

If you are a hobbyist maintainer, you may not be a steward at all. The regulation's guidance and the Commission's work on the definition are the place to check. The good practice below is useful either way.

How to check if you're exposed

Look at your repository the way a stranger would.

# Is there a SECURITY.md in one of the usual places?
for f in SECURITY.md .github/SECURITY.md docs/SECURITY.md; do
  printf '%s ' "$f"; gh api "repos/OWNER/REPO/contents/$f" --silent 2>/dev/null && echo found || echo missing
done

# Is private vulnerability reporting enabled?
gh api repos/OWNER/REPO/private-vulnerability-reporting --jq '.enabled'

In the browser, open the Security tab. If there is no "Report a vulnerability" button, a researcher's only options are a public issue or guessing at an email address. The GitHub Docs warn that a public issue or pull request would expose the project to potential exploitation.

What to do now

1. Add a SECURITY.md. GitHub's guidance says it can live in the root, docs or .github folder. Keep it short:

# Security Policy

## Supported versions
We fix security issues in the latest release and the previous minor.

## Reporting a vulnerability
Use the "Report a vulnerability" button on the Security tab of this
repository, or email security@example.org.
Please do not open a public issue.

We acknowledge reports within 3 days and aim to ship a fix within 90
days. We will credit you in the advisory unless you prefer otherwise.

2. Turn on private vulnerability reporting. Per GitHub Docs: open Settings, go to the Advanced Security section under "Security and quality", and click Enable next to "Private vulnerability reporting." Only owners and administrators of public repositories can do it, and it can also be set for an organization through a custom security configuration.
3. Check your notifications. Admins are notified of new private reports only if they watch the repository for all activity or subscribe to Security alerts, and have email enabled.
4. When a report arrives, assess it into one of four outcomes: working as intended, a bug, a feature request, or a vulnerability. Only the last needs the full process.
5. Develop the fix in a temporary private fork from the draft advisory. Private forks lack CI integration, so run tests locally.
6. Request a CVE from the advisory. GitHub is a CVE Numbering Authority, requesting a CVE does not make the advisory public, and GitHub says it usually reviews a request within 72 hours.
7. Publish the advisory and the release together, then credit the reporter. GitHub adds the reporter as a credited collaborator when a private report is submitted.

How to avoid this trap

The OpenSSF guide for open source projects gives specific numbers and warnings worth borrowing.

1. Acknowledge within 1 to 2 days, before you assess. A one line reply is enough.
2. Do not use security@ as your internal coordination alias. The guide advises a separate alias for the team, distinct from intake.
3. If you must offer email, use encrypted transport and also list an address in the policy, so an issue tracker is not the only option.
4. Aim for a team of at least two who can generate security advisories, so a vacation does not stall a fix. Small projects can have the maintainers act as the team.
5. If you cannot ship a full fix when the embargo ends, release a patch that breaks the exploitation chain and say it is partial. If you cannot fix it at all, disclose with workarounds.
6. Release Monday to Wednesday and avoid widely observed holidays.

Why it matters

Open source maintainers carry the same risk as vendors with a fraction of the staff. The OpenSSF guide says to treat declared embargo timeframes as a starting point for negotiation and notes that withholding exploit details helps only for a few days, since attackers can often infer the attack from the patch. That is the real constraint: you will not out wait the people reading your commits.

A clear SECURITY.md also helps your downstream users. When a manufacturer has to document how it handles vulnerabilities in its components, a maintainer who answers fast, publishes an advisory and provides a CVE ID is a supplier it can build a process around.

Try it yourself

Create a throwaway repository, enable private vulnerability reporting, and submit a test report from a second account. Create a draft advisory from it, start a temporary private fork, and walk to the point where you would request a CVE. Delete the draft afterwards. Timing the whole exercise tells you what your acknowledgment promise should be.

Quick check

Sources

• GitHub Docs: Configuring private vulnerability reporting
• GitHub Docs: Privately reporting a security vulnerability
• GitHub Docs: About repository security advisories
• GitHub Blog: Coordinated vulnerability disclosure for open source projects
• OpenSSF guide for maintainers
• Regulation (EU) 2024/2847, Articles 13, 24 and 71
• ENISA Single Reporting Platform FAQ