> The problem is that cybersecurity is ridiculous hard problem. I don't believe that. Making perfectly secure software at large scale is indeed very hard, but

> The problem is that cybersecurity is ridiculous hard problem. I don't believe that. Making perfectly secure software at large scale is indeed very hard, but a lot of security issues we see every day have little to do with lack of perfection. There's a ton of low hanging fruit out there. > The junior to senior developers are just using existing frameworks with poor documentation. Yes, I do believe that the modern way of quickly ducktaping junk together while paying little attention to security does make for lots of security issues, which might give someone the impression that cybersecurity is ridiculously hard. Security requires proactive effort. It's not ridiculously hard, but it needs to be done, it requires time (just as anything). Leaving it for "hope you don't write buggy code" and "does colleague notice the gaping hole in code review" is not doing security, it's just winging it. And I've never really been asked to do security, even when literally working on a security product. Everyone just seems to assume security is an automatic byproduct of skilled programming, but it's not when the pressing concern is "how many hours/days/.. does it take to ship this new feature oh and we have three dozen other features that need to be implemented soon" and "can we get it sooner?" and "why is it taking so long, it's not that hard!" It needs to be discussed, planned, designed, reviewed, tested, verified, questioned, audited. Just like anything else, if you want quality. None of this is ridiculously hard, but it needs to be done for it to be done. If it's not being done, it's that the organization doesn't care about it. In a lot of ways it's similar to technical debt. Are you taking the time to avoid it, reduce it, get rid of it? No? Then you're accumulating it. Security issues accumulate just like technical debt when ignored. And even the most skilled programmers do generate technical debt (because they don't jump into a problem with perfect knowledge of what needs to be done). Depending on the organization, they may or may not get to fix it. Many organizations just don't care and would rather have the devs work on something "more productive."