How SolarWinds busted up our assumptions about code signing

As the fallout from the SolarWinds hack broadens, we continue to learn more about just how it happened in the first place. There have now been four malware strains identified, one being Sunspot, which was installed on the SolarWinds build server that developers use to piece together software applications.

When it comes to software supply chains, code signing is a commonly used practice to indicate the provenance of software. In theory, the process validates the authenticity and integrity of the code. But as we all now know, that isn’t always the case.

As it turns out, code signing is the very last step in what is often a convoluted process to get from original source code to finalized packaged software. An attacker that can inject changes into a software build pipeline or continuous integration (CI) process — as was the case with SolarWinds — will be able to make changes that are included in the signed final product, altogether defeating the purpose of the signature.

Many software vendors may not have thought to take great care in securing their software release pipeline, but these recent attacks have more and more taking a deep look at how they can do that effectively. They need a system to certify that every step from source code to software has been executed correctly.

The Real Problem With Code Signing: Assuming It’s Fool-Proof
The process of code signing isn’t inherently bad. The problem is that it can (and often does) give people a false sense of security. The whole idea behind code signing is that it verifies that the code itself hasn’t been modified by anyone who doesn’t have the proper access.

A lot of the process is typically automated, and people don’t usually double-check things when it’s all set up — it’s just supposed to work. That’s when vulnerability and downright danger can strike.

If a cybercriminal or anyone else with malicious intent is able to make a change before code signing takes place, everything can seem to be working perfectly and no one will dive deep because everything is expected to function. In other words, code signing is designed to verify the software supply chain is legit, but if you’re signing something that’s already wrong or has been tampered with, it doesn’t matter.

To read the complete article, visit Dark Reading.