Not Just Third Party Risk

There’s a misconception in Cybersecurity among some that Software Supply Chain Security is just Third Party Risk Mana...

Michael Lieberman

July 20, 2022

There’s a misconception in Cybersecurity among some that Software* Supply Chain Security is just Third Party Risk Management (TPRM). There’s another misconception that it’s just the continuous integration (CI) or build pipeline or some combination of TPRM and pipeline. TPRM and the build pipeline are both important facets of Software Supply Chain Security, but are just two pieces of a bigger puzzle. It is very easy to just assume that most of the issues in our supply chain come from factors external to our project or organization. “It’s not my code that is bad, it’s some upstream vendor or open source code that is the real issue.” Software Supply Chain Security is security applied to your holistic System Delivery Lifecycle. This includes applying security to the people and process in your SDLC as well as the technology systems that facilitate the SDLC. In addition you need to apply rules and policies around what you pull into your SDLC and distribute downstream to your consumers. There are multiple internal actors operating within the SDLC that include a lot of people you might not normally consider part of your SDLC like:

Lawyers - For licensing and legal issues
Budget - For approving use of funds for procurement of software and hardware
Procurement - For actually purchasing the software and hardware
Compliance - Ensuring that systems development and delivery abide by internal policy as well as external regulations

This is in addition to actors commonly thought to be involved in the SDLC like:

Software, System, Site Reliability, Security Engineers
Engineering Managers
Systems and Software Architects
Project Managers
Product Managers

These actors interact with each other implementing the processes by which software goes from an initial idea, through to product design, technical architecture, software development, and eventually delivery. They are enabled through the use of various technical systems that both provide features allowing for software development and delivery in the first place as well as lots of glue systems that make the process more efficient, repeatable, and secure.

The above simplified SDLC example you might imagine for a large regulated enterprise, shows just a few of the tasks involved in the delivery of technology. Any of these tasks can be attacked, or when security is not considered, can impact the overall supply chain security of whatever is being delivered whether it’s software, hardware, configuration as code, software as a service or anything else. If during Project Planning security is not made a priority it can have second and third-order consequences down the line when considering security for the Technical Enginering during implementation. How many simple security vulnerabilities like a SQL injection vulnerability slip through the cracks, not because of some complex engineering problems, but just because security wasn’t a priority.

As we approach securing our supply chains we can’t just think about third parties nor can we even just consider the hands on keyboard engineering involved in developing our software. Establishing trust models for TPRM, creating a Secure Software Factory for your build, and enforcing Binary Authorization might be three of the most important technical challenges you will face, however these are not the only challenges when securing your SDLC.