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 organisations can take to address modern cybersecurity risks.
Following the increase both in security disclosures and events the Energy and Commerce subcommittee set about identifying what the common characteristics of these security events are and what, if any, priorities organisations can set from a strategic perspective to control and address these risks going forward.
- “The widespread adoption of coordinated disclosure programs.
- The implementation of software bills of materials across connected technologies.
- The support and stability of the open-source software ecosystem.
- The health of the Common Vulnerabilities and Exposures (CVE) program.
- The implementation of supported lifetimes strategies for technologies.
- The strengthening of the public-private partnership model.”
OSS is now critical infrastructure
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 not only become critical infrastructure for modern information systems, but also that a vast majority of organisations leverage it whether or not 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 have 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 to a process resembling manufacturing.
With the benefits of the above also arrives complexity, which the report by the subcommittee also recognises. As the amount of third party dependencies increases, it’s becoming hard for organisations to fully understand or appreciate exactly 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 couple of 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. For organisations to be able to minimise 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 organisations to develop and maintain automation that monitors for any new risk of these components, and allows for effective lifecycle 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.
OSS Needs the it’s user’s support - and it’s implicit trust network is changing
Amazingly, the report also recognises OSS itself has become a part of critical infrastructure in the internet, and requires its users to also 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 it’s creator - in fact for the two years he’d spent maintaining it he never once made a cent off it. When the maintainer was approach by a seemingly beneficial party who offered to help, they changed control willingly.
This exchange has been normal in the open source community for the last two decades, underpinning the implicit helpfulness of the community. Event-stream wasn’t the only such event we saw, with a very similar incident occurring with conventional-changelog earlier in the year and many more before it.
The report advocates recognising this inherent duality, and urges organisations to contribute back to open source, and help take on responsibility of maintaining and supporting it. The economic argument for this is pretty 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”
The new normal - trust, verify, manage with Devsecops
We here at Sonatype have been great believers Open Source's great contributions to our industry, and at the same time in the need to manage and maintain what we use responsibly. We are happy to see the Energy & Commerce Subcommittees take such an active stance in improving the cybersecurity hygiene of all companies around the world - and acts as great recommendations to organisations across the world, including those covered under GDPR and other internationally significant regulation.
We are extremely pleased to see the report also call out for strengthening the NVD programme, and have been advocating better quality security data for years. In our opinion a key part of why information that is available is omitted by the consumers of open source is in part because it is hard for developers leveraging OSS to fully understand and consume security data in a meaningful way. 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 organisation 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 Nexus Vulnerability Scanner
