HowTo: Protect Software by Understanding Your Environment

Written by

Software is the foundation of almost all modern businesses. Unfortunately, it’s also a favorite target for cyber-criminals. Securing software is essential for bolstering an organization’s cybersecurity, and understanding how attackers attack them is a key component of that. Fortunately, resources are available to help your organization better understand your software, how attackers attack it, and what you can do to protect it.

The Synopsys Cybersecurity Research Centres’ (CyRC) 2022 Software Vulnerability Snapshot revealed that 95% of applications had at least one vulnerability or misconfiguration, with 25% of those vulnerabilities classified as high or critical risk.

While those vulnerabilities were found and remediated, we should take these findings as a warning. Almost all the software built or used in your organization has defects, with a quarter of them able to cause serious damage. They cannot be ignored.

The CyRC report revealed that 78% of its targets had vulnerabilities appearing on the Open Web Application Security Project (OWASP) Top 10 list – some of the most common vulnerabilities out there. Topping that list are vulnerabilities that allow cross-site scripting (XSS), which can grant attackers access to application 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. 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.

But knowing how hackers can exploit these weaknesses is not enough. Organizations must understand how to mitigate and remediate them.

Use Both Automatic and Manual Testing Tools 

Using all the testing tools at your disposal is essential. Different tools work in different ways, meaning weaknesses missed by one tool could be identified by another. The most important of these are static application security testing (SAST) and software composition analysis (SCA). SAST helps identify code defects in the development stage, whereas SCA supports developers in discovering source components, where they came from, what version is being used and whether they contain any known vulnerabilities or licensing conflicts.

Also important is dynamic application security testing (DAST), and mobile application security testing (MAST), which are largely carried out with automated tools to find defects in running code. Organizations should also run a penetration test. These are simulated attacks designed to evaluate the security of an application or system, carried out manually to help organizations find and fix runtime vulnerabilities in the final development stages of software or after deployment.

Intrusive, “black-box” testing techniques such as DAST or pen testing are especially useful for discovering exploitable vulnerabilities in the software development lifecycle (SDLC) and are an essential part of any complete application security testing procedure.

Utilize SBOMs to Secure Your Supply Chains

Contrary to popular belief, software products are more assembled than written, combining proprietary, third-party and open-source code. On average, around 77% of every codebase is open-source software. Despite being imperfect – as all software is – too many organizations have next to no idea what components are in their software products or what other components they rely on. Considering the scale of modern supply chains, this makes them an enormous and irresistible attack surface.

If you’re not acquainted with all the versions of all the components you use, and/or if the code is unsupported or out-of-date, your organization is inherently vulnerable. Understanding the licences associated with every piece of open source included in your organization’s applications is essential.

SBOMs provide an inventory of every software component an organization is using. Inventories are essential for any organization – why wouldn’t the same be true for cybersecurity? SBOMs should be a security and quality fundamental.

Think back to the Log4Shell incident. The scale of the disaster was compounded because too many users of Log4j didn’t know they were using a version with the vulnerability. This was because they weren’t keeping track of their supply chain. An SBOM can help prevent that.

This is another reason why SCA tools are so valuable – they help create SBOMs by identifying open-source components, what version they are, and whether any of them have known vulnerabilities or licensing conflicts.

Don’t Ignore Low-Risk Defects

Low-risk vulnerabilities are often neglected, but it’s important to remember their classification can change. Depending on the profile of an organization, low-risk vulnerabilities could very well become high-risk. 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.”

Create and Enforce Software Security Policies

It’s important that you use the data your security testing tools provide. Collect and combine all data on what testing was performed and what defects were discovered to drive security improvements in both the SDLC and your governance processes.

Choose Vendors Wisely 

Only work with vendors that can develop a comprehensive risk posture report for your executives and regulatory/compliance purposes.

What’s hot on Infosecurity Magazine?