Re: Apache Software Foundation Security Report: 2020
Video highlights of the ASF Security Report: 2020 now available at https://youtu.be/Z7yudar_da0 Do enjoy, Sally - - - Vice President Marketing & Publicity Vice President Sponsor Relations The Apache Software Foundation On Mon, Jan 25, 2021, at 08:59, Sally Khudairi wrote: > [this report is available online at https://s.apache.org/SecurityReport2020 ] > > Synopsis: This report explores the state of security across all Apache > Software Foundation projects for the calendar year 2020. We review key > metrics, specific vulnerabilities, and the most common ways users of > ASF projects were affected by security issues. > > Released: January 2021 > > Author: Mark Cox, Vice President Security, Apache Software Foundation > > Background > The security committee of the Apache Software Foundation (ASF) oversees > and coordinates the handling of vulnerabilities across all of the 340+ > Apache projects. Established in 2002 and composed of all volunteers, > we have a consistent process https://s.apache.org/cveprocess for how > issues are handled, and this process includes how our projects must > disclose security issues. > > Anyone finding security issues in any Apache project can report them to > secur...@apache.org where they are recorded and passed on to the > relevant dedicated security teams > https://apache.org/security/projects.html or private project management > committees (PMC) to handle. The security committee monitors all the > issues reported across all the addresses and keeps track of the issues > throughout the vulnerability lifecycle. > > The security committee is responsible for ensuring that issues are > dealt with properly and will actively remind projects of their > outstanding issues and responsibilities. As a board committee, we have > the ability to take action including blocking their future releases or, > worst case, archiving a project if such projects are unresponsive to > handling their security issues. This, along with the Apache Software > License, are key parts of the ASF’s general oversight function around > official releases, allowing the ASF to protect individual developers > and giving users confidence to deploy and rely on ASF software. > > The oversight into all security reports, along with tools we have > developed, gives us the ability to easily create metrics on the issues. > Our last report covered the metrics for 2019 > https://s.apache.org/security2019 . > > Statistics for 2020 > In 2020 our security email addresses received in total 18,000 emails. > After spam filtering and thread grouping this was 946 (2019: 620) > non-spam threads. Unfortunately many security reports do look like > spam and so the security team are careful to review all messages to > ensure real reports are not missed for too long. > > [see image online at https://s.apache.org/SecurityReport2020 ] > > Diagram 1: Breakdown of ASF security email threads for calendar year 2020 > > Diagram 1 gives the breakdown of those 946 threads. 257 threads (27%) > were people confused by the Apache License. As many projects use the > Apache License, not just those under the ASF umbrella, people can get > confused when they see the Apache License and they don't understand > what it is. This is most common for example on mobile phones where the > licenses are displayed in the settings menu, usually due to the > inclusion of software by Google released under the Apache License. We > no longer reply to these emails. This is nearly double the number we > saw in 2019. > > The next 220 of the 946 (23%) are email threads with people asking > non-security (usually support-type) questions. > > The next 93 of those reports were researchers reporting issues in an > Apache web site. These are almost always false negatives; where a > researcher reports us having directory listings enabled, source code > visible, or the lack of various domain headers. These reports are > generally the unfiltered output of some publicly available scanning > tool, and often where the reporter asks us for some sort of monetary > reward (bounty) for their report. > > That left 376 (2019: 320) reports of new vulnerabilities in 2020, which > spanned across 101 of the top level projects. These 376 reports are a > mix of both external reporters and internal; for example where a > project has found an issue themselves and followed the ASF process to > assign it a CVE name and address it we’d still count it here. We don’t > keep metrics that would give the breakdown of internal vs external > reports. > > The next step is that the appropriate project triages the report to see > if it's really an issue or not. Invalid reports and reports of things > that are not actually vulnerabilities get rejected back to the > reporter. Of the remaining issues that are accepted they are assigned > appropriate CVE names and eventually fixes are released. > > As of January 1st 2021, 35 of
Apache Software Foundation Security Report: 2020
[this report is available online at https://s.apache.org/SecurityReport2020 ] Synopsis: This report explores the state of security across all Apache Software Foundation projects for the calendar year 2020. We review key metrics, specific vulnerabilities, and the most common ways users of ASF projects were affected by security issues. Released: January 2021 Author: Mark Cox, Vice President Security, Apache Software Foundation Background The security committee of the Apache Software Foundation (ASF) oversees and coordinates the handling of vulnerabilities across all of the 340+ Apache projects. Established in 2002 and composed of all volunteers, we have a consistent process https://s.apache.org/cveprocess for how issues are handled, and this process includes how our projects must disclose security issues. Anyone finding security issues in any Apache project can report them to secur...@apache.org where they are recorded and passed on to the relevant dedicated security teams https://apache.org/security/projects.html or private project management committees (PMC) to handle. The security committee monitors all the issues reported across all the addresses and keeps track of the issues throughout the vulnerability lifecycle. The security committee is responsible for ensuring that issues are dealt with properly and will actively remind projects of their outstanding issues and responsibilities. As a board committee, we have the ability to take action including blocking their future releases or, worst case, archiving a project if such projects are unresponsive to handling their security issues. This, along with the Apache Software License, are key parts of the ASF’s general oversight function around official releases, allowing the ASF to protect individual developers and giving users confidence to deploy and rely on ASF software. The oversight into all security reports, along with tools we have developed, gives us the ability to easily create metrics on the issues. Our last report covered the metrics for 2019 https://s.apache.org/security2019 . Statistics for 2020 In 2020 our security email addresses received in total 18,000 emails. After spam filtering and thread grouping this was 946 (2019: 620) non-spam threads. Unfortunately many security reports do look like spam and so the security team are careful to review all messages to ensure real reports are not missed for too long. [see image online at https://s.apache.org/SecurityReport2020 ] Diagram 1: Breakdown of ASF security email threads for calendar year 2020 Diagram 1 gives the breakdown of those 946 threads. 257 threads (27%) were people confused by the Apache License. As many projects use the Apache License, not just those under the ASF umbrella, people can get confused when they see the Apache License and they don't understand what it is. This is most common for example on mobile phones where the licenses are displayed in the settings menu, usually due to the inclusion of software by Google released under the Apache License. We no longer reply to these emails. This is nearly double the number we saw in 2019. The next 220 of the 946 (23%) are email threads with people asking non-security (usually support-type) questions. The next 93 of those reports were researchers reporting issues in an Apache web site. These are almost always false negatives; where a researcher reports us having directory listings enabled, source code visible, or the lack of various domain headers. These reports are generally the unfiltered output of some publicly available scanning tool, and often where the reporter asks us for some sort of monetary reward (bounty) for their report. That left 376 (2019: 320) reports of new vulnerabilities in 2020, which spanned across 101 of the top level projects. These 376 reports are a mix of both external reporters and internal; for example where a project has found an issue themselves and followed the ASF process to assign it a CVE name and address it we’d still count it here. We don’t keep metrics that would give the breakdown of internal vs external reports. The next step is that the appropriate project triages the report to see if it's really an issue or not. Invalid reports and reports of things that are not actually vulnerabilities get rejected back to the reporter. Of the remaining issues that are accepted they are assigned appropriate CVE names and eventually fixes are released. As of January 1st 2021, 35 of those 376 reports were still under triage (i.e. the project had not yet determined if the report is accepted or rejected). The remaining closed 341 (2019: 301) reports led to us assigning 151 (2019: 122) CVE names. Some vulnerability reports may include multiple issues, some reports are across multiple projects, and some reports are duplicates where the same issue is found by different reporters, so there isn't an exact one-to-one mapping of accepted
