In the ever-evolving landscape of software security, we’ve seen trends come and go faster than fashion statements at a high school prom. And just like fashion, not all trends are for the better. As someone who’s been in the trenches of software security and engineering for over two decades, I’ve seen my fair share of good, bad, and downright confusing practices. Today, I want to talk about three areas where the mainstream security advice not only misses the mark but also leaves us scratching our heads in confusion.
Security Shouldn’t Be a Gate—Or Should It?
Remember the old days when security was like that one strict bouncer at your favorite club, deciding who gets in and who’s left out in the cold? Yeah, those were not fun times for rapid release cycles. But then came the new wave of thought: “Security shouldn’t be a gate.” This sounded great on paper, but let’s not throw the baby out with the bathwater.
Security, at its core, is a quality checkpoint. It’s about making informed decisions. Take, for instance, our beloved fictional application, “MyOwnTutorial.” Imagine it has a shopping cart feature that occasionally gives the wrong price. Does it matter if this is due to a bug or a sneaky attacker manipulating cookies? In both scenarios, the user gets a price that’s not right. Similarly, consider a denial of service attack—whether it’s caused by a bug leading to an endless loop or an attacker bombarding the API, the end result is the same: service disruption. It’s up to the product team, armed with knowledge and context, to prioritize these issues. Security’s role? Guide, not gatekeep.
Prioritizing Based on Attributes: A Risky Business
The common practice of prioritizing security issues based on attributes like risk rating, the EPSS (Exploit Prediction Scoring System), Reachability/Exploitability, and others sounds rational. However, this method has its flaws. Attackers are opportunists—they don’t care if we label a vulnerability as “low risk”; if they can use it, they will.
Consider “MyOwnTutorial” again. Let’s say it uses third-party libraries that, while currently secure, haven’t been updated in a while. The conventional wisdom might suggest no immediate action since there’s no direct threat. However, what’s not a threat today could be a gaping hole tomorrow. Ignoring “low risk” issues or outdated components can lead to a tech debt avalanche, burying the application under vulnerabilities that, when combined, spell disaster. And while tech debt is snowballing, potential clients are running their own scans asking why haven’t these libraries with known vulnerabilities been updated?
The Great Security Tool Debate
Now, onto my favorite topic: the endless debate over which security testing tools are the best. It’s like arguing whether a hammer is better than a screwdriver—they’re tools designed for different purposes! Sure, not all tools are created equal, and context does matter, but the infighting within the security community about which tool reigns supreme is counterproductive.
Each tool has its strengths and weaknesses. Our hypothetical “MyOwnTutorial” platform could benefit from a variety of tools, depending on the specific security concerns at hand. The focus should be on leveraging the best aspects of each tool rather than looking for a mythical silver bullet. Remember, the goal is to secure our software, not win a popularity contest for our favorite tools.
While the landscape of software security is filled with advice, trends, and methodologies, it’s crucial to approach each with a critical eye. Security shouldn’t act as an impenetrable gate, but rather as a guide that helps the team navigate the murky waters of vulnerabilities and threats. Prioritization needs a balance between technical attributes and business context, ensuring that we’re not just fighting the last war but preparing for the next. And as for the tools of the trade, let’s remember that diversity in our security toolkit is a strength, not a cause for division.
So, the next time you find yourself navigating these security debates, take a step back and remember—the goal is to build secure, functional software, not to adhere blindly to the latest trends. After all, in the world of software security, the only constant is change.