Do you trust your software? Why verification matters
To manage risk, you need to trust the software you produce or consume — and that requires verification, provided by modern tools and a holistic approach.
There’s a reason the automotive industry only tests vehicles once they are functionally complete — because it's the only way they can truly trust their product is going to perform as intended. Sure, the teams behind the individual parts that make up a functioning car test the individual components. But before any cars arrive on a dealer's lot, the entire vehicle is crash-tested.
The same should be true for the software industry. What would be considered absurd in the auto industry — performing a crash test on just a single component (the door or the tires or the trunk) — is the norm for software organizations today. Software development organizations deliver their product daily, and sometimes hourly, by focusing on the components of the application — not the entire software lifecycle.
Shifting left, threat modeling, static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA) are critically important — but they focus on the components, giving you an incomplete view of whether consumers should trust of the final application that is set to hit the road.
Trust is critical for organizations today, which rely on software to operate. Here’s why being able to verify all software (whether you’re a producer or consumer), downloads, emails and files is essential to managing risk — and why that requires you to upgrade your tools and approach.
The need for holistic scrutiny of software is a relatively recent development. It took some painful incidents for chief information security officers to awaken to the problem. Most prominent CISOs today typically have 20 to 30 years of experience, having started on the lower rungs of the security ladder and climbed their way to the top.
That means that when these CISOs started in the field, "security" meant network security. That frame of mind colored their approach, which centered on the idea that adversaries could be held at bay by strong perimeter defenses alone. But as the idea of the fortress network began to erode and CISOs were warned about the importance of application security, many of them remained convinced that a stronger firewall was all that was needed. Or maybe that plus closing port 80 or 443 — even though that would essentially shut down the company.
They were told they needed SAST, DAST, and SCA, which focused on traditional vulnerabilities (cross-site scripting, SQL injection, etc.). And there was also a greater concern about the software produced by the organization's developers, using open-source software and other third-party code.
The Sunburst hack — which was behind the SolarWinds attack — changed that thinking in a big way. Attackers inserted malicious code into the company's Orion software, which is used by many government agencies, including the U.S. departments of State, Justice, and Defense, and by many Fortune 500 companies, including FireEye, Microsoft, Cisco, and Intel. The code enabled the threat actors to gain access to the networks of Orion users — and showed that even the most trusted software vendors can be compromised.
The attack, which damaged the reputations of the organizations that were affected, gained the attention of company executives across the world. It also had a significant impact on the global economy, costing businesses billions of dollars in lost productivity and remediation costs. This caused the federal government to take action as well.
For application security teams, Sunburst demonstrated that software supply chain attacks are a serious threat and highlighted the need for organizations to improve their supply chain security practices by shifting their focus from traditional threats to malware, secrets exposure, and tampering.
Before Sunburst, the consequences of inadequate software supply chain security were largely theoretical. Now there are actuarial tables and real events as measures of how bad things can get. It's not a matter of debate anymore.
The Sunburst attack opened the floodgates for software supply chain attacks, including Log4j, CodeCov, Kaseya, OpenSea, Colonial Pipeline, and 3CX. Before Sunburst the consequences of inadequate software supply chain security were largely theoretical. Now there are actuarial tables and real events as measures of how bad things can get. It's not a matter of debate anymore.
The software trust deficit
As someone with 20 years of Fortune 10 global executive security leadership experience at some of the largest software producers and consumers of software, I've seen both sides of software security. I know what can go right and what can go wrong. On the wrong side is believing that component security alone is enough to produce trustworthy software. On the right side is taking a holistic approach to software supply chain security.
Traditional approaches to application security are always going to be needed, much like the testing of individual components on a car. Shifting left, for example, is great. You should be doing software testing as early as it makes sense in the SDLC. It gives you a valuable component view of your software, even if you lose some context in the process.
But approaches such as SAST are useful only when it’s your application, when you have access to source code, and when the only types of vulnerabilities you’re worried about are cross-site scripting, SQL injection, etc. If the source code is not yours, if you don’t have access to it, and if you’re also worried about things such as malware, tampering, malformed signatures, etc., traditional app sec tools won’t help you.
And while DAST tools are a great complement to SAST tools for confirming vulnerabilities, they won't tell you if you have malware, tampering, or malformed signatures. And they won’t tell you anything about any third-party components, whether commercial or open source — or which contain high CVE vulnerabilities. DAST is also limited to web applications, not thick-client applications, binaries, etc. By the time you run DAST tools, your environment may already be compromised, because DAST tools require you to have already installed the application and to observe it at its runtime.
What's needed in the age of sophisticated and persistent software supply chain attacks is a modern approach to application security. Going beyond those traditional approaches is now a requirement to create truly trustworthy software. By implementing a holistic approach to application security, you can analyze a final product — your final, complete package. To do that, you need to be able to analyze thousands of file types and be able to identify potential malicious code, typically from repositories of millions of malware samples.
Through this holistic approach, you'll be able crash-test your application environment — and trust the software running in your organization.
Let's talk trust
ReversingLabs is uniquely positioned to deliver trust for all software. The ReversingLabs Software Supply Chain Security platform goes beyond traditional application security, offering behavioral and differential analysis of complete software packages. The platform is based on the ReversingLabs Titanium platform, the largest file reputation repository in the world, which ReversingLabs has been building for the past 10 years.
Trust is something that should extend to a host of file types across on-premises and the cloud, including files, downloads, e-mails etc. The Titanium platform is the most comprehensive in the industry.
As ReversingLabs’ new Chief Trust Officer, I'd love to meet with you to talk trust. You can also request a free software analysis, showing all threats, risks, vulnerabilities, and malware, with results delivered to you in a comprehensive and prioritized report.
Follow us
Subscribe
Get the best of RL Blog delivered to your in-box weekly. Stay up to date on key trends, analysis and best practices across threat intelligence and software supply chain security.
Topics
Frontier AI agents: Only as safe as their containment
The post-mortems of two compromises by rogue AI agents show that security teams need to focus on guardrails, not the AI model.
