Updates to the Zeek Security Patch Process
In the brave new world of LLMs, open-source projects are facing a much larger in-flux of security findings. Zeek is no different, and while we have always prided ourselves on the amount of automated scanning we already do to find issues, we have had a large amount of new findings. We have been fortunate enough to have partner organizations specialized in this work doing scans for us, along with our own initiatives. Unfortunately, this has led to a lot of our team having to spend significant amounts of time managing the new findings.
The Zeek project has long had a Security Release Process detailing how we deal with security issues from reporting to release. We’ve found that while this process worked well enough for a small load, it starts to have issues when the numbers grow as quickly as they have. We took some time to revisit this process and made a few changes.
Extension to 90 day window for High severity issues
Our previous policy stated that we would release fixes for all high-severity tickets within 4 weeks, with a lead time for the private distribution group of 2 days. With the 8.0.10 and 8.2.2 releases, we extended this time to 12 weeks. The current industry standard for such tickets is 90 days, so this aligns us more closely with that timeline. The timeline for the other severities remains the same.
Downgrading Memory Bloat Issues to Medium Severity
A lot of the issues that get reported to us involve memory bloating based on pathological sequences of packets. Things you would never see in normal packet feeds, but are possible to be constructed via scripts. Most of these reports require excessive numbers of packets or packets that would never pass through regular routing. We are changing the classification on these reports to be Medium Severity by default. They will still be triaged like any other report, and for egregious cases we may upgrade them to High status.
Using GitHub Security Advisories
GitHub Security Advisories (GHSA) allow projects to track patches created for releases and include a lot of metadata about them such as a description of the fix, the version(s) containing it, the severity of the finding, the reporter status, etc. GHSAs allow us to keep track of all of the patches in a single location, as well as assign CVEs via GitHub’s CVE Number Authority (CNA). The processing time on these assignments is very slow (on the order of months right now), but it’s a capability we didn’t have before. Creating a GHSA is now an official part of the process of working on a patch. All new pull requests for security patches have a draft advisory opened for them and it is reviewed along with the code.
For a list of the currently-released security advisories, visit https://GitHub.com/zeek/zeek/security/advisories.
CVE Assignment
The previous section mentioned using GitHub Security Advisories to assign CVEs to fixed issues. We typically have not assigned CVEs to our security fixes, but recently we have had more reporters asking for these. Our new policy is to assign a CVE automatically for High or Critical Severity tickets, or in any case where the reporter directly asks for it. Again, we’re at the mercy of GitHub’s timing for these, so bear with us if it takes a long time for a number to be assigned.
More Concise and More Automated Release Notes
We typically write all of the release notes for patch releases by hand, with Tim going through each of the merged PRs, determining what the patch fixes, and writing a small patch note. This works fine with small numbers of patches, but falls apart once the numbers grow. One thing that the above GHSA system gains us is the ability to automate this. Starting with the v8.0.10 and 8.2.2 releases, the patch notes are generated via a script from these advisories. This plus the additional review during the patch process ensures that the release notes are consistent (and considerably less work).
A Documented Process for How Security Tickets Get Worked On
We never documented the process for how security tickets get worked on, how they are merged into patch sets for releases, how PDG patch sets are created, how release notes are generated, etc. This is now a document on the Wiki for the Zeek repo that spells out all of the steps involved. We’ll be updating this doc as we refine the process. See https://GitHub.com/zeek/zeek/wiki/Security-Patch-Process for more details.