Security Risks Of Open Source Software

Be it Linux or Tensorflow, the open source community plays a huge role in taking a cutting edge technology mainstream. For instance, Tensorflow accelerated the popularity of machine learning after it was open sourced in 2015.  According to Microsoft, the open source software comes with multiple benefits, including:

• Creating software is easier and faster, thanks to already existing components.
• Focused effort by scores of developers on specific software components will lead to higher quality instead of dozens of engineers solving the same problems many times in silos.

However, open source comes at a cost. Due to the involvement of third parties/developers, open source projects are prone to vulnerabilities. And when the components of these open source projects show up as libraries and kernels in mega projects (think: self-driving cars), the outcomes can be irreversible. According to Google, Kubernetes (an open source container orchestration system) alone depends on about 1,000 packages. It is highly likely that open source incorporates more dependencies than closed source. Open-source software has no central authority responsible for quality and maintenance. Source code can be copied and cloned. Attackers can disguise themselves as maintainers and sneak in malware into projects. In such scenarios, you can’t expect the contributors to vet the project for vulnerabilities, making the use of open source in products riskier.

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

Best practices

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

---

---

Identifying vulnerabilities

Capturing vulnerability metadata from all available data sources is crucial. Knowing the version that carries the vulnerability can help identify the vulnerable systems. This also helps in checking if a certain bug is fixed and updated.

Stay updated

Even if a vulnerability is fixed and a new release is published, the chances are the users are yet to upgrade to a safer version. This lag can give the attackers enough time to infiltrate and exploit. So, it’s important to update open source components in a timely manner, especially when they contain security fixes. That said, experts also admit that upgrades are more challenging than they seem to be. An upgrade could be blocked due to versioning. Updating a package deep in the chain of dependencies is challenging as it’s harder to make the owners update intervening packages. 

Beware of dependencies

Most vulnerabilities are in dependencies. One might think of removing the dependency that contains the vulnerability. This will fix the problem for that particular person but not for the whole community. Unless every link in the chain of dependencies is fixed, one cannot call it safe.  Google Security underlined the importance of having infrastructure and industry standards as a prerequisite to track vulnerabilities, understand their consequences, and manage their mitigations. “Each link must include the fixed version of the thing below it to purge the vulnerability. Thus, the updates need to be done from the bottom up,” writes Eric Brewer and his 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, the security risks also increase. Experts suggest the developers identify mission critical software and employ high quality coding practices on those specific packages.

Further, there are factors such as anonymity that needs to be addressed during code reviews. Many developers christen themselves with pseudonyms, making it hard to check the credentials of a particular coder. 

Over the years, few free and commercial security tools have been released. Such tools automate the procedure of identifying and fixing the vulnerabilities to a great extent.  Here are a few popular tools to securely using open source software:

npm-audit

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

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 asks for a report of known vulnerabilities. If any vulnerabilities are found, then the impact and appropriate remediation will be calculated. In case, the “fix” argument is provided, then remediations will be applied to the package tree.

snyk

Snyk is a commercial tool used for automatically detecting vulnerabilities and notifies whenever new vulnerabilities are discovered.

Whitesource Bolt

Whitesource is used for fixing open source vulnerabilities and generating comprehensive inventory and license reports of all open source components. Whitesource can be availed 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 designed on Google’s “Know,Prevent, Fix” framework. To date, the Scorecards project has scaled up to evaluate security criteria for over 50,000 open source projects. Scorecards was launched in collaboration with the Open Source Security Foundation (OpenSSF) community. The OpenSSF is a cross-industry initiative to address vulnerability disclosures, security tooling and more.To make open source software safer to use, companies like Google and Microsoft have come together to form the OpenSSF.  

Know more about OpenSSF here.