Security Alerts: Don’t developers have something better to do with their time?

In the last two decades, with the rise of mobile, web, and cloud applications with multiple deployment options such as on-prem, hybrid, and cloud, we have witnessed an increase in the usage of security tools targeted towards Software Development Life Cycle (SDLC) processes and workflows. Unfortunately, these tools often generate many false positives, which results in wasted time and significant frustration.

One of the main goals has been to find and remediate security vulnerabilities as early as possible in the SDLC (called “Shift Left”), resulting in less time and resources needed to fix those vulnerabilities, along with not dealing with negative impact on brand recognition if those vulnerabilities were found during the production stage. It is also much more difficult for the development team to “remember” what they did and how to fix those vulnerabilities after a certain amount of time has passed.

With the shift of software development to an “Agile” workflow, delivery of products/features/fixes has increased rapidly. There is a parallel rise in security tools usage in the software development life cycle, those tools are being used more frequently than ever.

Security Tools including Static Analysis, Fuzzing, Dynamic Analysis, and others are the default go-tos of CISO and security architect teams aiming to integrate Security into the SDLC, with the goal being to catch those security problems as soon as possible in the product development.

Unfortunately, more tools means more alerts, and these tools can combine to generate thousands of security alerts that will have R&D teams spending significant time reviewing and triaging. Because those tools lack the context of code flow, don’t integrate with each other and don’t truly understand the source code, they will generate a non-trivial amount of false positives.

Dealing with security alerts is a daunting task for developers and security architects as it asks them for meaningful time and resources to review the generated security alerts and triage them. Taking into consideration the short “Agile” development cycles of coding & shipping fast, developers and managers want to utilize and maximize their time

Dealing with security alerts is a daunting task for developers and security architects as it asks them for meaningful time and resources to review the generated security alerts and triage them

The pain starts when they identify numerous defects as false positives: triaging one by one and discovering a high percentage of false positives results in a lack of trust in those tools. This can lead to half-hearted investigations into alerts and even result in missed “true positive” security vulnerabilities.

Security, development, and legal teams need to better understand their code, from the history of the code base to the context provided by Jira tickets to conversations about the new feature on Slack. The developers themselves are also incredibly important to understand, from their experience with certain technologies to their security knowledge. Visibility of the entire picture – from the design phase to development can minimize false positives by giving a more contextual overview of how code was designed –  and eventually how it was coded. For example, understanding API design, which services are involved and how it was coded can help with lowering false positive rates. In addition, having this visibility, we can prioritize code changes and focus security teams on what matters most for better and accurate alerts.

Differentiate between changes – before CI/CD!

Differentiating between changes will help you adhere to this advice from Gartner:

“Stop trying to remove all unknown vulnerabilities in custom code, which increases false positives. Instead, focus developers on those with the highest severity and confidence.”

Doing this will change your entire approach to security in software development. It will help you stop thinking about security as a checkbox function and more of a context-aware process. You’ll have fewer, but more relevant alerts, and many fewer false positives. That will help developers do something better with their time … develop.