This is probably not very good advice.<p>You <i>do</i> need a model for evaluating whether or not to trust a dependency, and for understanding if and when to extend that trust to a subsequent version/update.<p>I’m going to suggest that if your model is to fully understand the dependency, e.g., by reading every line of code, then you should probably stop having any dependencies and develop everything yourself —- just to save time. (But let’s face it, you should probably just find a new line of work).<p>It sounds glib, but I’m serious.<p>You can literally only run software only you’ve written, only on hardware you’ve designed and manufactured (and personally delivered), or you are trusting someone else, somewhere.<p>What is your basis for this? Actually?<p>If you’re not sure, but have an intuition, that’s not too bad… you’re in good company and like practically everyone else.<p>IDK, spend a few minutes thinking about what your model of trust is, and why even have one. Really, if the best you can come up with is to not trust anything you can’t personally verify, software development is not the best for you.
The article gives up on its clickbait headline almost immediately:<p>> <i>Of course you cannot do that with everything, you cannot read all the source code for the kernel of the operating system you're running, you cannot read all the code that makes up the compiler or interpreter you're using, but that is not the point at all, of course some level of trust is always required. The point is that you need to do it when you're dealing with code you are writing and importing!</i><p>OK, so we're drawing an arbitrary line of what we read and what we don't.<p>A basic web application at this point is going to import at least 10k lines of other people's code. A React app probably uses millions.<p>There's just no way around this. We all trust code we haven't read and have to continue doing it.<p>Reading code doesn't even guarantee finding security flaws. Most of us aren't security researchers, and none of us can understand an entire project's source code the first time we read it.
You don't need to read the code yourself, but ideally it should be vetted or reviewed by sources you trust. Maybe that's Debian / Ubuntu / Red Hat, or maybe it's through a review system like Rust's cargo-crev: <a href="https://github.com/crev-dev/cargo-crev" rel="nofollow">https://github.com/crev-dev/cargo-crev</a><p>Minimizing the number of dependencies helps a lot too.<p>But don't blindly npm or pip install something unless you trust the developers. npx/pipx are even worse. All it takes is a one typo-squatter to steal your ssh keys and maybe even saved browser passwords or cookies.
I just don't believe that I would have caught log4shell no matter how many times I read the code.<p>If some big org is using the same code I am then if there's a bug a patch will be written and released.
On top of all the other points raised here, I'm mystified by the author's reference to the Solarwinds hack. The whole issue with the Solarwinds attack was that Solarwinds themselves failed to notice changes to their own internal code, allowing attackers to push malicious updates using their infrastructure. No amount of code dependency auditing by any of Solarwinds' customers nor by Solarwinds themselves would have prevented that.
For commercial line-of-business application code, vendors will offer vetted versions of popular open source libraries/tools with SLAs for patches.<p>This will be a good thing for large companies, create a two-tiered world for open source, and create another set of gatekeepers. And if I were the author of a popular open library or tool, I would be thinking about how to get a piece of that action to support future development.
Is your own code free of security vulnerabilities?<p>Will you be able to identify and avoid issues with 3rd party libraries by reading their code, and the code of all the other libraries that they depend on?<p>Do you know what all vulnerabilities exist in cyberspace?<p>I mean that a static code analysis tool can take you much further than reading 3rd party code manually... and that is still going to fall short, but that is as good as it gets
Plug: I've been building tooling to easily audit third-party open-source dependencies for supply chain attacks. Packj [1] analyzes Python/NPM/Rubygems packages for several risky code and attributes such as Network/File permissions, expired email domains, etc. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out if a package accesses sensitive files (e.g., SSH keys), spawns shell, exfiltrates data, is abandoned, lacks 2FA, etc. It can be customized to your threat model by commenting out alerts that don't apply. We found a bunch of malicious packages on PyPI using the tool, which have now been taken down; a few are listed here <a href="https://packj.dev/malware" rel="nofollow">https://packj.dev/malware</a><p>1. <a href="https://github.com/ossillate-inc/packj" rel="nofollow">https://github.com/ossillate-inc/packj</a>
While I find myself agreeing with them occasionally, unixsheikh has an unfortunate habit of taking the extremum position in discussions like this, and not SUFFICIENTLY justifying it.<p>Reading code you use is a good habit. Reading it CAN improve its trustability, if you're familiar with both the language and the specific application space that the code operates in. Otherwise it's simply false that reading the code will help. In cases like that, it is better to use different heuristics for trust.<p>This 'overshooting the mark' behaviour is sadly very typical of a certain pocket of the Unix community, that have far too strong a conviction to their beliefs. I believe it severely damages the credibility of otherwise knowledgeable sources.
You can't trust any code, you can only evaluate risks and set your tolerance to those risks. There's plenty of third party code you can't read, like the code running your vending machine. I can tolerate a huge amount of risk in the code base for $1 though
Dependencies are generally terrible. One needs to consider whether they absolutely need something or just want to support complexity and vulnerabilities. NPM is the poster child of a giant tumbleweed of garbage no one reads and is half broken most of the time.
Author didn't mention node-ipc which I think makes his point much better than supply chain attacks. In supply chain attack, some security failure leads to sneaky malware injected into the build. One could argue that cryptographic signing could solve this problem. However, in the case of node-ipc, #the author# of the package inserted malware deliberately. No package signing can help you with that. Nor can community reputation, as github did nothing about the deliberate distribution of malware from their platform.<p>When that is the working environment, he's right. Trust no one.
You don’t want to be the one who read the code and certified it as good. You might become criminally liable for an attack.<p>What you want is to reduce your risk so if you can present evidence that Google or some other high profile has done the due diligence then that will be good enough to indemnify you.<p>Must regular developers don’t have time to read the code anyway. You need to use the slipstream of other companies to protect you.
I agree with the spirit of this post, but the idea of reading and understanding the code doesn't scale well. Perhaps a better way of expressing this is "trust, but verify". How trust is established varies depending on the size of the library and the reputation of the author(s). Verification obviously means rigorous testing.
It would be nice if we could import a library and have a way to only import the dependencies that are actually used in the code path, hide the rest and be notified whenever things change after an update.
Even if you do, you're still sort of screwed for reasons illustrated below:<p><a href="http://www.underhanded-c.org/" rel="nofollow">http://www.underhanded-c.org/</a>