Why AppSec Shifted Left

Software is a basic building material of our modern digital world. The infrastructures which manage our lives, businesses and governments are largely composed of software. The ability to run an organisation is in many ways dependent on our ability to develop and use new software products and services.

The demand for new software grows aggressively with each passing year. In order to maintain competitiveness, enterprise development processes have been squeezed to the point of breaking. In pursuit of ever faster release cycles and ever shorter deadlines, developers commonly overlook basic security steps. Invicti research, 2022 AppSec Indicator showed that 45% of DevSecOps professionals skipped crucial security steps in development to accommodate pressures at their workplaces. On top of that, the code review process – which was meant to catch vulnerabilities made before production – is put under greater pressure as it deals with larger workloads and more vulnerabilities. As a result, many vulnerabilities eventually make it to production.

How AppSec Shifted Left

Shift Left arose to combat exactly this problem. Shift Left declares that security controls in development were placed too far “to the right,” towards the end of the process. Their solution was to “Shift Left,” placing those controls further towards the beginning of the development process, thus catching as many bugs and vulnerabilities as early as possible. In pursuit of that understandable goal, Shift Left adherents introduced Static Scanning technologies to the early stages of development with tools like Static Application Security Testing (SAST) and Software Composition Analysis (SCA) to reveal problems as they arose. That said, solutions to one problem often produce issues of their own.

SAST raises costly false alarms

SAST is one of the central technologies of Shift Left and has also become the primary source of Shift Left’s problems.

Above all, SAST is a notorious source of false positives. One recent review of SAST tools on over 3000 open source code repositories found that 91% of its alerts were false positives.

At the most basic level, this wastes time as teams chase alerts which do little to improve security. These may be simple false alarms or real vulnerabilities, but unexploitable – such as an SQL injection in a piece of internal infrastructure which is only exploitable in one rare case. They might also arise from multiple tools which see the same problem but flag them as separate issues, duplicating the work involved in remediation.

However, they arise, they can quickly become a serious problem. These waste the time, energy and focus of otherwise-rushed specialists who need it to focus on actually mitigating AppSec risk, but it also leaves them open to alert fatigue.

Alert fatigue happens when security teams get tired of false alarms from their scanning tools, they start to disbelieve real alerts and miss the true risks. Many will actually just turn off their SAST tools or just ignore them entirely. This might be the largest problem around SAST: that these produce so many alerts that security practitioners no longer know or care what is dangerous and what is not.

Static Scanning obscures real risks

SAST alerts can commonly be confused with real insights about security. The better way to put it is that SAST scans for and flags mistakes in static code. That is a profoundly useful asset to have, but it does not say whether vulnerabilities are exploitable, whether they’re a risk or offer the context that would reveal how they present risk at runtime.

The “Static” part of SAST offers a clue as to its weakness. Attackers are looking for vulnerabilities in running applications, not static code. The reality of modern cyberthreats is that breaches don’t happen from individual vulnerabilities in static code. Modern cybercrime takes a far more dynamic approach to attacks: they’ll probe APIs, exploit implementation oversights, abuse business logic and chain together vulnerabilities to attack targets. Modern threats live in runtime, and that’s exactly the place that SAST does not scan.

A SAST tool will often flag a vulnerability such as a firewall misconfiguration which an attacker can only exploit in rare and improbable circumstances. It is – on paper – a vulnerability – but it is not a direct threat to an organisation. SAST, however, will not distinguish between that and an imminently threatening vulnerability. If teams can’t distinguish between a high-risk vulnerability and an unexploitable one then they’ll likely waste time and expand risk as they fix the low-risk alert, while neglecting the real vulnerability.

SAST can only be used as part of a broader AppSec strategy, and not its main tool. Shift Left’s true mistake is overfocusing on these kinds of scanning, and the 2-dimensional insights they provide.

Regaining visibility into real risks

Shift Left has helped solve one problem, while creating others. Organisations can’t merely get rid of their static scanning tools but rather have to expand their idea of risk mitigation. SAST and other pre-deployment tools struggle with false positives and lack production insight while neglecting runtime environments – where real threats lurk.

We need to move beyond Shift Left and towards Shift Smart. That means concentrating not on the specific stage of development – but on risk across the whole Software Development Life Cycle (SDLC), putting resources where application risk can actually be mitigated. SAST tells us very little about what happens when an application is deployed in real world conditions, and that’s exactly what AppSec programs need to focus on. Instead, testing needs to be a continuous process occurring across the SDLC. Only then, can AppSec teams get the context to know how a running app actually functions and whether a vulnerability is actually exploitable.

Shift Left has served an important purpose but urgently needs replacing. Shifting Smart will free organisations from chasing arbitrary on-paper vulnerabilities and allow organisations to see where risks actually emerge.