DaaS is Dumb

Software Dependencies as a Service (DaaS) are both dangerous and (because of their danger) dumb. They are a danger not only to their direct users but every downstream user of those users, recursively, ad nauseam.

Historically speaking, the malware typically targeted "average users" and attempted to trick them into installing something they shouldn't. Nowadays, with some irony, the favored (and far more effective) target is a more tech-literate crowd - software developers. A single packaging-service-based breach frequently successfully hits many, many more targets than any given email phishing campaign could ever hope to.

Try researching "what are the largest vectors of software supply chain attacks?" via your search engine or LLM of choice. (Spoiler alert: they are DaaS and github, the latter largely via the former.)

This page attempts to link to enough info for anyone to see that for themselves, but, frankly, if it is not self-evident then no article will be convincing to someone who believes otherwise (which, let's be honest, is 90% or more of modern software developers). Non-believers are going to keep on using them no matter what some old man has to say on the matter but, one of these days, they're are going to wish they hadn't. Those affected downstream will also wish that they hadn't.

Some of the affected platforms, in no particular order (except for the first one, which is easily the biggest target, victim, and perpetrator):

A minuscule subset of links describing DaaS-empowered breakage, attacks, and related topics:

The common factor in all of these? Software DaaS.

Again: this is just a tiny, tiny fraction of relevant articles, and finding untold hordes of them does not require more than a single search engine query.

In conclusion

DaaS is dangerous and, because of this danger, relying on DaaS is ill-advised.

Sidebar: OS Package Repositories

So how does DaaS differ from OS package repositories used by every modern OS?

They fundamentally don't. They suffer from the same security issues.

It's absolutely fair to ask, "so why do you despise software development DaaS but not OS package DaaS?"

The answer is simply that it's "an uncomfortable grey area", a matter of "severe practicality", to the extent that it's effectively a necessity, in the same way that we cannot expect automobile owners to drill for and refine their own fuel or manufacture their own engine parts.

My arguments in favor of accepting OS packages as a necessary fact of life, while also rejecting software dependencies as such, include...

OS package repositories, despite being DaaS, are effectively required for OS usability. Most computer users lack the technical know-how to go find software and install it themselves using a different approach for each package. There are no standards for doing so beyond the not-uncommon conventions of running ./configure && make && make install or double-clicking setup.exe. Even for those who know how to install software from their original sources, actually doing so is frequently not realistic. Many commonly-used packages (say a web browser or office suite) require installing hundreds, sometimes even thousands, of megabytes of dependencies just to get them built, and may require many hours to actually build. That time, network bandwidth, and electricty usage, multiplied by the number of users who would need to do so if package repositories did not exist, adds up to a tremendous waste of lifetime and resources.

Contrariwise, source code dependencies are a convenience for the very specific niche of users known as software developers who...

Adding a line to a JSON or YAML or TOML file does not quality as "dependency management", it qualifies as "passing the buck". One must, i strongly opine, be able to both readily list and justify each and every dependency their software uses, including all transitive dependencies. The latter are a much richer target for malicious actors for the simple reason that they are one or more levels removed from a developer's direct responsibility chain, i.e. they are both "out of sight, out of mind" and "someone else's problem", and therefore tend to undergo less scrutiny.

Practicality aside, OS package repositories do not use the "throw it over the wall to provide access to the whole world" approach which the various software DaaS platforms use. OS packages are more carefully moderated, most frequently by someone other than their initial developers. That is a significant distinction akin to the practice in some organizations of not permitting the developers of a system to have direct access to the production/live system.

It is of course possible for end users to add entries to their package manager's local database in order to import arbitrary software which is not being gate-kept by higher-level packaging maintainers, bypassing all security gained via gatekeeping. Similarly, it is possible for such packages to themselves modify the package database to maliciously install other packages. When installing "out-of-band" packages, the onus of gatekeeping falls to the user, precisely as is the case when not using any sort of package manager (e.g. when building software from its source code). Malicious single-package distributions, outside of package management systems, are relatively rare. Presumably this is because hitting a small number of targets is generally not cost-effective for attackers, who almost invariably go for "the big score" - hitting hundreds, even tens- or hundreds of thousands (even millions!), of targets in a single go, many of whom will not apply mitigation in a timely manner (thereby giving malicious scripts more time to propagate).

In any case... OS software packages as a service is an uncomfortable grey area, in that allowing for exceptions to safety-critical rules is invariably uncomfortable.