Shifting left has been a buzzword in the application security space for several years now, and with good reason – making security an integral part of development is the only practical approach for modern agile workflows. But in their drive to build security testing into development as early as possible, many organizations are neglecting application security in later phases and losing sight of the big picture.

Shifting left: misunderstood, misapplied, and absolutely necessary

In the AppSec industry, we’ve been repeating the shift left mantra for years, saying over and over that the only way to ensure effective and efficient application security testing is to integrate it with the development process. While absolutely true, this includes one tiny yet critical assumption: that you are also doing application security testing on the right, i.e. in staging and production. What’s more, the very term “shift left” can be misunderstood as moving all security testing to development – and doing that can leave gaping holes in your security.

Let’s say you do extensive security testing during development, and you feel pretty confident that as they go into staging and production, your applications contain no significant vulnerabilities. But even if that is true (and that’s a big “if”), vulnerabilities might crop up after deployment due to configuration or version differences. New vulnerabilities may be discovered in your technology stack, whether in frameworks, libraries, or other components. New attack techniques may appear in the wild. And finally, your security testing will only cover new and updated code that goes through your left-shifted pipeline – existing sites and applications will be untouched by security testing, as will third-party products that are used in your organization.

There is no question that extending security testing tools and workflows to involve the developers is a must if security is to keep up with the pace of change enforced by agile development. In fact, we have a whole white paper about it. But checking new code for vulnerabilities is only one piece of the security puzzle – and to build the complete puzzle, you need a broader view.

Building an AppSec program that works

Professional web development is not easy. Developers already have their hands full making features work while keeping up with the latest technologies and meeting all the requirements and release deadlines. If you decide to shift security testing left by simply bolting on more test tools, you are piling even more tasks and alerts onto your overworked devs. Unless they are actionable, the extra alerts will only increase noise for little security benefit.

One way to deal with this while keeping sight of the big picture is to base your application security program around dynamic application security testing (DAST). Modern DAST solutions are accurate enough to provide useful feedback to developers but also versatile enough to operate in all stages of development, testing, and production. Invicti products also feature asset discovery, so you always know what you have and what you need to secure.

For Netsparker specifically, a crucial benefit is that with Proof-Based Scanning technology, you can provide developers with actionable reports about real, exploitable vulnerabilities, complete with best-practice remediation guidance. Using out-of-the-box integrations with popular issue trackers, you can even automatically create tickets in the tools your teams already use. And when the additional IAST module is deployed, vulnerability reports for developers can include details down to the specific line of code, making remediation much easier.

This completely changes the dynamics of application security testing. Instead of a flood of vague recommendations saying “this bit could be insecure, you may want to take a look,” developers get factual, actionable tickets in their favorite issue tracker. Instead of rewriting code to make the alert go away, they know that they are fixing a specific and exploitable vulnerability that malicious actors could use to attack the application. That way, the extra work done on security issues makes a real and measurable difference to your overall security posture.

Reducing and avoiding security debt

The idea of technical debt is well-known in the development world. You might have lots of code that depends on an outdated library, but the old library is still good enough. Updating all that code would mean lots of extra work and testing, so it always gets put off for later in favor of more urgent and valuable projects. This technical debt often accumulates until something breaks, and then you fix it because you really have to. Now apply this exact same concept to security, replacing “until something breaks” with “until you have a breach” – and you have your security debt.

For application security, this debt can accumulate on many levels, from using known vulnerable components to treating your web application firewall (WAF) as a long-term solution rather than a band-aid until a vulnerability fix is ready. You might even get recurring debt, where the same types of vulnerabilities keep coming up over and over again due to poor coding practices or insufficient remediation guidance. All this adds up until many organizations give up on systematically securing all their applications because no matter what they do, their security backlog keeps growing.

The only way to deal with security debt is to resolve security issues as you go rather than sweeping them under the carpet. To get there, you need to give your developers the tools and processes to fix vulnerabilities quickly and permanently. This is where the value of a DAST-centric shift-left program with a proof-based approach becomes evident. Focusing on actual weaknesses that could be exploited by attackers helps you continuously improve security and coding practices to prevent security issues from piling up.

Security is all about the big picture

Recent high-profile incidents are finally hammering home the message that in modern web security, there’s no such thing as an unimportant application. Attackers can pick their time and place even as the attack surface of applications (and organizations) continues to grow, spanning new and existing code, multiple web technology stacks, open-source libraries, third-party components, and more. To know your true security posture, you need to start with the big picture before drilling into specific vulnerabilities.

Modern vulnerability scanning solutions such as Netsparker by Invicti are highly accurate and can run full scans in a matter of hours and incremental scans in minutes. For existing applications, this allows you to scan your entire environment for vulnerabilities as often as you need – even daily if that’s what your security policy mandates. For security testing in the development pipeline, it means giving rapid and actionable feedback to developers who can then quickly and effectively fix security issues in their own code.

All the time, you have full visibility into your current security posture while also improving your long-term application security. And because you are working with reliable data, your security and development professionals are not wasting time on inefficient communication or misleading results.

This is shifting left done right.

Source: Netsparker