While attacks on software supply chains aren’t new, the intense focus of malicious actors on tampering with trusted applications demands an extension of existing application security programs to identify and address a growing set of indicators of compromise. Minimizing the risk of future supply chain attacks requires us to improve how we assess the integrity of software as we build, release and deploy it. This is exactly what ReversingLabs is doing with our Managed Software Assurance Service. For those who have already invested in application security solutions here are three reasons why you should take notice.
1) It’s static analysis but doesn’t require access to source code or special debug builds to understand software behaviors.
We’ve leveraged our years of malware behavior analysis experience and proprietary techniques to glean detailed behavioral insights from software binaries alone. This means behavioral analysis can happen at several points across your software development lifecycle to identify several types of supply chain risks that have not been easy to spot before now.
The ability to audit behaviors of the final release packages is ideal for looking for suspicious behaviors, software tampering and other indicators of code compromise. Attackers are expending a lot of effort to ensure their changes (such as malicious backdoor code) look like they belong within the code base. Therefore, only by checking for behavior changes across release package versions, or even across multiple builds of the same package version is it possible to catch SunBurst-type supply chain attacks.
Another example is being able to detect malicious intent hiding within packages of third-party libraries and software is important for reducing the risk of attacks such as typosquatting, rogue packages, or malicious software maintainers. Third-party software can be a black box for many application analysis tools, in that without access to the source code their results are often not detailed enough to be useful. This is particularly true when attackers use version updates to introduce or activate malicious behaviors into an initially innocuous package.
Figure1: Behavior audits of release packages are ideal for investigating software tampering
Interactive sample reports are available at https://www.secure.software/
Insights for software architecture decision-making can also be gleaned from behavioral analysis. The larger and more complex the release package the more likely it contains components with a lot more functionality, and asks for more permissions than is needed for the application. By completely uncovering all of the component behaviors, software architects can make more selective choices to not only eliminate potentially untrustworthy behaviors, but also reduce the file footprint - in one case to the tune of 1000+ files.
2) It’s software composition analysis but much much more... way beyond only cataloging open-source licenses
We give security and developers the right info to take action. First, we leverage our in-depth static analysis of binaries to verify whether a component is what it says it is. The idea is to check if the file has been seen before - ideally from a reliable, secured file repository, and signed by the trusted software publisher - giving you confidence that no file tampering has taken place. This verification may sound like an obvious step, however it isn’t something most SCA and application security tools actually do. In a world where software supply chain attacks are being constantly uncovered, a new mantra of software development asserts itself - verify then trust.
Figure 2: Verify then trust your software. Fully interactive sample reports are available at https://www.secure.software/
This validation check also ensures no misleading or missing information about publisher, product, or its version affects any future vulnerability matching. Vulnerability research is a constantly moving target and as new zero-days for older versions of third-party, open-source and internally developed components are uncovered. As such, it is critically important for organizations to quickly get an accurate assessment of the scope of vulnerability risks by knowing with certainty which version of the components are embedded in which applications.
We also match each component and their dependencies to a comprehensive range of malware threats, accidental inclusion of sensitive or private data, ineffective or missing vulnerability mitigations, and indicators of compromise such as certificate impersonation in addition to software vulnerabilities identified by traditional application security testing. To aid remediation and mitigation planning, we both grade the quality of each component and prioritize the issues within based on severity, exploit prevalence, and known malware use.
Getting the matching done correctly depends on the accuracy and completeness of the SBOM component and dependencies. Instead of depending solely on build-server and package manifest lists, we analyze the package itself to determine the software components it actually uses. We look for over 400 file formats that may be embedded within a package to compile a far more complete list of in-house, open source and commercial third-party software components. Our ability to unpack and analyze all those file types enables construction of an accurate component tree of static, dynamic, package, resource and transient dependencies. It also helps us find “silent vulnerabilities” introduced by statically linked package dependencies that cannot be found by simply inspecting the declared manifests or dependency lists.
3) The service includes interpretation of results by some of the top threat researchers in the industry.
This level of knowledge can’t be replicated easily, yet it’s that knowledge transfer from experts to development and application security teams that is critical for tackling new risks and threats. For development organizations that are not used to thinking about security, it’s important to take the time to learn how to interpret their results. Asking questions and discussing different scenarios leads to deeper understanding of why security researchers view particular software behavior patterns as suspicious. In fact, many organizations need to take a “crawl, walk, run” approach to extending their existing application security programs.
Figure 3: Take a “crawl, walk, run” approach to extending application security programs
Start by baselining where you are today and creating an improvement plan, especially when large or complex deployment images are involved. These packages can have hundreds of newly discovered software quality issues or even silent vulnerabilities, thus integrating the first assessment results directly into developer’s IDE would be akin to flooding SOC analysts with too many alerts. Knowing the issues to focus on first helps development teams move the needle in the right direction faster.
Once a comprehensive improvement plan is created and put in motion, we advise development and application security teams through subsequent assessments to track improvements, and assess changes across multiple releases. This also gives the organization the experience to integrate the assessments and results into their devops stack more effectively.
Final Thoughts
Now that you have a better understanding of why our solution improves visibility and auditing of software releases and updates, you can check out some fully interactive sample reports are available at https://www.secure.software/
