The oss-security list is a public mailing list for discussing security flaws in open source software. To post an announcement, use plain text, put the software name, versions and vulnerability type in the subject, and include the essential detail in the message itself, not only as a link. Anyone can post, though new posters are moderated.
What the list is for
The charter says the group exists to encourage public discussion of security flaws, concepts and practices in the open source community. Members include projects, distributors, researchers and developers. Anyone can send mail, regardless of membership, and non-members and new members have messages moderated to keep discussion on topic and positive.
Content guidelines
The wiki lists simple rules for posts:
| Rule | Why it helps |
|---|---|
| English, plain text | Readable by every subscriber and archive |
| Subject names the software, versions and vulnerability type | A subject of just a CVE number is not appropriate |
| Essential detail in the message body | Links alone are not enough |
| Stay on topic | It is a security list |
The guideline on detail is the most useful one. The message should stay valuable even with all external resources gone. That also helps downstream readers who triage by scanning subject lines.
A good subject line
The wiki gives a pattern: name, version and weakness. A subject that reads like "Acme Placeholder 1.0 buffer overflow" with the identifier is fine, while a bare identifier is not.
When it is the right venue
Together with the distribution lists, oss-security is the public side. The distribution policy says that an issue which is already public, or will be public right away, should be posted to oss-security instead of the private lists. The Apache project's process for committers also lists oss-security among the destinations for a vulnerability announcement, alongside the project's own channels and the reporter.
Steps for a maintainer announcement
- Publish your advisory on your own site or repository first, so there is a canonical record.
- Write a short plain text summary: affected versions, fixed versions, impact, workaround.
- Use a subject with software, version range and weakness.
- Include the CVE identifier if you have one, and a link to the advisory as an addition.
- Post at the same time as the release, or right after.
- Reply to follow up questions in the thread so the record stays complete.
What consumers get
A public list gives downstream teams one more feed to watch, and an archive that survives a project's own website changing. If you track a critical open source component, reading this list is a cheap way to hear early.
Try it yourself
Click through it at your own pace, or open it full screen. See how a new issue is surfaced, and compare that with how a public mailing list post would reach you.
Quick check
Do I need to subscribe to post?
No. Anyone can send mail, though messages from new members are moderated.
Can I post only a link to my advisory?
Links are fine in addition to detail, but a post made only of links is not acceptable under the guidelines.
Should the subject be the CVE number?
No. It should name the software, versions and vulnerability type.
How Safeguard helps
Safeguard's zero-day discovery and dependency scanning watch for newly published issues in the components you actually use, and reachability analysis helps you judge whether your code touches the affected path. Policies and gates can hold a risky version out of a release. Autonomous remediation can open fix pull requests; it is off by default, with every category on Manual. Start with the free scan.
Sources
- Openwall, oss-security mailing list: charter and content guidelines. Fetched 19 October 2026.
- Openwall, Operating system distribution security contact lists: guidance on public issues. Fetched 19 October 2026.
- Apache Software Foundation, ASF Project Security for Committers: announcement destinations. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
