This is a great list. One minor criticism on... > Monorepos are easier to audit. > Speaking from the perspective of security researcher ergonomics, it was ea

This is a great list. One minor criticism on... > Monorepos are easier to audit. > Speaking from the perspective of security researcher ergonomics, it was easier to audit a monorepo than a series of services split up into different code bases. There was no need to write wrapper scripts around the various tools we had. It was easier to determine if a given piece of code was used elsewhere. And best of all, there was no need to worry about a common library version being different on another repo. This is much more dependent on the auditor's personal workflows (as well as the relative hygiene of any team's monorepos), rather than being universal. I've found the opposite to be true for e.g. the current orgs that I am auditing: individually split up repos tend to be idiomatically structured, and "just work" as expected more often than monorepos, which more often than not have a lot of custom glue or unusual monorepo-management init scripts. Comments on the other (generally very good) points in the list: > Writing secure software has gotten remarkably easier in the last 10 years. I don’t have statistically sound evidence to back this up I suspect compiling such statistical evidence would also be impossible as detection of security issues has also improved, so any data would never be comparable over time. > The counterargument to this is that heavily weighting discoverability perpetuates ”Security by Obscurity,” since it relies so heavily on guessing what an attacker can or should know. But again, personal experience strongly suggests that in practice, discoverability is a great predictor of actual exploitation. This is a tough circle to square because security by obscurity works. It's probably the best security measure you can have in place. But it's bad for two reasons: (1) The process of obscuring often (doesn't need to, but very often) obscures auditing, which means you end up relying upon obscurity solely. It's not a worthwhile trade-off. (2) In a simplistic marketing world, the idea of obscurity as a standalone measure is so tempting to non-technical decision makers that I believe it requires a bit of innocent dishonesty about it's effectiveness to dissuade. > (on auditing dependencies) Node and npm were absolutely terrifying in this regard—the dependency chains were just not auditable. I agree with the overarching bullet point this is said within, but I see this point about NPM said a lot, and I'm not sure how people are going about auditing or how many language ecosystems they're looking at. I have found Node/NPM to be the best / second best popular system for auditing dependency chains. I have significant experience in this area: the relative consistency of package management config across the JS/TS ecosystem is enormously helpful for software composition analysis - the only package manager configs I've found that may be slightly better is Composer, but the inconsistent usage of Composer by many PHP devs still makes it a little worse than NPM in practice. PIP /PyPi / setuptools is an inconsistent moving target of requirements.txt (is it a lockfile?), pipfile.lock, setup.cfg -vs- setup.py, pyproject.toml, and whatever else. Maven is a nightmare of multiple registry endpoints, and issues parsing custom <dependencyManagement> directives, extensions (without even starting on maven wrappers and pom.xml templating strings). Don't get me started on Gradle. Go's idea of package management is: just pull it from Git; good luck automating it if you've got private repos with any kind of secure ssh auth. I have less personal experience with Rust/Cargo. > for some reason, PHP developers love to serialize/deserialize objects instead of using JSON PHP serialize/deserialize predates the existence of the JSON spec., so that might have something to do with it. A lot of PHP code is old. > Almost no one got JWT tokens and webhooks right on the first try. Nor the second try...