If You’re Only as Strong as Your Allies, Should You Trust Third-Party Code? February 9, 2017 by Magaly Perez Leave a Comment http://www.securityweek.com/if-youre-only-strong-your-allies-should-you-trust-third-party-code As ITAC’s students we know that third-parties are often key components to businesses and organizations to stay competitive amongst each other. However, with partnership can come risk. As we know, the vulnerabilities and threats faced by your third-party system now can become the inherent risk of your organizations. Obviously, this is a newly discovered issued but, the author of this article states, “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”. One might ask, what is the source of these software vulnerabilities? Heinlein’s Razor studies have led him to this understanding, “Never attribute to malice that which can be adequately explained by incompetence, but don’t rule out malice.” The article further explains incompetence, “50% of software vulnerabilities are attributable to flaws from the architecture and design”. Needless to say, unless your third-party pledges to building security into their architecture and design, you can automatically accept that there will be already be inherit flaws in which can be exploited. Subsequently, the article asks its readers to think about these questions: “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”. Those rhetoric questions get you to thinking. The final remark by Heinlein is malice. Your third-parties can code malicious constructs into their code that allows them access your overall application. These insider threats can dodge 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”. To conclude, the article list some potential recommendations and solutions when dealing with third-parties: – Est. 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. “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”.