On the 12th of December, following the comprehensive timeline report detailing what happened during the Equifax Breach, the House Subcommittee on oversight and investigations released an additional report identifying the core strategies organizations can take to address modern cybersecurity risks.
Following the increase in security disclosures and events, the Energy and Commerce subcommittee set about identifying the common characteristics of these security events and what, if any, priorities organizations can set from a strategic perspective to control and address these risks.
It is a comprehensive report that sees input from several industry and technology sources, including the Linux foundation. Remarkably, the report discusses the inherent problem of known cybersecurity risks and the impossibility of managing known unknowns - and sets forth steps to control them.
The report bluntly states that Open Source Software components have become critical infrastructure for modern information systems, but also that most organizations leverage it whether they know it, and that most software today is assembled, not constructed.
"For the same reasons that physical manufacturing moved away from bespoke craftsmanship to assembly-line-based manufacturing, software development has moved from an artisanal, soup-to-nuts process to one more akin to bricklaying."
As custodians of the largest open source ecosystem in the Java world, we at Sonatype witnessed this transformation first hand. There were 87 billion download requests from this repository in 2017. A similar repository for JavaScript components is seeing 7 billion downloads a week, as reported in October 2018.
As the tools in the hands of developers across all programming ecosystems make it easier to leverage external code, the software engineering process itself has transformed itself into a process resembling manufacturing.
With the benefits of the above, complexity also arrives, which the subcommittee also recognizes. As the number of third party dependencies increases, it's becoming hard for organizations to fully understand or appreciate what has gone into constructing their software. This is particularly problematic when they're trying to control risk during an event, as millions learned with OpenSSL in 2014, Equifax, AADHAAR, and Canada’s Revenue Service learned in 2017 with Struts vulnerabilities, and CoPay learned a few weeks ago with event-stream JavaScript vulnerabilities. Buying software that is an opaque black box or assembling software without a full awareness of every constituent part can be a huge risk.
"The problem highlighted by Heartbleed and WannaCry was not that organizations did not know which software was vulnerable - that information was made publicly available from the outset - it was that they did not know which pieces of technology they depended on included it."
Towards this, their recommendation of building software bills of materials (SBOM) is exactly what we here at Sonatype have been recommending to our customers for years. To minimize their known unknowns, they must increase visibility of all aspects of software they produce and buy.
In our opinion, having and maintaining this SBOM allows organizations to develop and maintain automation that monitors for any new risk of these components, and allows effective life cycle management of all parts. It takes away the risk of being caught unaware during a security incident in one affected component, and allows for business-as-usual identification and remediation of any new risk.
Amazingly, the report also recognizes that OSS itself has become part of critical infrastructure in the internet, and requires its users to contribute to its maintenance.
As we have seen over the last two years, OSS dependencies themselves are becoming the new front line for hackers and attackers to influence. As mentioned above, we saw this two weeks ago with the event-stream hack and targeted attack to a bitcoin wallet that used it as a building block.
Although a sophisticated operation, the underlying tragedy of this event was that the event-stream component, despite being hugely popular (having over 2m weekly downloads), was not supporting its creator. In fact, for the two years he'd spent maintaining it, he never once made a cent off it. When the maintainer was approached by a seemingly beneficial party who offered to help, they changed control willingly.
This exchange has been normal in the open source community for two decades, underpinning the implicit helpfulness of the community. Event-stream wasn't the only such event we saw, with a similar incident occurring with conventional-changelog earlier in the year and many more before it.
The report advocates recognizing this inherent duality, and urges organizations to contribute back to open source, and help take on the responsibility of maintaining and supporting it. The economic argument for this is convincing:
"After all, if 78 percent of companies run on OSS, then any improvements in the quality of OSS bricks will create immediate, widespread, and effective increases in the overall quality of the cybersecurity capabilities of the organizations using them."
The recommendation of seeing OSS contributions as a key security strategy concludes with the following statement:
"OSS support, together with coordinated disclosure (of security vulnerabilities) and SBOM, recognize and address some of the most critical facets of organizations' modern cybersecurity challenges."
We here at Sonatype have been great believers in the great contributions of open source to our industry, and in the need to manage and maintain what we use responsibly. We are happy to see the Energy and Commerce Subcommittees take such an active stance in improving the cybersecurity hygiene of all companies around the world - and act as great recommendations to organizations across the world, including those covered under GDPR and other internationally significant regulation.
We are delighted to see the report also calls for strengthening the NVD program, and have been advocating better quality security data for years. In our opinion, a key part of why consumers omit open source information is partly because developers are hard to leverage OSS to fully understand and consume security data meaningfully. This is why we have dedicated our lives to enriching and providing data about components in a meaningful, actionable way that helps our customers not only know about risk, but also to action it immediately, without the need for a security middle man. DevSecOps automation is the concrete step every organization can take today to start implementing these practices in a scalable and meaningful manner.
Read the full report here: https://energycommerce.house.gov/news/suboversight-report-details-recommendations-for-addressing-cybersecurity-vulnerabilities/
And to get started with automation, why not start with creating a SBOM with our Sonatype Vulnerability Scanner.