Do we need to regulate the security of open-source code?

Today columnist Matt Sanders of LogRhythm says government and industry need to work together to settle the rules of the road for open-source code. (Photo by Anna Moneymaker/Getty Images)

When a critical vulnerability was discovered in Log4j in December, it sparked widespread panic as security teams raced to ensure their systems remained secure. The implications were staggering, with CISA estimating that the vulnerability exists in hundreds of millions of devices.

This raises the question: are new rules needed to make open source code safer?

While regulating an environment created for unlimited use may seem contradictory, the Log4j vulnerability underscores how today’s high-risk cyber threat landscape, combined with the unprecedented pace of innovation and software development, requires additional measures.

A few ways to approach securing open source code might include creating a software security alliance, investing in a new kind of secure software assurance, or even a set of minimum standards put in place by the federal government. . Let’s explore how companies that rely heavily 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 take the example of the Vendor Security Alliance (VSA) to better understand how we could improve open source security compliance. This coalition offers subscriber organizations the ability to assess vendor security in a standardized way. The VSA manages the initial work by sending questionnaires to the suppliers. Subscribers get a single contact to interact with instead of trying to verify multiple vendors themselves.

Similar to the VSA, we can envision a Software Security Alliance (SSA) that would take care of security analysis and rating of open source projects for the benefit of its members. Such analysis can go beyond a simple database of known vulnerabilities to include static and dynamic scans, and possibly manual code reviews as needed. The open source code is freely available, so the SSA could easily find and ingest open source projects to perform this analysis.

Subscribing organizations would then pay a fee to the SSA to receive the rating data on open source projects. In this model, organizations would check the software libraries they use against the list of projects and versions that the SSA has scanned and validated. The SSA would spread open source scanning costs over many subscribers. As the membership of the SSA grows, so too will its influence in reporting security findings and collaborating with open source projects to see them addressed.

Invest in a new class of cyber insurance

Most organizations already carry general cyber risk insurance to protect against financial loss incurred as a result of a security incident. Companies can also purchase specific open source compliance insurance to protect against costs incurred if they are fined for violating the terms of an open source software license.

The industry needs a new kind of secure software insurance that protects organizations against the risks associated with vulnerabilities in the open source software they use. This model could work in different ways. First, the insured would provide the insurance company with a list of the software projects and versions they use. The insurer would then issue a policy against those specifications. Alternatively, the insurer could provide a list of open-source projects and note which versions are insured. Any projects or versions that companies use outside of this list that cause security issues will not be covered.

There are many variables in terms of the level of risk of the software used, the premiums paid by the insured, and the way insurers analyze and rate 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 should implement a security-focused environment for their use of open source code, internal rules and policies may vary from company to company. A core set of standards could help ensure that organizations use open source code that meets minimum security requirements. Having the ability to share publicly that a piece of code has met a minimum standard would also prevent any company looking to use that code from repeating the same tests and assessments, saving employees countless hours.

The federal government could work with businesses 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 provide better protection against intentional attacks and unintended code weaknesses. The government could create an impartial third-party certification body that publishes guidance on scanning methods and tools for assessing the security of open source components, as well as certifying specific versions of libraries as “secure” similar to the existing list DISA Approved Products (APL) or ISO Common Criteria processes for evaluating the security of software products.

As one of the largest purchasers of software and services, the U.S. federal government could quickly drive adoption of an open source certification process by requiring the use of certified open source software and software products that ‘He buys. This would create consistency and potentially accelerate innovation while keeping security at the forefront of the open source community.

While there are several ways to 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 consistent collaboration regarding certification of open source code to minimize security risks and reduce redundant efforts.

Matt Sanders, Chief Security Officer, LogRhythm


Comments are closed.