An auditor wants proof that vulnerabilities are received, assessed, fixed and disclosed on a repeatable path. A maintainer can show that with a security policy, a private reporting channel, a record per report, and published advisories. You do not need a large team, but you do need dated evidence for each step.
What does a defensible process look like?
The OpenSSF guide for open source maintainers recommends coordinated vulnerability disclosure: a reporter and the project work together, privately, from discovery to a public fix. It says reporters have done the project a favour, and that the intake process should be discoverable, smooth and low friction. Clear expectations about reporting and triage reduce friction as an issue moves toward resolution.
That gives you the spine for evidence. An auditor will ask four questions. How does someone report a problem? Who decides what it means? How do you fix and release? How do users find out?
How do you take reports?
Two pieces cover intake. First, a security policy file in the repository that tells people how to report. GitHub's docs describe creating a security policy to give instructions for reporting vulnerabilities. Second, private vulnerability reporting. GitHub lets owners and administrators of public repositories switch it on, so researchers see a Report a vulnerability button and can submit privately instead of opening a public issue.
Evidence an auditor can check: the policy file with a commit date, a screenshot or settings export showing private reporting enabled, and a monitored contact for people who do not use that platform.
How do you triage, fix and disclose?
GitHub repository security advisories let maintainers create a draft, discuss impact privately, collaborate on a fix in a temporary private fork, and publish when a patch is ready. You can credit contributors. Advisories for supported ecosystems are published to the GitHub Advisory Database. The advisory is your durable record: it has dates, affected versions, fixed versions and a description.
For machine-readable data, the OSV schema describes a common format for vulnerability records that tools consume. If your ecosystem has its own advisory feed, publish there too.
Constructed example: a small parser library receives a private report on a Tuesday. The maintainer opens a draft advisory the same day and notes a severity and affected range. A fix lands in a private fork on Friday, a release follows, and the advisory is published with credit to the reporter. The audit trail is three dated artifacts: the report, the draft with its comments, and the published advisory.
What gaps do auditors often find?
- No written target for acknowledging a report, so nobody can show it was met.
- Fixes released with no advisory, leaving downstream users without a record.
- Reports handled in email only, with no dated log.
- Dependencies of the project itself never scanned, so the project ships known issues in its own tree.
Be honest about capacity. A policy that promises a response in 24 hours is worse than one that promises a week and meets it.
What to do
- Add a security policy file stating how to report, what you will acknowledge and what you will not.
- Enable private vulnerability reporting, and test it by filing a report yourself.
- For each report, create a draft advisory and keep notes on severity, affected versions and decision.
- Fix in a private fork where the issue is not yet public, then release.
- Publish the advisory with fixed versions and credit.
- Scan your own dependencies on a schedule and record the results.
- Once a quarter, export your reports, advisories and scan results into one folder with dates.
- Write a short note on who covers when you are away.
Safeguard SBOM and dependency scanning and the Gold free scan can produce dated dependency evidence for a project, though the disclosure process itself is yours to run.
Quick check
Do I need a CVE for every issue?
Not necessarily. A published advisory with versions and a fix is the core evidence. Request a CVE where your ecosystem expects one.
Is private reporting required?
It is not mandated by the guides we read, but it gives researchers a safe channel and gives you a dated record, which helps in an audit.
Sources
- Maintainer guide, OpenSSF Vulnerability Disclosure Working Group, fetched 18 October 2026
- About repository security advisories, GitHub Docs, fetched 18 October 2026
- Configuring private vulnerability reporting, GitHub Docs, fetched 18 October 2026
- Open Source Vulnerability schema, fetched 18 October 2026
Last reviewed: 18 October 2026.
