How Security Vulnerabilities are Reported & Handled in Apache Superset
One of the fundamental tenets of the open-source community is transparency, especially when it comes to addressing security vulnerabilities. This is particularly true for any top-level project (TLP) operated under the banner of the Apache Software Foundation. While members of the Superset community (including Preset) try to make people broadly aware of critical issues (such as this recent example), what we don’t talk about often enough is what happens behind the scenes, and how these issues are tracked from their initial report all the way through to evangelization efforts.
In this post, we'll walk through the not-always-so-obvious steps to report a security vulnerability to Apache projects, the responsibilities of the Superset Project Management Comity (PMC), and how the team report status updates on issues and Common Vulnerabilities and Exposures (CVEs).
Reporting a Security Vulnerability
This step is not exclusive in any way - it might apply to you. While security issues are often discovered by research firms that make a living by doing penetration tests (or “pen tests”), many more of them are discovered by code contributors in the community, or by end users.
If a security vulnerability is discovered in an Apache project, it is typically reported through one of two avenues: either directly to the project's dedicated security email or through the general ASF security mailing list. It is crucial to handle such reports confidentially to minimize the risk of early exposure, which could result in misuse. You can read more about Apache’s general reporting practice here.
For the Superset project specifically, we do not yet have a security@superset.apache.org email yet, but we’re building an official consensus around the policies of managing that address and who may access it. For now, you can email security@apache.org and it will be sent our way.
Update: We do now have a security@apache.org email address (and corresponding team to receive these emails). Please report your security issues there!
What you should not do is post-security concerns as Issues on GitHub or in public Slack channels. In a pinch, you can reach out to the Superset PMC via private@superset.apache.org or refer to our roster if you have questions about reporting an issue.
The role of Superset’s Project Management Committees (PMC)
Once a security issue is reported, it falls under the responsibility of the PMC for the relevant. Apache projects are a meritocracy, with their PMC committee being comprised of committers that have been chosen (via a nomination and voting process) on the basis of merit and active contribution to the project (Superset’s standards are published here).
It may be worth noting that of the 33 Superset PMC members, 20 have worked for Preset, and 10 of those are at Preset today. The remainder of these members continue to be active participants in the PMC within other organizations. While it is not The Apache Way to have a single organization effectively run a project, Preset’s nomination and voting of qualified committers and PMC members (inside and outside of Preset), is a priority, to maintain a healthy and active community.
The responsibilities of the PMC in handling security vulnerabilities include:
Assessment
Once a potential vulnerability is reported, the PMC must swiftly assess and confirm the report. This involves validating the vulnerability, assessing its impact, and prioritizing the required action based on severity.
The Superset PMC typically handles this by means of a private channel on Superset’s Slack workspace, or via a periodic meeting of the Security working group which is part of Superset’s Operational Model. Note that these individual issues may be deemed private, so they might not be discussed individually in meetings/channels where non-PMC members are present.
Once a security vulnerability report is (in)validated, a reply is sent to the reporter as well as the Apache security team, and the Superset PMC. The issue is either accepted or denied, based on the PMCs findings. If the PMC decides to accept the report, then we begin tracking it.
Tracking
Tracking security reports that are in flight involves a couple of processes.
First, the Superset PMC is responsible for keeping the Apache Security team in the loop, as they provide oversight and a certain degree of responsibility for the project’s stewardship. This typically happens via private email correspondence but also gets reported on the project's periodic board reports.
Secondly, the PMC is allowed to have its own means of (privately) tracking the status of issues. In the case of Superset, we have a private kanban board that makes it easy to manage access (adding/removing interested PMC members), and low-friction in terms of updating/tracking the status of things.
Resolution
Following the assessment, the PMC is tasked with developing a fix for the vulnerability. This often requires collaboration within the committee, and sometimes with external contributors. After recently confirming it with the ASF, it is indeed acceptable to discuss an open vulnerability with contributors and/or directly affected parties that are deemed to be on a “need to know” basis (with the expectation that they too keep it under their hat).
It's paramount to design, implement, and test the solution promptly to limit the window of vulnerability. We want not only to get the fix released quickly, but also to make sure we respect the timelines of any reporters who seeks to publish their findings (which is in fact a living for some of these orgs, and finding issues in open source is good PR for them).
Release
Once the issue has been fixed, the PMC is responsible for creating a new release of the project that includes the fix. These are usually released in a patch release (following SemVer processes), but occasionally will be shipped in a minor or major version opportunistically. While getting the fix out the door and into the newest version is the primary objective, we do attempt to backport these fixes to our long-term support (LTS) versions as well. While Superset is still establishing an official definition of LTS, the de facto interpretation is “the most recent major or minor release prior to the current major or minor release.” In other words, while we’re on 2.1.x, we’ll try to support 2.0.x with patches. When we’re on 3.0.x, we’ll try to support 2.1.x with patches. If anyone else in the community wants to participate in building releases that include patches for older versions of Superset, we’d welcome help in our Release Strategy working group.
Once the new release is out, the Superset community will announce the release and the vulnerability to their user community, along with guidance on updating to the patched version. Release announcements happen via several channels including the Apache Superset developer mailing list (which you can join by sending an email to dev-subscribe@superset.apache.org), various places on Superset’s Slack workspace, at Superset’s Town Hall and Release Strategy syncs (available on the community calendar). The specifics of these releases (including noteworthy security patches) are also detailed in release notes published on the Preset blog (such as the recent 2.1 release notes).
Reporting CVEs
PMCs are also responsible for handling reports for "common vulnerabilities and exposures” a.k.a. CVEs associated with their projects. A CVE is an industry standard that identifies specific vulnerabilities. It provides a common naming scheme and a detailed description of the vulnerability. These CVEs are published in various places, but the NIST is the main hub to search for issues.
When a PMC identifies a vulnerability, they will usually apply for a CVE identifier from Apache, which registers one directly, as the Apache Security Team is a CVE Numbering Authority. The report should provide a detailed, accurate description of the vulnerability, its potential impact, and the version of the project in which it was introduced.
The PMC then includes this CVE identifier in all communications about the vulnerability. This allows users and tools to unambiguously refer to each specific vulnerability.
Once a release with the fix is ready, the PMC is responsible for updating the CVE entry to reflect that a fix is available and to provide a reference to the announcement of the new release. The CVE is made public, and the reporter is free to publish their findings and process.
Putting it all together
Here’s a flowchart of the entire process, stem to stern, that shows not only Superset’s workflow, but how Preset layers onto it.
Security at Preset
At Preset, we strive to have an active representation in Superset’s community, with many of our team having been voted in as Committer or PMC members. Since our team is deeply involved in fielding security reports, we are able to take action quickly and make sure our service is patched and secured, before any Apache releases are made or CVEs published. Note that Apache releases are usually on a 3+ month cadence, require a minimum 3-day vote, and are typically subject to multiple release candidates, whereas Preset is often able to ship a patch within 24-48 hours.
Often, this is not a concern, however, since we take security very seriously. Thanks to our team’s expertise with Superset configuration, we’ve made a lot of careful and strategic choices and modifications to secure our offering. We are regularly subjected to audits and pen tests as part of our SOC2 Type 2 compliance.
Additionally, through diligent dependency patching as part of our own SecOps process (utilizing Snyk, Dependabot, and more), we ensure that your Superset instance remains up-to-date and resilient against vulnerabilities. At the infrastructure level, we have implemented multiple layers of defense such as firewalls, application firewalls, and intrusion detection systems. Data protection is paramount for us, this implies multiple levels of backup, with multi-regional replication, encryption at rest and in-transit, and an extra level of encryption for extra sensitive data with personalized keys by tenant.
In short, we believe that Preset’s version of Superset will be the most secure version you can have sitting on the public internet. And if you’d rather not be on the public internet, we have a solution for that, too.
Security is Everyone’s Concern
Apache Superset has a robust process in place to handle security vulnerabilities, balancing transparency and the need for confidentiality, while taking all reports seriously. Superset’s PMC plays a crucial role in ensuring the security and reliability of all Superset installations. Through the assessment, tracking, resolution, and release of vulnerabilities, Superset continues to uphold its commitment to its community of users and contributors.
Remember, we are all stakeholders in the realm of cybersecurity. If you identify a potential security vulnerability in any Apache project, don't hesitate to report it. Your contribution is key to ensuring the integrity and security of the open-source ecosystem we’re all living in.
