Resurrecting Shift-Left With Human-in-the-loop AI – Source:www.hackerone.com

As software development cycles grow shorter and more iterative, ensuring the right security controls are deployed with new functionality is more critical than ever. For security and development teams, one of the biggest challenges is catching insecure code before it’s merged — without overloading developers with extra work or sacrificing productivity with prohibitive gatekeeping. 

Implementing security policies in development isn’t easy. No one has gotten this quite right yet.

A successful strategy needs to fulfill security needs, work well with developers, and break the cycle of compromising one over the other.

What’s Needed for Secure by Design Success

We spent years understanding the culprits of why “shift-left” controls fail to identify the principles needed for them to succeed. Success starts with a developer-first foundation and a discipline to eliminate work vs. create it.

The Developer-first Application Security Foundation

To guide developers to write secure code, they need to be armed with actionable information. In fact, use “actionable” interchangeably with “useful.”

The key ingredients for actionability are context, speed, and low-noise output. It needs to be focused, fast, and understand what’s being analyzed. Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools are fast but fall short on context and noise. The problem is how often they’re not right—bombarding developers with false positives and duplicate warnings.

The source of information needs to continuously learn. A process is doomed for failure if developers need to constantly explain their work and escalate exceptions. Developer security tools need to listen, watch, and adapt without intervention. If application security listens to developers and provides value, developers respond by listening and learning back.

When application security activates in development, it should be non-blocking. Blocking mechanisms bring development—and everything else—to a halt. They incentivize creative bypasses, not secure code. Applying preventative safeguards is important, but overburdening developers because they work on the pre-production side of the SDLC is hardly a balanced defense-in-depth strategy.

Finally, security can’t just make noise at developers. Remediation needs to be part of the solution. To address issues that arise, there needs to be interactive support throughout the lifecycle.

Where “Shift Left” Went Wrong

Efforts to introduce security testing earlier in the SDLC usually begin with applying SAST (and IAST, DAST, SCA, RASP, etc.) scanners. These are fast and, because of broad compatibility with most programming languages, theoretically scalable. The problem is the work it takes to prove their output is right or wrong, leading to compounding backlogs. And upon examination, they’re often wrong, leading to security policies developers don’t trust. It’s here where application security in development stalls: trying to make a dysfunctional policy work (as security debt grows).

None of this is to say security code scanners aren’t powerful and valuable. Their maintainers, whose work has done the world a great service, never claimed for them to stand as a single strategy. “Shift left” failed developers as a well-intended, unspoken hope that there’d be an easy fix to a hard problem.

The Future of Developer Security with AI

Scanners are limited when it comes to things like understanding massive legacy codebases, identifying misuse of functionality in microservice architectures, and finding flaws related to code not written. Here, AI shines and the future looks bright. 

Models, trained on corpuses of training data, are capable of analyzing entire codebases. Secure code systems can flag areas that deviate from normal patterns. Great news for developers and security engineers who have carried 100% of the manual secure code review burden for years.

Is AI alone the solution to right what “shift left” got wrong?

Embarking on these opportunities made possible with AI, it’s important to remember technology is a tool, not a replacement for invaluable human expertise.

Human-AI Collaboration

Rethinking “shift-left” security strategy by incorporating AI technology is exciting, but warrants safe and responsible exploration. Execution of deployment requires human-in-the-loop (HITL) oversight as a governing principal. Conventionally, objectives of a HITL methodology are to improve the models they oversee—ensuring AI systems are accurate, robust, ethical, adaptable, and align with real-world goals.

Let’s challenge conventional thinking.

Instead of prioritizing the efficacy of AI systems, what if human-in-the-loop oversight priorities begin and end with helping a developer write secure code? What if human experts can not only categorize model output as “right” or “wrong,” but expand on what’s “right” so it’s actionable with all of the context details taken into account? What if they’re a teammate who can help a developer on a problem-solving journey of taking action to remediate?

Let’s Resurrect Shift-Left Security

Check out the on-demand webinar during which we discuss how a human-AI collaborative approach transforms security from a dreaded blocker into a powerful enabler of development velocity.

Broken Security Promises: How Human-AI Collaboration Rebuilds Developer Trust
Originally aired on Jan. 16, 2025 @ 12pm ET

Stay tuned for more insights into how HackerOne is working with dev teams to reinvent secure development together.