Open source software security risks



Whether it’s Linux or Tensorflow, the open source community plays a huge role in the adoption of cutting edge technology. For example, Tensorflow accelerated the popularity of machine learning after it opened in 2015. According to Microsoft, open source software has multiple benefits, including:

  • The creation of software is simpler and faster, thanks to the already existing components.
  • The concentrated efforts of dozens of developers on specific software components will lead to better quality instead of dozens of engineers solving the same problems multiple times in silos.

However, open source comes at a cost. Due to the involvement of third parties / developers, open source projects are subject to vulnerabilities. And when the components of these open source projects appear as libraries and cores in megaprojects (think self-driving cars), the results can be irreversible. According to Google, Kubernetes (an open source container orchestration system) alone depends on around 1,000 packages. It is very likely that open source has more dependencies than closed source code. Free software does not have a central authority responsible for quality and maintenance. Source code can be copied and cloned. Attackers can disguise themselves as maintainers and introduce malware into projects. In such scenarios, you cannot expect contributors to check the project for vulnerabilities, making the use of open source in products more risky.

Open source, like any software, can contain security flaws, which will reveal vulnerabilities later in the project.

Best practices

Earlier this year, Google’s security team proposed the “Know, Prevent, Fix” framework and urged the industry to focus on transparency and consensus in open source projects. Here are some practices that keep open source projects intact:

Identify vulnerabilities

Capturing vulnerability metadata from all available data sources is critical. Knowing which version carries the vulnerability can help identify vulnerable systems. It also helps to check if a certain bug is fixed and updated.


Stay up to date

Even if a vulnerability is fixed and a new version is released, it is likely that users have not yet upgraded to a more secure version. This lag can give attackers enough time to infiltrate and exploit. It is therefore important to update open source components in a timely manner, especially when they contain security fixes. That said, experts also admit that upgrades are harder than they appear to be. An upgrade may be blocked due to versioning. Updating a package deep in the dependency chain is a challenge because it is more difficult to get owners to update intermediate packages.

Beware of dependencies

Most of the vulnerabilities are in dependencies. One could think of removing the dependency that contains the vulnerability. This will solve the problem for that particular person, but not for the whole community. Unless every link in the chain of dependencies is fixed, it cannot be called safe. Google Security has stressed the importance of having infrastructure and industry standards as a prerequisite for tracking vulnerabilities, understanding their consequences, and managing their mitigations. “Each link should include the patched version of the thing below to purge the vulnerability.” So updates have to be done from the bottom up, ”writes Eric Brewer and colleagues at Google Security.

Target critical components

An open source project can have many components. Few are more critical than the others. With an increase in the number of contributors, security risks also increase. Experts suggest developers identify critical software and use high-quality coding practices on those specific packages.

In addition, certain factors such as anonymity should be taken into account during code reviews. Many developers baptize themselves with pseudonyms, which makes it difficult to verify the credentials of a particular encoder.

Over the years, few free and commercial security tools have been released. Such tools largely automate the process of identifying and remedying vulnerabilities. Here are some popular tools for safely using open source software:


npm, the world’s largest software registry, is used by open source developers to share and borrow packages, and many organizations also use npm to manage private development.

See also

npm audit [–json] [–production] [–audit-level=(low|moderate|high|critical)]

npm audit fix [–force|–package-lock-only|–dry-run|–production|–only=(dev|prod)]

The “npm audit” command, as shown above, submits a description of the dependencies configured in the project to a default registry and requests a report on known vulnerabilities. If vulnerabilities are detected, the impact and appropriate corrective actions will be calculated. In case the “fix” argument is supplied, the fixes will be applied to the package tree.


Snyk is a commercial tool used to automatically detect vulnerabilities and warn whenever new vulnerabilities are discovered.

White source bolt

Whitesource is used to patch open source vulnerabilities and generate comprehensive inventory and license reports of all open source components. Whitesource can be used through Microsoft’s VisualStudio subscriptions.

Google’s scorecard

Scorecards is an automated security tool that produces a “risk score” for open source projects. Scorecard is based on Google’s “Know, Prevent, Fix” framework. To date, the Scorecards project has grown to assess the security criteria of over 50,000 open source projects. Scorecards was launched in collaboration with the Open Source Security Foundation (OpenSSF) community. The OpenSSF is a cross-sector initiative to address vulnerability disclosures, security tools and more. To make open source software safer to use, companies like Google and Microsoft came together to form OpenSSF.

Learn more about OpenSSF here.

Join our Discord server. Be part of an engaging online community. Join here.

Subscribe to our newsletter

Receive the latest updates and relevant offers by sharing your email.



Leave A Reply