OpenSSF adds prototype open source package analysis tool

The Open Source Security Foundation (OpenSSF) has made available a package analysis tool prototype which has already identified more than 200 malicious packages uploaded to PyPI and npm software components.

Caleb Brown, an OpenSSF maintainer on the project, said the goal is to understand the behavior and capabilities of packages available on open source repositories. It also tracks the behavior of packages over time to help identify when previously safe software has started acting suspiciously.

Most of the detected malicious packages use dependency confusion and typosquatting techniques, Brown said. They usually contain a simple script that runs during installation and provides some host details to an external command and control system. Most of these packages don’t exfiltrate meaningful data except the machine name or a username, but they don’t attempt to hide their behavior. The problem is that any one of those packages could have done a lot more damage, Brown noted.

Future goals of the project include detecting differences in package behavior over time; automate the processing of package analysis results; store the packages themselves as they are processed for long-term analysis and improve pipeline reliability. As such, the OpenSSF is looking for application developers and cybersecurity researchers to contribute to the project. Many application security tool vendors are expected to incorporate the package scanning tool into their offerings rather than requiring each vendor to create its own version of the same tool, Brown said.

The OpenSSF has launched a series of initiatives to improve the general state of open source security. More recently, he added a Alpha-Omega Project to automate security testing processes for open source software with an initial investment of $5 million provided by Microsoft and Google. The main challenge is that many organizations depend on open source software projects created and maintained by a handful of volunteer maintainers and contributors. The people who created these projects don’t always have a lot of expertise in cybersecurity. In fact, many would argue that the responsibility for securing open source software rests with the organizations that use what amounts to free software. It is not the responsibility of contributors and maintainers, for example, to drop everything and immediately create a patch to fix a zero-day vulnerability.

It is unclear how easily open source software could be compromised by cybercriminals who insert malware into downstream applications that rely on this code. However, following a series of high-profile breaches, it is safe to assume that more cybercriminals than ever are trying to compromise open source software projects. While some organizations may choose to limit their reliance on open source code that has not been properly vetted, there is no way to completely avoid using open source code. The challenge is to find a more effective way to ensure the integrity of this code for everyone involved.

Comments are closed.