Open source security gets a boost with new scorecard and best practices

There is no shortage of challenges when it comes to securing open source software and no shortage of ideas for mitigating risk.

It is the stated mission of the OpenSSF (Open Source Security Foundation) to help improve the state of open source security, and that is exactly what it does. The OpenSSF is part of the Linux Foundation and has multiple ongoing efforts in various aspects of the software development lifecycle.

On September 7, 2022, the organization announced the latest version of its Scorecards effort, an initiative designed to help open source projects and their users identify security status within a project. The updated scorecards come a week after the OpenSSF is released new guidance and best practices on how to secure npma widely used and often abused open source package management system for JavaScript.

Easier access for open source security scorecards

The OpenSSF has its roots in a predecessor of the Linux Foundation known as the Core Infrastructure Initiative (CII), where the concept of best practices badges for open source projects was introduced in 2015. The badge projects became part of the OpenSSFs Scorecards effort in 2020. With security scorecards, anyone can scan an open source code repository and automatically identify the general state of security. Badges enable an open source project to easily publicly display scorecard results that reflect the state of best practice.

With the new version of scorecard badges, the OpenSSF aims to make it easier to share scorecard information and make it more widely accessible with a programmatic approach. There is now a REST API that allows anyone to get a data stream of access to the scorecard information that can then be used for analysis and trend analysis.

“Until now, anyone could download and run the scorecard tool, but now they don’t have to use it to get all the information,” David Wheeler, director of open source supply chain security at the Linux Foundation, told VentureBeat.

Best practices for npm may be obvious, but still important

The OpenSSF looks beyond scorecards to provide very specific guidelines to help npm users and developers be more secure.

Finding malware in npm libraries is not uncommon. One of the high-profile security incidents involving npm was one in 2021 that the US Cybersecurity and Infrastructure Security Agency warned about in a advisory.

Wheeler noted that the best practice guide doesn’t necessarily introduce new concepts for open source security; rather, it reinforces ideas and approaches that are known to help mitigate risk – if only users and developers implemented them.

“For the most part, the stuff in the guide was familiar to a lot of people who have been involved with npm for a long time,” Wheeler says. “But nobody knows everything, and some people knew something, but that doesn’t mean the knowledge is universal.”

One of the best practices identified in the report is to avoid vendor dependencies. Wheeler explained that vendor dependency is a risk that occurs when a software developer creates a local copy of an npm library. The challenge is that the local copy is not updated by default when the original software vendor or developer makes a change, which could very well be to patch a software bug or vulnerability.

Wheeler emphasized that the risk of vendor dependency is not unique to npm, but rather a broader issue when using open source software. He explained that historically it has not been easy for developers to access the original, upstream software code, and that is why it became common practice to create a local copy. With modern code repositories, such as GitHub, Wheeler said this is no longer the case and developers no longer have to create local copies that are completely decoupled from the main codebase.

Another npm best practice advocated by the OpenSSF guide is to embrace the concept of least privilege. The idea behind least privilege is to provide only the minimum required amount of access to an application to minimize the potential attack surface. This also means that unnecessary access credentials and permissions are not included in code or an npm component.

While the npm best practices guide is the first such guide from OpenSSF, Wheeler expects more guides to other critical open source projects to be released in the future.

“Npm is widely used and once you get on the web you often use the npm ecosystem to some degree, even if the code in the backend is in Python, Ruby or some other language,” Wheeler said. “I think it was important that we prioritized npm, but this is not the last guide and we are very interested in guidance for other situations.”