Evolution of AppSec: 4 requirements for the software supply chain security era

Software development continues to swiftly advance and also to entail more complex dependencies, with continuous integration/continuous development (CI/CD) bringing faster code releases. Meanwhile, application security (AppSec) is struggling to keep up with its practices and tooling.

Ahead of both development and AppSec, however, are attackers, who have adjusted to the changes in development patterns. Both the scale of attacks afforded attackers by cloud-native development and the interconnected reusability of components in the modern software supply chain have been a boon for them.

Attacks such as Sunburst, which was behind the SolarWinds compromise, and last year's MOVEIt attest to how easy it has become for attackers to cut through tens of thousands of targets at once with a precise blow against a weak link in the software supply chain.

Even though AppSec has evolved in recent years, it's not changing fast enough. Today's software development practices and tool chain remain woefully unprotected from attacks, and legacy AppSec tools and practices are failing the teams charged with securing their releases or managing risk in their organizations.

In 2024, AppSec must make a giant leap forward to modern practices and tooling in order to tackle the new era of software supply chain attacks. Here are the four essential changes needed.

Learn more with our Essential Guide: Software Supply Chain Security for Dummies

A brief history of AppSec

For the better part of 20 years, the world of AppSec has been locked into an evolutionary game of innovation leapfrog. Every time a new iteration of application scanning or testing comes along, the development world changes. Waterfall shifted to agile, agile morphed into DevOps, and DevOps refined itself with cloud-native principles and rampant reuse of components through microservices. And throughout it all, new programming languages kept growing in popularity, further adding complexity to the task of examining code, configurations, and overall security of applications.

Attackers adjusted quickly, picking apart new weaknesses and coming up with stealthier attack methods against the software ecosystem, while keeping most of their old attack methods in play for as long as they could.

That means AppSec pros must leap into new tooling while carrying all the old tooling and practices. The industry started with generic web application scanners such as those from SPI Dynamics, and those later bifurcated into the staple duo of static application security testing (SAST) and dynamic application security testing (DAST). From there interactive application security testing (IAST) came to fill in the gaps left by SAST/DAST, and layered on top came software composition analysis (SCA).

In short, AppSec has to manage a mashup of legacy tools. "This has created so much tool sprawl in the industry," said Matt Rose, field CISO for ReversingLabs.

In the AppSec testing market, all the solutions that are out there are always chasing the changes in the way software is being developed. And if you're in the industry long enough, you see that one of the biggest things that drives any AppSec tooling — whether SAST, DAST, or IAST — is, 'What languages can it scan?

Matt Rose

A call to action on AppSec tooling and practices

This overload for AppSec teams has led many involved in the industry to call for systemic changes. On the government side, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) last year introduced Secure by Design and the Cybersecurity Framework 2.0, with a focus on software supply chain security. The analyst firm Gartner is also on board, with its latest guidance pushing for software supply chain security and third-party risk management to be better merged within the greater cybersecurity strategic framework.

In order to support these changes, organizations need new tooling. Companies require comprehensive software supply chain security, including complex binary analysis. However, Rose said that while tools that provide comprehensive software supply chain security are essential, companies cannot get rid of their legacy tools overnight.

People are struggling with just reams of data, and they're releasing software faster and faster and faster. So it's like every time you do a scan, if you integrate it into your build, you just have more information than you can process. So now you know your house is on fire, but you don't know which room it is. It's like all the rooms are on fire at once. There are alarms going off everywhere.

Matt Rose

With companies facing increasing risk for software supply chain attacks, you need to evolve your AppSec approach so that it can keep up with software engineering — and attacker adaptations. Here are four things that experts say need to happen.

1. Software supply chain security demands transparency

As organizations move to building and using software bills of materials (SBOM) more thoroughly, the industry is going to have to decide how to make SBOMs truly comprehensive. Currently, gaining transparency into the open-source dependency chain has received hyperfocus, at the expense of the bigger problem: the composition and dependencies within commercial software. This was one of the big points made in the Gartner report, said Saša Zdjelar, chief trust officer at ReversingLabs and a former chief information security officer at ExxonMobil.

