Software Integrity

 

If you’re only as strong as your allies, should you trust third-party code?

Originally posted on SecurityWeek

Doing business is a highly interactive endeavor and software is increasingly at the heart of those interactions. Agility becomes a key component of staying competitive, so organizations are seeking allies to help them obtain the software they need to stay in the race. Notice I said “obtain” rather than “build” or “code,” because help from one’s allies may come in the form of software components or fully grown application code.

Allies may bring software to the game, but they also bring risk. The vulnerabilities in your allies’ software now become the vulnerabilities of your organization. This is not a new phenomenon—industries have turned to supply chain partners for a variety of business drivers in all sorts of markets and quickly realized they were inheriting risks from their allies. The growing use of open source components in agile and CI/CD environments have simply pushed the software supply chain and the need to trust your allies center stage.

So what is the source of these software vulnerabilities? Heinlein’s Razor tells us, “Never attribute to malice that which can be adequately explained by incompetence, but don’t rule out malice.” A study of software vulnerabilities proves Heinlein to be quite prophetic when it comes to assessing the strengths, weaknesses, and potential risks of your allies.

We will start with incompetence. In his seminal book, Software Security, Dr. Gary McGraw, Cigital CTO, established that 50% of software vulnerabilities are attributable to flaws from the architecture and design. Therefore, unless your ally commits to building security into their architecture and design, you can assume that you will inherit foundational flaws that can be exploited. Only the most mature of your allies will embrace the notion of secure design and perform adequate threat modeling. I suppose we could categorize this more in the realm of ignorance or neglect, but incompetence will cover it nicely.

Got your attention? Good. Now consider your own coding practices. Does your team write bugless code? Have you eliminated the OWASP Top 10 from your software? Your honest answer will be no. So why would you assume that your allies have achieved some form of bug-free coding Nirvana? After all, they are competing against other would-be suppliers in the chain, and are under the same pressures as you. Who has time for security? Suffice it to say you should expect to inherit vulnerabilities from the incompetence of your ally at writing secure code.

Now that we have covered off incompetence, remember Heinlein warns to never rule out malice. Heinlein was a smart man because your allies may in fact be coding malicious constructs into their code that allows them access to the application. These insider threat constructs normally evade detection by standard security testing tools because they do not contain vulnerability markers. The constructs may be a backdoor for malicious access, time bombs, or Trojan Horses. Regardless of the tradecraft, the ally has purposefully coded in a path to exploit.

The insider threat represents real risk because traditional static and dynamic application security tests (SAST and DAST) that lie at the heart of most software security initiatives won’t find these vulnerabilities. Seasoned security experts can find the malicious constructs through source code analysis, but the majority of the code from your allies comes in binary form and you won’t have access to the source code. There are a limited number of tools that can detect insider threat constructs in binary code (full disclosure, Synopsys offers such a tool), but they are not widely deployed. So while open source component analysis is getting all the press, it may be the insider threat that stands to cause the most harm.

So what is the solution? The best place to start is to establish the policies and processes necessary to ensure that your organization takes the steps to reduce the vulnerabilities introduced by the software supply chain. Create policies around open source usage and the testing of third-party applications. Create guidelines that define the gates necessary for software from the software supply chain to make it into production.

You can’t evaluate what you don’t know about, so get your hands around what open source or third-party software you are using.

Continue Reading.

Keep your eyes open for potential risks.