A CISO’s guide to protecting against modern software threats

How to rebuild trust in the SDLC and the software supply chain

There have been several blog posts, including SunBurst: The next level of Stealth, discussing the technical nature of what is now being called SUNBURST, which shows conclusively that the exploit was built into the source code of an update to the SolarWinds Orion software. The patch was then deployed unsuspectingly by IT teams diligently maintaining the patching cycle intended to avoid these situations. Supply chain attacks are not new, but the level of sophistication and capabilities for damage seen during the attacks on SolarWinds has evolved to a point where all organizations that develop software should take notice.

It will be a while before the details of how attackers gained enough knowledge to directly alter the SolarWinds source code and mirror their development standards to hide the code in plain sight. In the end, the main takeaway is the risk that the applications used to run and protect our businesses are now a threat vector. From both the production and consumption standpoints, we need to be testing our code for more than bugs and be looking for exploits that can disrupt our entire supply chain. Specifically, there are three threat vectors that need to be addressed.

1. Malicious software libraries

Bad actors are creating malicious versions of open-source software packages commonly used in commercial code. In many cases, they rely on typosquatting, which has proven effective since every piece of commercial software uses some form of shared code libraries. We detailed exploits such as Mining for Malicious Ruby Gems and Malicious Python Libraries Discovered on PyPi that show these attacks are not new.

2. Source code manipulation

Having direct access to the source code repository requires more skill and can have a massive payoff if successful. In the case of SUNBURST, the source code was directly modified to include a malicious backdoor, which was compiled, signed, and delivered through the existing software patch management system. The attackers blended in with the affected code base, mimicking the software developers’ coding style and naming standards, creating a compromise of sufficient quality that it did not break the parent program or be noticed during the QA process shows a level of sophistication that is on the rise.

3. Third-party software and patches

The software user or customer is the real target. There’s always been an implicit trust that the software and patches are secure. Organizations have testing protocols to ensure the software patches don’t have bugs and won’t cause disruption. Now that exploits and malware are being inserted directly into the code, companies need to treat all their software as a threat.

The path forward

It’s fair to say source code manipulation will evolve. We should expect to see more evasive techniques to avoid AV detection or execution in a sandbox since it’s generally not executable by itself. This is going to be true for both vendors and internal DevOps teams.

With that in mind, here are the steps you can take today to ensure your applications are secure.

Verify third-party libraries

As engineers consume software components and containers from open source and third-party libraries to build their applications, demands increase to ensure the software’s integrity resulting in added security measures to prevent malicious content from entering the life cycle. There’s a need to scan third-party and open-source libraries, source code, and gold image builds for more than known vulnerabilities and errors.

Scan for code anomalies during QA and before deployment

During the QA and deployment process, effective software security must provide wide-ranging format coverage, with the ability to inspect any kind of content hosted in open-source package repositories and compiled gold images. Going far beyond what a legacy AV system can deliver, the analytical capabilities must look for more than just malware and provide a unified view into software packages, composition, configuration, respective digital signatures, and security mitigations. The analysis must also avoid file size limitations, providing visibility into the inner workings of certificates, URLs and hundreds of embedded files to trust the software is free from tampering. For example, organizations that regularly release applications over one gigabyte in size and with over 600,000 individual files would typically overwhelm legacy scanning tools. With this complexity level in software, CISO’s must counter sophisticated supply chain attacks with more advanced file analysis technology.

You need a platform that accurately detects advanced threats hidden in code repositories through automated static analysis. Having in-depth analysis confirms that all files are inspected for known malware and anomalies in the code’s behaviors. When initially benign code is modified to be malicious, staff can be instantly notified to take action. The net result is increased trust in application security that increases the confidence engineers and DevOps teams have in their code development and deployment processes.

Beware the force multipliers

Software supply chain attacks are becoming more common as bad actors continue to align their coding practices with their victims and leverage vectors with a force multiplier effect. It doesn’t matter if you are a vendor like SolarWinds, an internal DevOps team building applications for internal use, or an end user deploying third-party applications. Mitigating the risks in the software development process is a challenge that needs to be addressed to ensure the software lifecycle is secure and ensure the code can be trusted.

There is a renewed focus on software supply chain attacks that would otherwise be compiled into your code and lay dormant for months while bypassing traditional controls. This slow and patient attack has elevated the supply chain as a priority threat vector that must be protected. The time is now to validate that your software development life cycle and approved software catalog is free of malicious threats and dangerous digital artifacts. ReversingLabs has helped many Fortune 500 companies have confidence in their SDLC process. Our advanced detection of hidden malware within complex binaries keeps digital businesses moving forward with a supply chain CIOs can trust.

Read some of our other Software Supply Chain blogs:

• How Existing Cybersecurity Frameworks Can Curb Supply Chain Attacks
• Why You Need to Prioritize Software Development and Supply Chain Security

And research blogs:

• Mining for Malicious Ruby Gems
• The NPM package that walked away with all your passwords
• SupPy Chain Malware - Detecting malware in package manager repositories