As an industry, we're struggling with the definition of 'comprehensive.' In my world, comprehensive means 'everything, with no excuses.' But a lot of companies who say, 'We do SBOM,' define 'comprehensive' as, 'As long as it's only open source, and as long as it's only one of these seven file types, and as long as it's less than 65 megs size, then we're comprehensive.'

Saša Zdjelar

Zdjelar said that comprehensive transparency of dependencies is essential if organizations are going to truly address their AppSec risk across the supply chain and use SBOMs to remediate or at least mitigate risk preemptively and to effectively respond to incidents.

2. AppSec pros must conduct practices like a symphony

The evolution of AppSec tooling thus far means that practitioners are going to have to become a lot better at integration, tools orchestration, and delegation, said Rose.

Successful AppSec people think of their roles as like being the conductor of a symphony. I think the most effective way to do it is doing identification at the CI orchestration layer and then remediation based on the expertise layer.

Matt Rose

3. Prioritized action and automation are key

All of that delegation and orchestration of identification and remediation can't be done manually, and it can't be done all at once — in fact, some of it may be of a low enough priority to not be done at all. And prioritization will be key in 2024, with an emphasis on elevating how tooling can signal prioritized action and on improving automation so that priorities are met. The goal is making AppSec more efficient without losing the insights from the tools it has added over the years.

John Funge, managing director of the security venture capital firm DataTribe, said that in the age of supply chain attacks, AppSec must go beyond "shift left."

There is a growing movement behind the idea that digital products need to be built more securely in the first place, that is, Secure by Design. It’s more than 'shifting left.' Rather, it’s a realization that the entire software development lifecycle needs to be reoriented to elevate security to the same level as user experience, performance, and reliability in the minds of product development teams.

John Funge

Funge said that the company founders he's been working with are seeing opportunities to build up capabilities that make things easier for security teams and the developers they work with.

We are seeing an increased emphasis on helping teams to identify not just vulnerabilities in libraries they use, but also how impactful each particular vulnerability will be depending on the context of how that specific system uses the library. There is a movement afoot to fuse static and dynamic application testing principles to deliver better results and greater efficiency.

John Funge

Rose said integration and automation will be crucial to dealing with AppSec, given the speed of DevOps pipelines today.

People are releasing sometimes thousands of times a day with microservices architecture. It has to be automated. If it's manual and it takes a day to do something, ... you're already behind.

Matt Rose

4. Software packages need a final exam

AppSec threat mitigation is no longer primarily about finding and fixing vulnerabilities. It's more about catching malware that has sneaked its way into the software supply chain. Henrik Plate, security researcher for Endor Labs, said to expect to see a whole lot more of that in 2024.

In the past few years, registries like PyPI, npm, or Rubygems.org were the primary focus of attackers, but the deployment of malicious packages using techniques like typosquatting has already extended to other component registries or marketplaces, and this trend will continue. Attackers will refine obfuscation and evasion techniques and continue to conduct bigger malware campaigns, with hundreds or thousands of malicious software packages deployed in short time frames, because running such campaigns is relatively cheap.

Henrik Plate

One of the reasons attackers are finding it easy to slip malicious packages into software is that organizations have been so focused on shifting left — doing their testing early in the release cycle — that they're forgetting that checks need to happen before software releases, Rose said.

We have to be diligent and shift security everywhere. We especially need a 'final exam' to check for potential risk or compromise before each release.

Matt Rose

These last checks need to be built into the development workflow to look for malware injections, tampering and other problems like secrets leaks or other identity problems.

Comprehensive supply chain security is now a requirement

When it comes to managing risk across the software development lifecycle (SDLC), Rose said modern tooling that can deliver such a final exam is key, citing the Enduring Security Framework group's call to for binary analysis and reproducible builds to manage risk.

Complex binary analysis, which focuses on malware, can help organizations evaluate and verify the security of not just internally developed software, but also third-party commercial software in their environment, before it is released, Rose said.