When a critical vulnerability was discovered in Log4j in December, it triggered widespread panic as security teams raced to ensure their systems remained secure. The implications were staggering, with CISA estimating the vulnerability exists within hundreds of millions of devices.
It begs the question: are new rules needed to help make open-source code more secure?
While regulating an environment created for unrestricted use may seem contradictory, the Log4j vulnerability highlights how the current high-risk cyber threat landscape combined with the unprecedented pace of software innovation and development necessitates further action.
A few ways to approach securing open-source code could include creating a software security alliance, investing in a new type of secure software insurance, or even a set of minimum standards put in place by the federal government. Let’s explore how companies that largely depend on open-source code for innovation could see these ideas put into practice to better protect the organization and its customers.
Create a software security alliance
We can look at the Vendor Security Alliance (VSA) as an example to better understand how we could improve open-source security compliance. This coalition offers subscribing organizations the ability to assess vendors' security in a standardized manner. The VSA handles the upfront work by sending out questionnaires to vendors. Subscribers get a single contact to interact with versus attempting to vet multiple vendors themselves.
Similar to the VSA, we can envision a Software Security Alliance (SSA) that would handle the scanning and scoring of the security of open-source projects to benefit its members. Such scanning can go beyond just a database of known vulnerabilities to include static and dynamic scans, and eventually manual code reviews where appropriate. Open-source code is freely available, so the SSA could easily find and ingest open-source projects to complete this scanning.
Subscribing organizations would then pay fees to the SSA to receive assessment data on open-source projects. In this model, organizations would check the software libraries it uses against the list of projects and versions that the SSA has scanned and validated. The SSA would spread the costs of scanning open-source across many subscribers. As the SSA membership grows, so would its influence in relaying security findings and working with open-source projects to see them addressed.
Invest in a new category of cyber insurance
Most organizations already purchase general cyber risk insurance to protect against financial loss suffered from a security incident. Companies can also buy specific open-source compliance insurance to protect against costs incurred if they are fined for not complying with the terms of an open-source software license.
The industry needs a new type of secure software insurance that protects organizations against risks associated with vulnerabilities in the open-source software that they use. This model could work in a few different ways. First, the insured would provide the insurance company with a list of software projects and versions they use. The insurer would then issue a policy against these specifications. Alternatively, the insurer could provide a list of open-source projects and note versions that are insured. Any projects or versions companies use outside of that list that result in security issues would not receive coverage.
There are many variables in terms of the risk level of software used, premiums paid by the insured and how insurers scan and score open-source projects before writing policies. This leaves a lot of room for innovation in this model.
How the private and public sectors can come together
While companies must implement a security-first environment for their use of open-source code, internal rules and policies can vary from company to company. A baseline set of standards could help ensure organizations use open-source code that meets minimum security requirements. Having the ability to publicly share that a piece of code has met a minimum standard would also prevent the need for every company looking to use that code to repeat the same tests and evaluations – saving incalculable employee hours.
The federal government could work with enterprises and the open-source community to establish guidelines for testing and certifying the security of software components. Developing a partnership to create policies and a process for testing applications and software components will allow for greater protection against intentional attacks and inadvertent weaknesses in code alike. The government could create an impartial third-party certifying body that issues guidance on scanning methods and tools for evaluating the security of open-source components as well as certifying specific versions of libraries as “secure” similar to the existing DISA Approved Products List (APL) or ISO Common Criteria processes for evaluating the security of software products.
As one of the largest procurers of software and services, the U.S. federal government could quickly drive the adoption of an open-source accreditation process by requiring the use of certified open-source software and the software products that it procures. It would create consistency and potentially speed up innovation while keeping security at the forefront of the open-source community.
While there are a few different ways we could achieve a more standardized approach to leveraging open-source code, the Log4j vulnerability has underscored why companies need to implement the proper security procedures to protect the organization and its end users.
As organizations continue to leverage open-source code to innovate, the industry stands to benefit from more cohesive collaboration regarding the certification of open-source code to minimize security risk and reduce redundant efforts.
Matt Sanders, director of security, LogRhythm
