A mature process handles a vulnerability in private, acknowledges the reporter, accepts or rejects the report, requests a CVE ID, agrees on a fix, releases it and then announces. The Apache Software Foundation publishes its default process for committers, and a small project can copy the same sequence at its own scale.
The sequence
The Apache security page for committers sets out a default process. It says projects needing a different process must contact the security team and document theirs publicly.
| Stage | What happens |
|---|---|
| Work in private | No public tracker entries, and commit messages must not mention the security nature |
| Report | The reporter writes to the project's security list, or the foundation list if there is none |
| Acknowledge | The project replies to the reporter, investigates, then accepts or rejects |
| CVE | The team requests an ID from the foundation's internal portal |
| Resolve | Agree on a fix privately, draft the announcement, share both with the reporter |
| Announce | Send the vulnerability notice after, or with, the release |
| Complete | Update the project's security pages and add the public link to the CVE record |
Details worth noting
If the project rejects a report, the team writes to the reporter to explain why. If the reporter is unresponsive for a reasonable time, that should not block the project from moving on, especially for high severity issues.
On disclosure detail, the page advises enough information for people to assess the risk to their own system, and no more. Announcements do not normally include steps to reproduce.
The announcement goes to the same places as the release announcement, to the reporter, to the project's security list and to the oss-security list. The page says this is the first point at which any information about the vulnerability becomes public.
Projects should also keep a clear link on their home page to known vulnerabilities and not enter details of security issues in a public bug tracker unless access is restricted to the reporter and project team. The page describes optional project specific security lists, whose membership should be a subset of committers and not a third party notification system.
Scaling it down
You do not need a portal. A one person project can follow the same order with a private advisory feature in its hosting platform.
- Receive reports through a private channel listed in your security policy.
- Reply to the reporter and state whether you accept the report.
- Request a CVE ID if the issue qualifies.
- Develop and test the fix in private.
- Draft the advisory and share it with the reporter.
- Release, then publish the advisory the same day.
- Update your security page and link the public advisory to the record.
For dependents
Reading a project's process tells you what to expect: how fast you will hear, and where. If a project does not publish one, ask how it handles reports.
Quick check
Should I put the fix in a public pull request first?
Under this process, no. Work in private and do not reference the security nature of a commit until announcement.
Do I have to include exploit steps?
The guidance says announcements do not normally include steps to reproduce.
What if the reporter goes quiet?
The page says that should not block the project from continuing.
How Safeguard helps
Safeguard's SBOM and dependency scanning show which upstream versions you depend on, and reachability analysis helps you decide which advisories matter for your code. Compliance and evidence automation can record how you handled each one. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can run the free scan on a manifest to see where you stand.
Sources
- Apache Software Foundation, ASF Project Security for Committers: default vulnerability handling process. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
