Not Just Third Party Risk

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.

Further Reading:

• Melba Lopez’s 2022 Open Source Summit North America Talk - All about that Bom - Will be updated with link to presentation once it has been uploaded to YouTube
• CNCF Secure Software Factory Reference Architecture
• Google Binary Authorization Whitepaper

*Note: Software Supply Chain Security needs a better name to not just refer to software in supply chains, but all systems, hardware, etc.

‍