SoylentNews is people
SoylentNews
There's never enough time or staff to scan code repositories:
Software dependencies, or a piece of software that an application requires to function, are notoriously difficult to manage and constitute a major software supply chain risk. If you're not aware of what's in your software supply chain, an upstream vulnerability in one of your dependencies can be fatal.
A simple React-based Web application can have upward of 1,700 transitive NodeJS "npm" dependencies, and after a few months "npm audit" will reveal that a relatively large number of those dependencies have security vulnerabilities. The case is similar for Python, Rust, and every other programming language with a package manager.
I like to think of dependencies as decaying fruit in the unrefrigerated section of the code grocer, especially npm packages, which are often written by unpaid developers who have little motivation to put in more than the bare minimum of effort. They're often written for personal use and they're open sourced by chance, not by choice. They're not written to last.
[...] Not all hope is lost. For known (reported and accepted) vulnerabilities, tools exist, such as pip-audit, which scans a developer's Python working environment for vulnerabilities. Npm-audit does the same for nodeJS packages. Similar tools exist for every major programming language and, in fact, Google recently released OSV-Scanner, which attempts to be a Swiss Army knife for software dependency vulnerabilities. Whether developers are encouraged (or forced) to run these audits regularly is beyond the scope of this analysis, as is whether they actually take action to remediate these known vulnerabilities.
However, luckily for all of us, automated CI/CD tools like Dependabot exist to make these fixes as painless as possible. These tools will continually scan your code repositories for out-of-date packages and automatically submit a pull request (PR) to fix them. Searching for "dependabot[bot]" or "renovate[bot]" on GitHub and filtering to active PRs yields millions of results! However, 3 million dependency fixes versus hundreds of millions of active PRs at any given time is an impossible quantification to attempt to make outside of an in-depth analysis.
[...] Did you install your packages from the command line? If so, did you type them in properly? Now that you've installed your dependencies "correctly," did you verify that the code for each dependency does exactly what you think it does? Did you verify that each dependency was installed from the expected package repository? Did you ....
Probably not, and that's OK! It's inhumane to expect developers to do this for every single dependency. The best bet for software developers, software companies, and even individual tinkerers is to have some form of runtime protection/detection. Luckily for us all, there are detection and response tools that have relatively recently been created which are now part of a healthy and competitive ecosystem! Many of them, like Falco, Sysdig Open Source, and Osquery, even have free and open source components. Most even come with a default set of rules/protections.
(Score: 3, Insightful) by theluggage on Friday March 10 2023, @04:44PM
I think the problem is that developers don't need languages they need platforms with all the "wheels" you need to develop real-world applications. Modern languages like Node.js*, python (and possibly Rust, but I can't speak from experience on that) have been built on a "rock soup" basis and depend on third-party dependencies to be useful (e.g. Node.js is no use as a website backend without adding things like Express and jsdom...) Even things like 'leftpad' are somewhat forgivable when the core language only has very limited string formatting functions.
C.f. something like C which - on non-unix systems - usually came bundled with a substantial subset of the UNIX standard libraries (which, post-ANSI/K&R edition 2 effectively became part of the language) which was pretty much all you needed for writing text-mode software. Pascal by itself was as much use as an ashtray on a motorbike but the successful implementations like VAX Pascal, Turbo Pascal, Delphi etc. came with a lot more (up to and including GUIs and Application Frameworks for Delphi). Visual C++ came with MS Foundation Classes and ODBC libraries. Java: a complete cross-platform GUI class library. PHP - fucking awful language - but the standard distribution included a shedload of libraries for HTML/XML parsing, database access: everything you needed for writing web backends. I remember wanting to write a program to parse some XML files (I couldn't help that they were in XML) and wondering if this was an opportunity to try Python. Looked for Python XML support and found a couple of half-finished XML libraries and a lot of online beard-pulling about the most "pythonesque" way of supporting XML - PHP came with an official build of Apache's XML libraries in the standard distribution (this was years ago, but not before python was well established - things may have improved now ).
On the one hand, the "rock soup" method probably helps ensure that we can get full-featured development tools for free, and helps stoping Microsoft from pulling an Embrace, Extend and Extinguish on competitors to Visual C++. It's easy to forget that in the "good old days" you had to pay for your developer tools. On the other hand, this reliance on third-party dependencies (which have dependencies on their backs to bite 'em) for much needed functionality is really getting out of hand (esp. NPM) - and we could do with some well-curated, stable, 'standard' packages to accompany these "new" languages.
(* OK that's an ECMAScript implementation rather than a language in itself, but regular ECMA/Javascript traditionally comes wrapped in a web browser, so the "platf" is usually DOM/HTML).
(Kids, get off my lawn and take your modern "fragile development" and "minimum viable product" rubbish with you! :-) )