Being a security tool itself, the security of Suricata itself is naturally of great importance. This document describes the policy around security issues as well as how to report them.

If you believe you found a vulnerability, please report it to us as described in this document.

We will determine the severity of each issue, taking into account our experience dealing with past issues, versions affected, common defaults, our estimate of exploitation complexity, part of the code affected, and use cases. We use the following severity categories:

• CRITICAL Severity. This affects Tier 1 features that are enabled by default where the issue disrupts availability of the service, leading to severe loss of visibility and/or availability. Remotely triggerable traffic based code execution, crashes, or evasions with a wide scope are considered to be in-scope for this severity. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to address these as soon as possible.

• HIGH Severity. This includes issues that are of a lower risk than critical, perhaps due to being disabled by default Tier 1 or affecting Tier 2 and Community features, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control.

• MODERATE Severity. This includes issues like crashes or evasion in Tier 2 and Community features that are not enabled by default. These will in general be kept private until the next release, and that release will be scheduled so that it can roll up several such flaws at one time.

• LOW Severity. This includes issues such as those that only affect the Suricata command line utilities, or unlikely configurations. These will in general be fixed as soon as possible in latest development versions, and may be backported to older versions that are still getting updates. These will be part of the Changelog as a security ticket, but they may not trigger new releases.

Note that we'll be refining the levels based on our experiences with applying them to actual issues.

We will request a CVE ID for an issue if appropriate. Note that multiple issues may share the same CVE ID.

We work with the Github CNA, through the Github Security Advisory (GHSA) facility.

The GHSA's will be published at least 2 weeks after the public release addressing the issue, together with the redmine security tickets.

4 levels are defined: Tier 1, Tier 2, Community and Unmaintained.

These are documented in https://docs.suricata.io/en/latest/support-status.html

For reporting security issues, please use [email protected].

If you report a security issue to us, please share as much detail about the issue as possible: pcaps, attack scripts, potential fixes, etc. If you share pcaps or other data, please clearly state if these can (eventually) enter our public CI/QA.

We will assign a severity and will share our assessment with you.

We will create a security ticket, which will be private until at least 2 weeks after a public release addressing the issue.

We will acknowledge you in the release notes, release announcement and GHSA. If you do not want this, please clearly state this. For the GHSA credits, please give us your github handle.

Please let us know if you've requested a CVE ID. If you haven't, we can do it.

OISF does not participate in bug bounty programs, or offer any other rewards for reporting issues.