Is software less secure these days? It’s tempting to say yes. I’d love to blame the corporate sector for egotistically dumping low quality software on us. I’d love to blame marketing-oriented people developing stuff with the sole goal of making a profit. I’d love to blame Rust for getting people obsessed about memory safety, and ignoring the kinds of vulnerabilities that aren’t caught by the compiler. Finally, I’d really love to blame slop. But the truth is, I don’t know. That’s really beside the point.
The point is that nowadays everyone and their chatbot became security researchers. Projects are being flooded with vulnerability reports. Even though pretty much every bug bounty was discontinued because of slop, people aren’t stopping. And even if we disregard truly invalid junk reports, there’s a lot left, and you have to deal with them somehow. You have to figure out how important they are, and how to fix them (or more likely, whether the fixes submitted are truly valid and don’t introduce regressions), or if you should reject them and why.
In the end, security is tricky. We’re seeing lots of bugs like REDoS, or other kinds of “performance bugs”. Are they really vulnerabilities? Well, it depends on the attack vector. And that in turn depends on how the software is used. Some scenarios are really conceived, and feel like “shell can execute dangerous commands if you type them in”. But then, you also have really serious issues such as “timing attack can be used to guess user’s secret”. You need to know a lot to make that kind of judgment, and sometimes your judgment doesn’t really match users’ expectations.
In the end, what can project maintainers do? Even if they have the expertise and the energy to judge, if they can “know better”, there’s likely a CVE assigned already. It may have absurdly high score. All security scanners will complain unless you fix it, and users will come asking or complaining, or attacking, or forking. I mean, technology can’t handle nuances. More than once I’ve been doing unnecessary security stabilizations over vulnerabilities that didn’t affect Gentoo (for example, because we already unbundled the vulnerable dependencies), to avoid false positives from security scanners. I’ve been also doing meaningless version bumps (with no real changes or no changes that applied to Gentoo) so that our packages don’t get reported as being “outdated”. It’s a hassle and it sucks, but it saves people from worrying.
I’ve said this before and I’ll say it again: most projects aren’t really prepared to handle security issues. And it’s not just about triage. It’s about having LTS or security branches, it’s about making proper security releases with minimal changes. Unfortunately, it’s quite common for security fixes to be combined with new features, deprecations, API changes. In extreme cases, people are caught with their metaphorical pants down, and suddenly need to make a security release in the middle of a major rewrite, or along with barely tested new code. And then, people downstream discover that they need to quickly deal with major API changes to upgrade past a vulnerable version. These things keep piling up.
What happens next? The community reaches a breaking point. People can’t keep up. You discover you can’t rely on others, so you work around them. You start bundling more stuff. Soon enough your workload goes beyond your ability. Software development becomes “every chatbot for itself”. The nightmare becomes worse, and the wheel keeps turning.
Originally published at blogs.gentoo.org.