As discussed with the community at Suricon 2023, we have started requesting CVE IDs for security issues in Suricata. There was already a “security” ticket class in our ticketing system, so generally we’ll get a CVE ID assigned to these. After consulting Mitre, we’ve started using Github as our CNA, through the Github Security Advisories facility.
Previously, CVE IDs were requested by reporters of security issues, at their digression. This caused most “security” releases, to not have CVE IDs associated with them (we consider a release closing at least one “security” ticket a “security” release)
This policy change will result in more CVE IDs for Suricata, but is not to be read as a degradation in code quality. In fact, we consider it to mean the opposite: we are further professionalizing and maturing our operations. Most security issues we find ourselves are based on our extensive fuzz testing support, for which the Oss-Fuzz project generously provides resources.
We are aware that there is debate about the usefulness of the CVE system, however it is our hope that our use of the CVE IDs will help distributions and vendors to stay current.
CVE IDs are part of the “security” tickets, and will also be made part of release announcements. To view a list of CVE IDs for Suricata, see for example this list. Note that security tickets will remain private for at least 2 weeks after a release.
For our security policy, please have a look at: