Jim Ivers wrote an interesting post about If You’re Only as Strong as Your Allies, Should You Trust Third-Party Code? that I would like to share.
“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, Cigital 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. For example, there are software composition analysis tools that identify and inventory open source usage. These tools will apply organizational policies and provide licensing data for accounting and legal purposes. They will also identify those open source components that contain known vulnerabilities.
As I mentioned in a previous article called, “Running in Front of the Open Source Parade,” organizations are increasingly using open source components to construct software. In that article, I cite Black Duck Software’s study, “State of Open Source Security in Commercial Applications, 2016,” which states 67 percent of the applications tested in the study had some form of open source component. The same study noted there was an average of 22.5 vulnerabilities identified in the applications that included open source components, and that 40 percent of those vulnerabilities were rated “severe.” So, getting a handle on open source usage is a big first step.
For software developed by your allies, consider some of the available tools that can identify insider threats. Ask your allies about their coding practices and drill into their security policies. A trustworthy ally should be eager to provide you the information needed to address your concerns. Consider it the software version of trust, yet verify.
Allies are a great thing, and today, organizations are extending themselves to more allies than ever to keep pace. As with any business relationship, you should use software or open source components from your allies with your eyes open to the potential risks. Because when it comes to software security, you’re only as strong as your allies.”
_____
Source:
www.securityweek.com
