Cybersecurity
Did we learn from last year’s mistakes?
How to increase your Javascript security
Goodbye and Good Riddance
Last year was a wild ride, no question about that. Although most people who look back will probably think about pandemics and leadership crisis. However, a lot happened on the IT stage as well.
Within the JavaScript ecosphere a lot happened last year and the sheer speed of development is staggering. We’ve seen news regarding a couple of areas that I believe we all need to become a bit better at understanding. Better at understanding how it affects us from the perspective of the developer as well as from the perspective of the enterprise. And once we understand, we need to work diligently to mitigate and, if possible, avoid risks and vulnerabilities were we can.
Wait what, how many did you say?
Some numbers, that frankly, are quite staggering:
The 10+ million strong JavaScript developer community introduced over 500,000 new component releases in 2020, with 1.5 million packages now available to developers in npm alone. With on average 90,000 npm packages downloaded annually per developer.
This is of course not without introducing code that, well, doesn’t do what it is intended (mistakes — best case) and sometimes does what is intended but not what you expect (malicious code — worst case).
Once mistakes or wilful malice is committed and pushed it on can take up to four years for it to be detected according to GitHub.
“Security vulnerabilities often go undetected for more than four years before being disclosed.” — GitHub: The 2020 State of the Octoverse
Once they are identified, the package maintainer and security community typically create and release a fix in just over four weeks. This highlights
the opportunities to improve vulnerability detection in the security community.
Now you may think that “we don’t use those packages for our code” But are you as confident that the dependency chain does not include some of those vulnerable packages somewhere down the road?
“”You would be hard-pressed to find a scenario where your data does not pass through at least one open source component,” GitHub says. “Many of the services and technology we all rely on, from banking to healthcare, also rely on open source software. The artifacts of open source code serve as critical infrastructure for much of the global economy, making the security of open source software mission-critical to the world.”
Given the average pressure that a developer will face when time-to-market is critical, it comes to no surprise that due-diligence and analysis of any newly introduced 3rd party packages might not end up on top of the list.
What to watch out for
Some of the areas where I believe we all can become (at least a little bit) better:
- Typesquatting & Combosquatting
Typesquatting is (and has been) a threat, and let’s be honest, a nuisance, whether it regards URLs or node package names. In the context of node packages, combined with the default setting of executing code on installation in your developer’s environment is downright cary. - Awareness of intentional malicious packages (not common, but neither unheard of)
- Security issues in popular libraries, make sure you are prepared to discover and apply patches without delay
If you find these topics interesting, please keep reading this post what we at Bytesafe learnt from 2020 and what to avoid going into 2021, written by my colleague Andreas at Bytesafe. In his post, he’ll touch on some practical examples of above mentioned areas, what to stay clear of and of course why you should use Bytesafe to help you! 😃
Good luck and build something awesome (and resilient to the most common pitfalls)!
Sources:
