Nearly 90% of companies report they have detected a security issue in their software supply chain in the last 12 months. This may come as a surprise to many, but those of us who have worked knee-deep in the software supply chain for a long time have seen it coming.
I say this for two reasons: developers and development teams are directly in the attacker’s bullseye. That’s a place they’ve never been before. That problem has been compounded by my second point: businesses don’t grasp what the practice of software supply chain security entails, nor do they understand what attacks matter and how to defend against them.
Without a formalized plan, security teams have attempted to address a modern issue using old, outdated processes and traditional application security tools. Here’s what this looks like: security teams deploy their in-house software composition analysis (SCA) tools, examine open-source code, and look over their DevOps tooling capabilities. Once these steps are completed, they think they are done. And, back in the day, they were right.
But to tackle a modern problem, we need to look at it through a modern lens. That would mean asking how the steps above deliver the necessary assurances that malware hasn’t been inserted into the final solution somewhere along the way.
Spoiler alert: they can’t. That’s because traditional application security tools like SCA and application security testing (AST), while good at finding vulnerabilities in code, struggle to identify malware or deliberate tampering. In part, that’s because they lack a reputational database containing a library of identified malware, the key to detecting the presence of malware.
Need further validation? Look at the product descriptions for the AST tools that are deployed right now and tell me which include a mention of malware. I’m willing to wager that the answer is “none.” The lack of malware identification in traditional AppSec tools was one of the major takeaways from the ReversingLabs Software Supply Chain Risk Survey. According to the research, 74% of practitioners believe these traditional products are ineffective at protecting companies from supply chain threats.
Think big, validate, repeat!
To combat the software supply chain security problem, teams must stop malware from getting into the supply chain that they are using to create software. This begins by putting away the magnifying glass and think holistically about the product. It doesn’t matter if it’s being deployed in the cloud, a container, or inside a data center.
In addition to looking at the bigger picture, teams also need to stop approaching software supply chain risk as a trust exercise. We can’t make trust a deciding factor in determining whether a deployable package is malware-free, but validation can. Implement package validation and use it on a consistent and repeatable basis that’s integrated into the continuous integration and continuous delivery (CI/CD) pipeline.
To successfully shift to this approach, teams need to shift the way they examine software. Stop the day-to-day practice of examining source code, open-source code, third-party packages, and build systems. It’s time to think big by looking at what the supply chain creates.
Next, evaluate the company’s complete application package on top of examining the individual pieces within it. The most vital part of this process comes at the post-compilation/pre-deployment stage. Here’s where teams review the analysis to match the behaviors the package has been designed to perform with what the program actually does.
Conducting such an evaluation requires development organizations and application security teams to expand their efforts from runtime analysis that shows what the application does functionally, to a reverse engineering process that gives teams the perspective to ask, “Here’s everything this application does. Is this what’s expected?”
Focus on malware
Security teams also need to change their focus from vulnerabilities to malware. Malware can be very difficult to find. If the organization lacks a product capable of monitoring behaviors, the challenge becomes even greater. But, like a great poker player, even the most effective malware has a tell: some behavior that raises a red flag. It could be the inclusion of privilege escalation, or opening port or socket connections. Once identifying one or more of these behaviors, check to see if any are part of the application’s architecture. If not, there’s officially have a malware problem.
Shift to modern software supply chain security
If the organization already has a program in place that can reliably identify all malware in the software the team develops and releases, it’s in great shape. But that’s the minority of organizations. Our research found that 65% of practitioners believe their supply chain security program has fallen behind.
For this group, stop spending all that time in the weeds, exhausting cycles and examining just the individual components of application security. It’s time to take a holistic approach to application security. Next, stop trying to solve a modern-day problem with dated solutions that are simply not up to the task. This isn’t a call to abandon traditional AppSec tools. They still have their place, but they cannot do this on their own.
By taking these steps to expand the scope of the company’s application security and modernizing its toolsets, the team can manage the risks coming from the software the company depends on every day.
Matt Rose, Field CISO, ReversingLabs
