Software: the world increasingly runs on it, and your business relies on it today. That means if you can’t trust the software that powers your business, you’re in danger. To protect those digital assets in today’s often malignant online world, we can start with the advice of one of the most famous warriors of the ancient world, Chinese General Sun Tzu: Know your enemy.
To defeat malicious hackers, you need to know how they are likely to attack. That advice, along with ways to use that knowledge to defeat enemy hackers, are the focus of the 2022 “Software Vulnerability Snapshot,” a recent report by the Synopsys Cybersecurity Research Center (CyRC). The report analyzes data from almost 4,400 software security tests conducted on 2,700 targeted web or mobile applications, source code files, and systems.
What were the findings of the research?
All of the tests were performed by Synopsys Application Security Testing (AST) services, and most of the tests required truly knowing the enemy—intrusive “black box” and “gray box” tests designed to probe running apps in ways that a real-world attacker would, identify the vulnerabilities, and provide guidance on fixing the vulnerabilities in order of importance.
The tests found plenty of defects—95% of apps had at least one misconfiguration, and 25% of the vulnerabilities found were deemed high risk. That’s good at one level—the point of software security testing is to fix vulnerabilities before hackers can find and exploit them.
But it’s also a warning—the chances are close to 100% that the software your teams are building and/or using has defects, and that a quarter of those defects are the kinds that can cause significant damage. If you don’t address them, you’re asking for trouble. CyRC researchers found that 78% of the targets had vulnerabilities that appear on the Open Web Application Security Project (OWASP) Top 10 list—the most common vulnerabilities found.
Top on that list—vulnerabilities that allow cross-site scripting (XSS)—can let attackers access app resources and data. According to the report, “Synopsys AST services found that 22% of the test targets had exposure to reflected, stored, or DOM (document object model)-based XSS vulnerabilities,” which can enable hackers to inject a malicious payload into a web page.
How can organizations mitigate software risks?
In addition, other critical-risk vulnerabilities, such as remote code execution and SQL injection, allow attackers to execute code on a web application or application server and access sensitive data. So, given all the ways hackers can exploit those weaknesses, how can organizations mitigate them? Synopsys’ comprehensive report offers advice on that as well.
Use all available testing tools—automated and manual
Different tools work in different ways to find weaknesses in software. Organizations should use them all. They include static application security testing (SAST), which helps flag defects in code as it’s being written, and software composition analysis (SCA), which helps developers find open source components, where they came from, what version is being used, and whether they contain any known vulnerabilities or licensing conflicts.
The Synopsys AST team used dynamic application security testing (DAST), mobile application security testing (MAST), and penetration tests—simulated attacks designed to evaluate the security of a system. DAST and MAST are largely done with automated tools that find defects in running code, while penetration testing is done manually and helps organizations find and fix runtime vulnerabilities in the final development stages of software or after deployment.
The research confirms that intrusive black-box testing techniques like DAST and pen testing are particularly effective for exposing exploitable vulnerabilities in the software development lifecycle (SDLC) and should be part of any well-rounded application security testing regimen.
Secure your supply chains with software Bills of Materials (SBOMs)
Software products today are more assembled than written—they include a combination of proprietary, third-party, and open source code. An average of about 77% of every codebase is open source software. And just like any other software, it is imperfect.
Yet too many firms have little to no idea what components are in the software products they’re using or what other components they rely on—a supply chain that can run several levels deep and involve hundreds to thousands of so-called dependencies. That makes it a an attractive attack surface that needs much better protection than it has been getting.
As security experts have said for decades, if you don’t know what you’re using, you can’t protect it. Your firm is vulnerable if you don’t know the versions of all components you use, and/or if the code being used is unsupported or out-of-date. Of course, it’s also important to understand the licenses associated with every piece of open source included in your apps.
That’s one reason why you need SBOMs—an inventory of every software component an organization is using. Software Bills of Materials (SBOMs) ought to be a security and quality fundamental—a vehicle manufacturer wouldn’t stay in business long if it didn’t have a parts list for each vehicle and meticulously keep track of where its parts came from.
If anyone needs a reminder of the risks inherent in the software supply chain, last December’s discovery of a catastrophic vulnerability in the Apache open source logging library Log4j called Log4Shell was an example. One of the reasons it was so catastrophic is that too many users of Log4j didn’t know if they were using a version with the vulnerability.
They weren’t keeping track of their supply chain. A software Bills of Materials (SBOMs) can help mitigate that risk. And it’s another reason SCA tools are so valuable. They help in the creation of software Bills of Materials because they find open source components, what version they are, and whether any of them have known vulnerabilities or licensing conflicts.
As the Software Vulnerability Snapshot report puts it, “with many companies having hundreds of applications or software systems in use, each themselves likely having hundreds to thousands of different third-party and open source components, an accurate, up-to-date software Bills of Materials is urgently needed to effectively track those components.”
The good news is that there is now better awareness of that need than ever before. A recent Synopsys report, “Walking the Line: GitOps and Shift Left Security,” found that 73% of survey respondents had increased their efforts to secure their organizations’ software supply chain.
And President Biden’s May 2021 “Executive Order on Improving the Nation’s Cybersecurity,” explicitly calls for organizations, both public and private, to create and maintain software Bills of Materials for their software products that will be sold to the US federal government.
Don’t let low-risk defects become high-risk
Vulnerabilities labeled low-risk get that ranking either because they are unlikely to cause much damage or because it is unlikely that an attacker could exploit them. The report notes that, depending on a firm’s profile, such a vulnerability could become high-impact/high-likelihood.
One example is the Verbose Server Banners vulnerability that, while considered low-risk, “provides information such as server name, type, and version number that could allow attackers to perform targeted attacks on specific technology stacks.”
Enforce software security policies and Choose the right vendor
Collect and combine data from your security testing tools on what testing was performed and what defects were discovered to drive security improvements in both the SDLC and your governance processes. In addition, choose a vendor that can develop a comprehensive risk posture report for your executives and for regulatory/compliance purposes.
Girish Janardhanudu is the Vice President at Synopsys Software Integrity Group.
