Dad (who was a history professor) liked to say that History repeats itself because nobody listens the first time. I get an incredible sense of deja vu all over again looking at Mitre's list of top 25 exploits for 2025.
The top 4 are all very, very old. I myself demonstrated #4 when I taught a computer security class (with corporate IT Security present) back in 1994. That's three decades ago.
And what's with numbers 11 and 14? One of the classic papers on software security is Smashing The Stack For Fun And Profit - from 1996.
Numbers 3, 6, and 22 are web server vulnerabilities that are over 20 years old, and I've posted about them before.
17, 19, and 21 have been known since before I was in this industry. Call it the 1980s, although it's likely older.
I guess it's nice to see a shout-out to DoS (number 25) although geez, this is depressing.
So that's half the list having been known for literally multiple decades. So what gives?
I blame Agile Software Development. I guess I'm the cranky old guy yelling at the sky here, because this is how all software is developed these days. Product Managers (my old field) are to blame here, having spent the last 20 or 30 years pushing Go Ugly Early - get working product shipping as soon as possible and let customers tell you how to improve it. Essentially, a lot of what you would have the developers spend their time fixing are things that customers just don't care about.
This has led to a pushback of sorts from software professionals, particularly the Software Craftsmanship movement. Their manifesto is interesting:
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships
So what's missing from this? How about don't keep making the same dumb security mistakes that people have been making for decades?
And what do Product Managers miss in their rush to go ugly early? How about don't keep making the same dumb security mistakes that people have been making for decades?
And so here we are. The IT infrastructure of the 21st Century has been constructed out of moonbeams and cotton candy.
I don't see anything changing here, as the incentive structures are all stacked against good security.
3 comments:
Security has (and will always) take a back seat to convenience because people refuse to wait even a few seconds to allow for security overhead, much less Marketing droids delaying a product release to remediate the issues found in the latest security scan of the product.
Security will always take a back seat as long as Our Betters insist on their right to look at EVERYTHING we do. Five Eyes, then Nine Eyes, and now Fourteen Eyes have befouled everything for MANY years now. Until they are dealt with properly, there is NO security on the Internet.
Security is always pushed aside when it affects SQA testing. Can't tell ya the number of times I was told "what happens if you turn off the security features - does it work?", and when I answered "yes" I was told "Ok, let's put the security features on a parallel development track". Of course that second "parallel development track" was never fully synchronized with the mainline code, thus leaving the mainline code unprotected.
It was always an issue of "cost". As someone who worked for a long time (decades?) developing military embedded systems, I don't have enough fingers to count the number of times I was told "ship it" when I *knew* it wasn't field-ready.
Post a Comment