When one open-source package riddled with vulns pulls in dozens of others, what's a dev to do?

Snyk survey puts cross-site scripting top of the list for security holes – but watch out for prototype pollution too

Open-source security specialist Snyk has released a new survey combining data on vulnerabilities in available packages with responses from developers and DevOps teams about how they handle the challenge this poses.

Click to enlarge (via Snyk)

The problem is easy to express. Software development today typically makes use of packages from online repositories. A developer sits down to create a web application and starts by installing libraries from npm.js (more than 1 million JavaScript packages to choose from), Maven (for Java), NuGet (for .NET) or PyPI (for Python).

Each package may and probably will pull down other packages on which it depends. The result is a big chunk of code that gets deployed with the application, but was not written by the developer and may include security vulnerabilities.

Indirect issues

The Snyk survey is based on responses from 500 developers, security pros and operations bods, together with data from the company's own vulnerability database and "correlated data from the hundreds of thousands of projects currently monitored" by Snyk, and data published by sources such as GitHub, GitLab and Bitbucket, each of which manages a large number of code repositories.

The majority of problems, the report said, come from indirect dependencies, which are least visible to developers. In the case of npm.js, around 80 per cent of the vulnerabilities are in indirect dependencies. The good news is that new vulnerabilities are down by almost 20 per cent across "the most popular ecosystems", but there is still plenty to worry about.

What kind of vulnerabilities? Top of the list is cross-site scripting, where JavaScript is injected into a site via techniques such as user input that is not properly sanitised.

The second top vulnerability last year was malicious packages, where a trusted package is contaminated with one crafted for an attack. Looking more closely, the researchers found that the top vulnerability "currently impacting scanned projects" is prototype pollution, a JavaScript attack where an object's behaviour is modified by altering its base class. When listing top vulnerabilities by project impact, prototype pollution was followed by deserialisation of untrusted data, denial of service, denial of service by Regular Expression (which oddly gets a category all to itself), and arbitrary code execution.

SQL injection, historically a big problem, seems to be in decline. That said, the researchers reported increasing numbers of SQL injection vulnerabilities in PHP packages.

Snyk also looked at issues around containers and Kubernetes, the flavour of the moment for application deployment. Docker images often contain high-severity vulnerabilities, they reported, coming from the version of Linux on which they are based, but slimmer base images help.

When deploying to Kubernetes clusters, do IT teams check the security of Helm charts or other manifests? Most rely on manual review while 31 per cent said: "I don't know."

Snyk observed: "There are numerous key configuration decisions that can be made when defining a Kubernetes cluster that have a direct impact on the security of that cluster."

We asked Snyk to put the report in context. How serious is the issue of developers inadvertently adding vulnerabilities to application via open-source dependencies?

"The problem is very severe," Snyk president and co-founder Guy Podjarny told us. "A dev using one open-source package typically unwittingly pulls in dozens of others. Most known vulnerabilities are in those packages, and with a typical app using hundreds of libraries, the odds of a severe vulnerability in some of them are high.

"To top that, OS vulnerabilities are easy pickings for attackers, as the vulnerable code is in plain sight, and a single vulnerability has many victims. This allows even the least sophisticated attackers to exploit such issues, resulting in botnets focusing on these exploits.

"Combined, the likelihood of having an OSS vulnerability exploited in your system is considerable, and far outweighs the risk of flaws in your own code being found and exploited."

What, then, is the call to action for DevOps teams? "The first step is clearly visibility – know which components you're using, contrast them against a vulnerability database like Snyk's," Podjarny said.

"The second step, however, isn't to triage across the org, but rather to start fixing issues. Teams who overspend energy triaging at the expense of fixing end up incurring greater risk. So prioritisation is important – but nothing is more important than actual fixing."

A dev using one open-source package typically unwittingly pulls in dozens of others. Most known vulnerabilities are in those packages, and with a typical app using hundreds of libraries, the odds of a severe vulnerability in some of them are high

It seems a big ask for developers sitting down to work on a project. If sucking in all these packages and dependencies is wrong, what should they be doing? "It's important for developers to understand their bill of materials," said Simon Maple, Snyk developer relations veep.

Having established what vulnerabilities exist, "there are a number of ways to mitigate the risks. Does an upgrade path exist? Or we need to code defensively so that if a vulnerability exists, which doesn't have a fix, we do enough input validation or whatever is needed to avoid that code path from being attacked. And when we choose an open-source package, how many maintainers are there? If a vulnerability is found, how quick are they to provide patches?"

Is it humanly possible to know all your dependencies in such detail? Automation, it seems, is unavoidable. "There are many tools which will give you information about the health of those libraries," said Maple – and note that this is exactly Snyk's business, so its recommendations are not without self-interest.

Should developers minimise the number of packages they use? "We want to practice caution but we want to keep the agile part of development," said Maple. "We need to use open source but use it responsibly with a measure of how it potentially affects us."

What about applications that live behind firewalls that require multi-factor authentication to log in – can developers argue that these are less likely to be attacked? "Hackers love those developers," said Maple, "because as soon as they do get past that firewall, it's party time." ®