Rethinking the Scan and Fix Hamster Wheel: A New Paradigm for Application Security

If you've been in the application security landscape long enough, you know that we, as an industry, seem to be stuck on a hamster wheel of scanning and fixing. Having led many conversations about this issue, it's clear that our traditional approaches, such as SAST and DAST tools, have us chasing our tails rather than enabling us to be proactive about security. Note that we are proponents of SAST tools and believe they add value when properly tuned. DAST is another story; DAST should be removed.

Shifting left doesn't solve the problem; it merely starts the cycle earlier. We urgently need to rethink our models, particularly in a more synergistic way with development workflows.

The origins of this cycle can be traced back to network vulnerability tools like Nessus, which pioneered the "scan and fix" method. Scan a network, find open ports, identify likely vulns, and generate a list of issues via report. SAST followed this pre-existing and flawed paradigm when it came onto the scene, substituting code for the network and security flaws for the ports and vulns.

The process is simple but destructive: scan the code, identify vulnerabilities, generate a list, and throw it at developers. Not surprisingly, this fire-and-forget approach led to backlogs, inertia, and a considerable drain on development resources. The primary challenge is dumping this list of problems on development teams and saying, “Fix them. Fix them all!” Development teams then have 10,000 issues to prioritize, of which most get junked over some time.

The Illusion of Shift Left

You might argue that "shift left" is the answer, integrating security earlier into the Software Development Lifecycle (SDLC). But does it genuinely alleviate the problem? Spoiler alert: it doesn't. The hamster wheel continues to spin, albeit a bit earlier. While the intent is noble, the implementation leaves us wanting more holistic solutions. It's not uncommon for developers to rely on shift-left methodologies to catch security vulnerabilities in their code before deployment. However, the idea of shift-left can lead to a false sense of confidence, resulting in a lack of post-deployment security fixes. This, in turn, creates a vicious cycle.

To break this cycle, it's essential to implement a comprehensive security strategy that prioritizes security in the design phase. While shift left can help catch some vulnerabilities early in the development process, it cannot replace the need for regular security reviews and post-deployment fixes. Organizations can protect their data and applications from known and unknown threats by adopting a more holistic approach to security.

Is AI the Knight in Shining Armor?

Recently, there's been talk about leveraging Artificial Intelligence to ease this burden. The idea is compelling: AI-powered tools scan and even generate fixes for you. However, even this elegant solution doesn't escape the fundamental flaw—it's still rooted in the "scan and fix" model and the reactive nature of this approach. We're merely trading manual drudgery for robotic automation without addressing the underlying issues.

1. Over-reliance on Automation: Entrusting AI with too much responsibility can lead to over-reliance on technology without human oversight. AI can make errors, and its decision-making process might only sometimes align with the nuanced intricacies of application security. What happens when the AI writes the code and then the AI reviews the code?

2. Potential for Missing Context: AI operates based on data and patterns. There could be scenarios where AI might miss the larger context, either overlooking genuine threats or generating unnecessary alerts. AI is not going to discover unknown classes of vulnerabilities. AI can only report on the news it hears at least once.

3. Static Evolution: If AI tools are solely trained on past vulnerabilities and attacks, they will need to be more adaptive to predict and address novel threats that haven't been encountered before.

4. Overhead of "Robotic Fixes": While AI might generate fixes, there's no guarantee that these fixes are optimized or efficient. Implementing them without review could introduce other issues, like performance bottlenecks or new vulnerabilities.

The IDE Experiment: Just-in-Time Security

A more recent experiment has been to introduce real-time scanning functions into Integrated Development Environments (IDEs). While this helps catch security flaws on the fly, the constant interruptions could hamper a developer's flow, compromising productivity.

1. Interruptions in Workflow: Scanning for potential vulnerabilities can disrupt a developer's flow and lead to a loss of focus. This can cause interruptions and significantly impact productivity. Just ask any developer the time it takes to regain focus.

2. Signal to Noise Ratio: Real-time scans generate many alerts, but not all are relevant. Sorting through the high volume of notifications, including false positives, can be frustrating and time-consuming for developers.

3. Overhead on System Resources: IDE real-time scanning consumes resources and may cause performance issues, especially when handling large projects or on less powerful machines.

4. Dependency on Network: Some scanning tools require an active Internet connection to cross-reference vulnerabilities with online databases. This can introduce latency, and any network interruptions can impact the effectiveness of the scans.

In summary, while introducing real-time scanning functions into IDEs offers the promise of more secure code, the potential interruptions and challenges associated with this approach can significantly compromise developer productivity. IDE plugins make the scan and fix pattern in real life, and the interruption factor is a deal breaker for most developers. Balancing security and efficiency remains a delicate act, and tools must be designed with a deep understanding of developer workflows to truly integrate seamlessly.

A Call for Industry-Wide Innovation

Do you see the common themes? Overwhelming and unmanageable numbers of alerts and notifications. Interruptions to workflow and code development. Reliance on tools that may have only some of the context necessary to make good decisions.

We don't merely need another tool or another buzzword. We require a seismic shift in how we approach application security, one that harmonizes with development practices rather than disrupts them. In pursuing Secure by Design, our models should empower development teams to anticipate and mitigate threats efficiently and effectively without becoming a roadblock.

We're at an inflection point. The hamster wheel has spun long enough. It's time to step off and forge a new path that aligns security with the natural rhythms of software development. This is the crux of my pursuit to bring threat modeling to everyone, every team, every application.