Custom rules in security tools can be a game changer for vulnerability detection

In this Help Net interview, Isaac Evans, CEO at Semgrep, discusses the balance between speed and thoroughness in CI/CD pipeline security scanning. Stressing the need to avoid slowing down the process, he recommends a nuanced approach, utilizing custom rules to tailor security findings to an organization’s coding practices.

Evans also discusses the impact of a developer-first approach, the significance of minimizing false positives, and highlights the potential of modern security tools, particularly those integrating AI and secure code development guardrails.

Given that speed is a critical factor in security scanning, how can users balance the need for thorough vulnerability detection with the requirement for rapid scanning in CI/CD pipelines?

There’s a big difference between the slowest and the second slowest checks: security must never be the slowest part of the CI/CD process. Enforce this as an invariant to avoid developer anger. Speed is critical for scanning in CI/CD pipelines, and especially so for security results presented to developers in those pipelines. However, security teams need not take a binary approach to the tradeoff of fast scanning vs. vulnerability detection.

Instead, they should maintain scanning speed by focusing on high-priority issues that can be actioned by developers and leave more comprehensive vulnerability detection to periodic scans that can be reviewed by the security teams without interrupting the developer workflow. This instills confidence in both teams that actionable issues are being raised and that code is comprehensively scanned.

How significant is the ability to write custom rules in security tools for organizations, and what impact does this have on the effectiveness of vulnerability detection?

Most security tools come packaged with “out of the box” rules to detect security issues. These provide a solid foundation for teams to secure their code, but they are not optimized for a particular organization’s coding or security practices. If these issues are all presented directly to developers, they may lose trust in the security team and tool due to the number of irrelevant issues produced.

The ability to write custom rules enables teams to adjust these default rules and gradually increase the number of issues surfaced directly in developers’ workflow, thus producing increased confidence in the accuracy and actionability of security findings. This allows organizations to maintain code release velocity and shift left without an “all or nothing” approach. Without this, security tools risk alienating those who consume their output, including both security and development teams.

Can you discuss the strategies to minimize false positives in vulnerability detection and why this is important for developer efficiency?

False positives and high noise are a shared problem between AppSec and developers, slowing developers down and damaging overall trust in security processes. In order to minimize false positives, security teams should only present high-confidence findings to developers in their workflow. The resulting mutual trust, based on a shared understanding of confidence and priorities, can then enable teams to collaborate on exposing more findings to developers.

Without this shared trust, developers and security teams can’t collaborate effectively, leading to inefficiency and a slow down across the organization.

How does a developer-first approach transform the security landscape within an organization, and what are the key benefits of this approach?

By taking a developer-first approach, security teams can take significant steps to build trust with their developer stakeholders. This trust is foundational to the credibility that security teams have internally, and can lead to the creation of “security champions” within development teams. The ultimate benefit resulting from this mutual trust is the maximized impact security teams have in terms of making meaningful improvements to the organization’s overall security posture, and the feature development velocity that engineering leadership need to sustain.

Can you provide insights into how complex security scenarios, like the Log4Shell vulnerability, are managed and mitigated using modern security tools?

Modern security tools can quickly uncover how an organization is exposed to high-impact security incidents such as Log4Shell. This includes identification of where the exposure points occur and the necessary steps for remediation. When presented with the developer-first approach described above, modern security tools can thus protect the organization from additional impact, and especially compared to legacy tools, significantly accelerate the time to issue resolution.

What is the next big development in security scanning tools, and how should organizations prepare to integrate these advancements?

Security scanning tools are undergoing a renaissance, with modern tools shaking up an industry that had become stagnant. Among the most important developments are the integration of AI and the use of guardrails for secure code development. Both advancements have shown incredible promise, and admittedly, a large amount of hype. With AI, there’s a significant opportunity to leverage its capabilities through automated recommendations for triage and for code remediation, thus saving teams immense amounts of time.

With secure guardrails, organizations can move towards preventing entire classes of vulnerabilities from occurring in the first place, instead of being stuck in a doom loop of bug whack-a-mole. Since there won’t be a “one-size-fits-all” approach, organizations should recognize the hype and thoughtfully integrate tools that enable them to test these advancements in their own environments.