We have developed a patent-pending technology to detect and prevent SolarWinds-style attacks before shipping binaries to production, in both on-prem and cloud environments.
In order to understand how this new capability works technically, let’s briefly examine how the attack was executed and why it went unnoticed for so long.
In late 2020, a complex supply chain attack against SolarWinds made headlines globally. Malicious code that implemented a back door was injected into the source code during the build process, exposing every SolarWinds customer to a significant threat. Although supply chain attacks are a known concept, this is the first disclosed detection of one at such complexity and vast scale.
Internal and external investigations of the scenario discovered that malware was running on the SolarWinds Orion IT management build environment and waiting for msbuild.exe (the C# compiler) to run. When a build process started, the malware verified that the build target was SolarWinds.Orion.Core.BusinessLayer.dll. If so, it immediately replaced the staged C# files with a version containing the back door’s code before compilation, resulting in malicious code inside. This dll was later digitally-signed, which resulted in the file avoiding significant scrutiny.
Once the build environment is penetrated, there are countless methods to influence the resulting product. While the pipeline’s input is readable (and testable) code, its output is a digitally-signed binary. Comparing them in order to identify a build-level attack wasn’t possible ... until now.
Taking binary code and restoring it to its original source code is a practically impossible task. Compilation is a complex, non-reversible action. A compiled binary is packed with information, optimizations, and metadata that are continuously changing. Even if you take the same source code and compile it again a minute later, the binaries won’t be identical.
In addition to the non-readable binary challenge, the variety of CI/CD tools and approaches is extremely broad. These tools are used differently by every team (where each approach handles dependencies, common code, and additional resources in a unique way). Add to this the fact that the CI/CD pipeline is designed to be invisible to its users and is almost never inspected and you get a huge DevSecOps blind spot.