Why Fixing SAST Findings Frustrates Developers and Security Teams

Fixing vulnerabilities in software is a critical task, but it's often a source of frustration for both developers and security teams. This frustration can be encapsulated in what we call "Vulnerability Hell," a situation marked by two main challenges: the Cyclone of Debate and the Cyclone of Fixing. Let's break down why these challenges exist and how they impact both sides.

The Cyclone of Debate

The first major issue is the Cyclone of Debate. When a SAST tool identifies a potential security vulnerability, it alerts the developer. But these tools often over-report issues because they lack context about the codebase. This leads to a significant number of false positives—estimates suggest anywhere from 25% to 50% of the findings fall into this category. In a large company with thousands of repositories across multiple programming languages, this becomes a huge time drain.

Security teams and developers then spend hours, sometimes days, debating whether a finding is a true vulnerability or a false positive. This back-and-forth can happen through countless emails, chat messages, and meetings. It's a time-consuming process that eats into productivity and causes frustration on both sides. Developers feel bogged down by what they see as unnecessary distractions, and security teams feel overwhelmed by the sheer volume of issues to review.

The Cyclone of Fixing

Once a vulnerability is confirmed as legitimate, the developer moves into the Cyclone of Fixing. Here, the challenge is implementing a fix that satisfies the security requirement without disrupting the rest of the codebase. For many developers, security is not their area of expertise. There are over 900 Common Weakness Enumerations (CWEs), each requiring a different approach to fix, depending on the programming language used. This complexity pushes developers into uncomfortable territory, leading to suboptimal fixes.

Moreover, the pressure to fix these vulnerabilities quickly can lead to rushed, temporary solutions. Sometimes, these fixes don’t completely resolve the issue, causing the same or new vulnerabilities to appear in subsequent scans. This not only frustrates developers, who feel they are chasing their tails, but also increases the workload for security teams, who must continuously review and revalidate these fixes.

The Root Causes of Vulnerability Hell

So why does this cycle persist? There are a few root causes:

1. Over-reporting by Tools: SAST tools generate many false positives because they can't fully understand the context of the code they analyze. This requires extensive tuning and customization, which is impractical at scale.
2. Lack of Security Expertise: Developers often lack the specialized knowledge needed to fix security issues correctly. With so many different CWEs to consider, it’s easy for them to feel out of their depth.
3. Disrupted Workflows: Security issues interrupt the development workflow, leading to "alert fatigue." Developers lose their flow, and the constant interruptions can sour their relationship with the security team.
4. Resource Constraints: Security teams are usually outnumbered by developers, making it hard for them to keep up with the volume of reported issues. This imbalance leads to backlogs and delays in addressing genuine vulnerabilities.

The Impact on Teams

The consequences of Vulnerability Hell are significant. Developers end up seeing security as an obstacle rather than an integral part of the development process. They experience alert fatigue and frustration, which can lead to burnout. Security teams, overwhelmed by the volume of issues and the constant debates over false positives, also face burnout and struggle to maintain a proactive stance.

Moving Forward

To alleviate these challenges, both developers and security teams need better tools and processes. Here are a few suggestions:

1. Improved Tools: SAST tools need better contextual analysis to reduce false positives. Machine learning and AI could play a role in enhancing the accuracy of these tools. Corgea (YC S23) recently launched Advanced False Positive detection to catch these findings. It leverages contextual analysis to understand the nature of the false positive.
2. Automated Fix Suggestions: Developers best learn when shown a real and practical example, rather than a generic one. Code-gen development now allows tools like Corgea (YC S23) to write the security fix for developers to approve.
3. Security Training: Regular training for developers on security best practices and common vulnerabilities can help bridge the knowledge gap.
4. Integrated Workflows: Seamless integration of security tools into the development workflow can help reduce disruptions and make security a more natural part of the development process. Corgea (YC S23) also introduced IDE extensions to help developers get fixes and advice in their IDE, eliminating the context switching.
5. Collaboration: Encouraging a collaborative approach between developers and security teams can foster better communication and mutual understanding.

Fixing vulnerabilities will always be a critical aspect of software development. By addressing the root causes of Vulnerability Hell, we can make this process more efficient and less frustrating for everyone involved.