As software development continues to swiftly advance — and grow more complex in terms of dependencies, with faster code releases in the age of continuous integration/continuous development (CI/CD) — application security (AppSec) practices and tooling are struggling to keep up.
Attackers have moved swiftly as well, adjusting targeting these changes in development patterns to leverage the scale of attacks afforded to them by cloud-native development and the interconnected reusability of components in the modern software supply chain.
Attacks like Sunburst, which was behind the SolarWinds compromise, and last year's MOVEIt, attest to how easy it has become for them 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, the reality is that it's not evolving fast enough. Today's software development practices and toolchain 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 five essential changes needed.
[ Learn more: Tools gap leaves orgs exposed: Why you need to upgrade your AppSec | Get report: Software Supply Chain Security Risk Report ]
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 to DevOps. Then DevOps refines itself with cloud-native principles and rampant reuse of components through microservices. And throughout it all new, popular programming languages keep 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 software ecosystem — all while keeping most of the old attack methods in play for as long as they could.
And so AppSec pros are called to leap into new tooling while still carrying all the old stuff on their backs as they make every new jump. The industry started with the generic web application scanners of the old SPI Dynamics days, which then bifurcated into the staple duo of static application security testing (SAST) and dynamic application security testing (DAST). From there interactive application security testing (IAST) evolved to fill in the gaps left by SAST/DAST, and layered on top came software composition analysis (SCA).
However, that bevy of legacy AppSec tools leaves companies managing a mashup of AppSec 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 is what has gotten so many industry pundits on-board for making systemic changes. Last year, the Cybersecurity and Infrastructure Security Agency (CISA) introduced Secure By Design and the Cybersecurity Framework 2.0 with a focus on software supply chain security, which foreshadows the future of AppSec. The analyst firm Gartner's 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 fundamental 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's alarms going off everywhere."
—Matt Rose
With companies facing increasing risk for software supply chain attacks, big changes are need to evolve your AppSec approach so that it can actually keep up with software engineering — and attacker adaptations. Here's what experts say needs to happen.
1. Software supply chain security demands transparency
As organizations focus on building and using tools like software bills of materials (SBOM) more thoroughly, the industry is going to have to elevate what it means for SBOMs to be truly comprehensive. Currently there's a hyperfocus on gaining transparency into the open source dependency chain, while ignoring the elephant in the room: 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 CISO at ExxonMobile.
"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
If organizations are going to truly get a bead on their AppSec risk across the supply chain, if they're going to use SBOMs to remediate or at least mitigate risk preemptively, and if they are going to use them to effectively respond to incidents, Zdjelar said comprehensive transparency of dependencies was essential.
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 whole 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, it's 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 also can't be done all at once—in fact, some of it may be low priority enough to not be done at all. That's why in 2024 a lot of the emphasis is going to be about elevating how tooling can signal prioritized action and how things can be better automated. The goal is making AppSec more efficient without losing the insights from the tools we've kept adding over the years.
John Funge, Managing Director of the security venture capital firm DataTribe, said the big shift in the age of supply chain attacks 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 re-oriented to elevate security to the same level as user experience, performance, and reliability in the minds of product development teams."
—John Funge
Funge said the company founders he's been working with are seeing opportunities to build up capabilities that make it easier on 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 even takes 10 minutes or a day to do something, let's say it's a day, you're already behind."
—Matt Rose
4. Software packages needs a final exam
These days, AppSec threat mitigation is no longer about finding and fixing vulnerabilities. It's more about catching malware that has snuck 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 why attackers are finding it so easy to slip these 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 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.
Article Link: The evolution of AppSec: 4 key changes required for a new era