When one open-source package riddled with vulns pulls in dozens of others, what's a dev to do?
- Reference: 1593163506
- News link: https://www.theregister.co.uk/2020/06/26/open_source_security_snyk_survey/
- Source link:
[1]
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 [2]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." ®
Sponsored: [3]Kubernetes: Your Hybrid Cloud Strategy
[1] https://regmedia.co.uk/2020/06/25/topvulns.jpg
[2] https://snyk.io/open-source-security-report/
[3] https://go.theregister.com/tl/1956/-8472/kubernetes-your-hybrid-cloud-strategy?td=wptl1956
"Validating inputs isn't defensive coding. It should be standard practice. If you, as a software developer, are not rigorously validating 100% of your user inputs, your computer access rights should be revoked."
My guess, given the topic, is that this is talking about validating other inputs. You sanitize your user input, mess with it, then pass it into some third-party code. My guess is that the author then wants another set of revalidation and sanitization, in case the third-party code is compromised.
Yeah, I understand that.
It's a bit of a circular argument though. Any third party library should be validating any inputs it is receiving.
And yes, I realise the lack of validation there is the issue being discussed. It doesn't invalidate my initial statement though. If you're providing code for others to use you should be extra vigilant when it comes to input validation, and you should never rely on external systems to provide validation for you.
"It's a bit of a circular argument though. Any third party library should be validating any inputs it is receiving."
Yes, but it's where you put your trust. You don't trust the user as far as you can throw them but you do trust most modules you suck down off some repository. Perhaps you should be treating them as cack-handed or malicious as well.
The problem is easy to express
It's the lack of compartmentalization in conventional web software frameworks. These should be analogous to Android and IOS where each software package runs in its own sandbox with access only to the particular set of features that it needs.
You are never going to be able to police and properly maintain all these software packages, so there will always be security (and other) bugs. And validating inputs only gets you so far - whilst a bit of simple syntax gets you past the stupid, simple problems like SQL injection, once you start thinking about context it can be enormously difficult. So a solution is to assume that these bugs are going to be present and design the framework in which they sit accordingly. Hence some security compartmentalization.
Re: The problem is easy to express
It also often feels like most developers are like a passing person that, using a pile of generic bricks and some ready made generic mortar, believes that this means that they are both an experienced builder and an experienced architect and able to use these to construct a tower block, a bridge or a watertight dam.
if a developer is pulling in unchecked and untested third-party packages, and including them in a 'product' that is shipped to their customers, then that developer should face the full force of any legal penalties incurred by their customers due to the developer's incompetence.
If an aircraft manufacturer bought components from a supplier, and just installed them without consistently checking they they met the safety specs, would they get away with saying "not my fault, blame my supplier"?
It isn't 'agile', it's 'lazy'.
First to market is king in (most) software development, first to go bang is rarely considered by the folks throwing money at it.
"... and including them in a 'product' that is shipped to their customers ..."
One glaring security hole, mentioned on The Register in occasional stories, is pulling in these packages on execution, rather than using a fixed, immutable version of the code. (Am I remembering right: BA had this problem?) Then if the package gets turned off or maliciously updated, you are screwed. Sometimes borkage can occur innocently, but I would worry more about the opportunity for malice.
Minimize dependencies
Minimizing dependencies is the rational way to minimize the vulnerabilities that are pulled in. The vast majority of code I work with pulls in a vast amount of unrelated and unused code, the proportion of stuff actually used tends to be tiny - and worse still quite a few of the imports are redundant - they are replicating stuff that's already available in the stdlibs or other imports.
YMMV, the stuff I work with on a daily basis has been worked over by a team with a high turnover of staff where the focus is very much on adding new stuff rather than fixing technical debt for over a decade, so I recognize that my viewpoint might not fit everyone's situation. :)
It's interesting that the report identified the imports brought in by containers as a problem - it's an issue that has been glossed over by too many people for too long. Glad they brought that up because I am seeing containers broadening and deepening the pool of dependencies in practice because Devs now get to pick and choose what bits of the OS they want - and it's rare that two of them agree. :)
Re: Minimize dependencies
> they are replicating stuff that's already available in the stdlibs or other imports.
Ah, you're being subjected to jQuery
Speaking of bad code...
... what the hell is that graph? Stacked columns but stacked by years? Sorting by total over multiple years? Masking the trends over time. Should have been column per year stacked by category, top to bottom, best to worst.
Then you'd notice the disturbing trend in malicious packages.
Other Peoples Code
On other peoples computers; what could possibly go wrong.
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.
Validating inputs isn't defensive coding. It should be standard practice. If you, as a software developer, are not rigorously validating 100% of your user inputs, your computer access rights should be revoked.