Security Release Process
The Zeek Project is eager to work with the community to resolve any security vulnerabilities. We strive to address security concerns in a timely manner, and to properly acknowledge the contributor(s). To report a security vulnerability, please follow the process on our website.
The handling of security issues poses a challenge for any open source project, as maintainers straddle the line between providing the usual transparency into development while shielding users from attacks before they have the means to protect themselves. For that reason, we generally treat severe security issues as confidential until we are ready to publish updates for all currently supported Zeek releases. At that point we will then open source the fix and provide additional context on the vulnerability’s implications.
As we learn about a security issue, we first assess its severity by categorizing the vulnerability into one of the following groups:
-
Critical:
-
Remotely exploitable vulnerabilities that may let attackers elevate their privileges, execute custom code, or modify system assets.
-
Remotely exploitable vulnerabilities that may provide attackers access to highly sensitive site information (e.g., password database, arbitrary files).
-
-
High:
-
Remotely exploitable vulnerabilities that let attackers carry out denial of service attacks leaving Zeek functionality unavailable (e.g., by causing a crash or clogging up resources).
-
Remotely exploitable vulnerabilities that may provide attackers access to relatively insensitive site information (e.g., local IP addresses).
-
-
Medium
- Vulnerabilities that require local system access for exploitation.
- Evasion attacks affecting Zeek's detection & analysis capabilities.
-
Low, or no risk: Anything that’s unlikely to impact a site’s operational security.
-
Out of scope:
- Risks that require control of the scripts loaded into Zeek.
- Risks that require control over the local Zeek installation.
- (See below for more context on being out of scope.)
We may up- or downgrade vulnerabilities based on their likelihood of exploitation. For example, a readily available exploit script that can remotely trigger any Zeek installation out there to immediately crash, would move the vulnerability from High to Critical. Likewise, a report that’s been prematurely, unintentionally, or irresponsibly disclosed would also qualify a vulnerability’s severity to be upgraded. On the other hand, a vulnerability that requires an obscure Linux kernel option to be set for exploitation, may move a Critical rating down to High or even just Medium.
We generally exclude experimental functionality from the higher-risk groups. Vulnerabilities inside anything that the release notes refer to as being experimental/preliminary/work-in-progress will be considered as "Low / no risk" as long as the functionality is not automatically enabled/active with a default Zeek installation.
A note on out-of-scope vulnerabilities: We consider any vulnerabilities out of scope that we can't realistically expect to fix through code changes in Zeek. For example, if attackers control the Zeek scripts being loaded (e.g., through a malicious Zeek package), they'll have various ways to execute custom code, most directly by simply calling Zeek's
system()built-in function. Likewise, if they control the host system sufficiently to impact Zeek's runtime behavior (e.g., by replacing an external tool that Zeek relies on, or manipulating Zeek'sPATH), there's not much we can do about that. Fundamentally, these risks stem from Zeek providing an unrestricted execution environment, just like many other language platforms do. We will still attempt to address such issues when we learn about them, in particular if they involve potentially surprising behavior of Zeek's standard scripts (e.g., shell executions hidden inside frameworks should certainly sanitize their command line arguments). However, we will treat them as a standard issues outside of this security process.
It is the responsibility of the Zeek Security Team (ZST; see below) to assess the severity of an incoming security report. The rating then determines whether the issue requires confidential treatment:
-
For Low & Medium vulnerabilities, we will develop the patch inside the public git repository, and then push it out with the next patch release (which we may decide to pull forward). In this case, we will also add the issue to the public meta ticket where we collect changes scheduled to go into the next patch release.
-
For High & Critical vulnerabilities, we will track the issue inside a separate, non-public issue tracker that’s accessible only to members of the Zeek Security Team. We will discuss fixes and proposed patches there, and we will not commit them to any public repository at this point. We expect ZST members to treat the information as confidential until openly published: They must not reveal any specifics to people who are not already privy to the information (unless the group decides that we need to involve additional, trusted people to develop and/or test a fix). Once we have developed a final fix, we collect sign-off from at least two of the Merge Masters (excluding the author of the fix) before proceeding further.
The ZST determines the course of action within at most a week after the initial report. We will then let the reporter know what to expect and begin working on the fix. At this point, we will also let Zeek’s Private Distributors Group (PDG; see below) know that a security release is forthcoming, for now without details on the specifics of the vulnerability and release timing. Once we have a finalized fix (meaning sign-offs were obtained for a High/Critical severity patch, or else a Low/Medium severity patch has been merged into the master branch), the ZST decides on a release date as well as the lead time for sending patches to the PDG. We will base the timeline on the issue’s severity, per the following table:
| Severity | Max time to fix release | Lead time for PDG |
| Critical | ASAP | 24 hours |
| High | 4 weeks | 2 business days |
| Medium | 12 weeks | 1 week |
| Low | With next regular release | (no advance notice) |
Once we have a fix ready and decided on timeline, the distribution will happen in two steps:
-
Ahead of release day, we inform the Private Distributors Group about the upcoming release for levels Medium or higher. The communication will include a description of the issue, an assessment of its severity, and any patches to fix the problem for all currently supported Zeek releases. At the same time we provide this to the PDG, we also send out a public note, without specifics, informing users that a security release is upcoming.
-
On release day, we will first apply the patches to the affected public repositories. We will perform standard regression testing, and then publish updated releases as quickly as possible. Once published, we will announce the releases, including the same information that previously went out to the Private Distributors Group.
The ZST may decide on a custom timeline, or a different process, on a case-by-case basis. It may choose to include a fix into a broader update that’s already planned as long as doing so does not further delay its release.
The Zeek Security Team consists of a small, trusted group of people who have volunteered to help triage and fix Zeek security issues. The team can be collectively reached at security@zeek.org.
The Zeek Security Team automatically includes all the Merge Masters as well as the Chair of the Leadership Team. Additional Team Members may be selected to join as well. Any change in membership must be approved by 2/3 of the current group, as well as by 2/3 of the Merge Masters.
Understanding that several downstream projects depend on Zeek, we maintain a small, carefully vetted list of third-party distributors of Zeek who we provide with advanced notice of upcoming security updates. Due to the sensitivity of the information being distributed, we require all of the following for an organization to become part of this group:
-
Have an actively monitored security email alias for us to use.
-
Have a clearly defined individual as a point of contact, along with a member of the Zeek Security Team vouching for that person.
-
Be a Zeek distributor with a user base not limited to their own organization.
-
Have a verifiable track record of providing security updates for their distribution of Zeek.
-
Do not be a downstream, or rebuild, of another 3rd party distribution.
-
Be an active contributor to the Zeek community.
-
Accept the Embargo Policy that is outlined below.
Communication with the Private Distributors Group will take place over email to the specified aliases, as well as inside a private Slack channel to which the point of contacts will be invited. The email alias of an organization may automatically forward to additional members of the organization; however, the individual point of contact for the organization is responsible for making sure that everyone knows and respects the embargo policy.
If your organization is interested in joining the group, please contact security@zeek.org with the corresponding information. The Zeek Security Team will decide by 2/3 majority vote if you satisfy the requirements. The team may remove group members who no longer qualify likewise with 2/3 majority. Replacements of the point of contact of an organization similarly require a 2/3 majority vote.
The information members receive through their membership in the Private Distributors Group must not be made public, shared, nor even hinted at anywhere beyond the need-to-know within their specific teams, except with the Zeek Security Team’s explicit approval. This holds true until the issue’s public disclosure date/time. Members may not use the information for anything other than getting the issue fixed for their respective distribution's users.
In the unfortunate event that a member shares information beyond what is allowed by this policy, they must urgently inform security@zeek.org of exactly what information leaked and to whom.
(Credit: The specifics on the Private Distributors Group are adapted from Kubernetes security process).