Kusari's Software Supply Chain Security Overview

So there’s Network Security, Application Security, Hardware Security, End Point Security, and a bunch of other categories of security. Now we have to add in Software Supply Chain security as well? What is this new thing I need to care about, and why should I care about it separately from just Cybersecurity?

These are common questions posed to us from every level of the enterprise from software engineers to engineering managers up through the C-suite. Most folks have enough on their plate already and adding another buzzword around cybersecurity isn’t making anyone more secure. This can all seem overwhelming, especially with the flurry of tools, frameworks, and services out there with “Supply Chain Security” associated. We founded Kusari because we’ve been in your shoes. We can help.

You ask a dozen people what software supply chain security is and they’ll give you a dozen different answers. These answers will range from it just being a synonym for Third Party Risk Management (TPRM) or Open Source Security. Some folks will conflate software supply chain security with Software Composition Analysis (SCA). This article will clear up some of the confusion and misconceptions folks have about Software Supply Chain Security.

Software supply chain security is the name that has stuck for what is System Delivery Lifecycle, or Software Development Lifecycle (SDLC) Security. At Kusari we don’t look at security in a vacuum, so many of these previous definitions are good but not complete. We believe in applying a holistic approach to security from software engineering planning through to eventual runtime security in production. You need to have that traceability from development through to production operation, not just for protecting against tampering throughout the SDLC, but for analysis and audit later down the line.

The simplified SDLC interaction diagram outlined above helps us understand what we’re trying to protect. A simplified pattern for development looks something like this:

1. A Software Engineer downloads development tools and dependencies like IDEs, compilers, and third-party libraries proxied through an internally run Artifact Repository to their Workstation. They also download internally built tools and dependencies stored in the Artifact Repository.
2. They write code and test it out in Development Environments while also installing dependencies and tools they need in their Development Environments.
3. They commit and push to Source Control
4. The Build System pulls source code from Source Control. It pulls down build tools and dependencies from the Artifact Repository.
5. The Build System then builds and packages the code into software and publishes it to the Artifact Repository
6. Finally some process, either manual or automated will deploy this build software to Production Environments by downloading from the Artifact Repository directly to the Production Environment or pushing from a deployment system.

This flow ignores various processes and systems like Quality Assurance (QA), Authorization to Operate (ATO), and Continuous Deployment (CD), to keep it simple for this overview.

From this flow, we can already see a bunch of key areas we want to protect.

• Developer
• Workstation
• Development Environments
• Source Control
• Build System
• Artifact Repository
• Production Environments

There are a lot of reasons why one would want to protect the people, systems, and processes in this flow, but we’re going to look at the Software Supply Chain Security aspects. The critical characteristic of Software Supply Chain attacks and vulnerabilities is:

A compromise or vulnerability at one part of the supply chain potentially introduces a compromise or vulnerability to every component down the chain.

This means that a vulnerable library can compromise any downstream software that uses it. It also means that any compromised system involved in the SDLC can have cascading effects on anything downstream from that system. Let’s look at the log4shell vulnerability from 2021. Not everything that used a vulnerable version of log4j could easily be compromised or attacked but it still led to massive audits of supply chains in an attempt to discover what might be vulnerable and where it lived. Similarly, if we look at the SolarWinds SUNBURST attack that was discovered in 2020, a compromise against the build systems led to potentially all software being built by that system being compromised.

Now we can take a look at how this all begins to get solved.

The above diagram illustrates our high-level view of the breadth of supply chain security. Future blogs from us will go more in-depth into the various pillars highlighted here, how you can approach thinking about these problems, and how Kusari is helping solve these problems through the solutions we are building today. However, let’s take a quick overview of the segments in this document.

From left to right we have the core SDLC security functions:

• Endpoint Protection - This is providing security controls around Workstations.
• This protects against attacks against a Software Engineer, from a malicious Software Engineer or compromises of the Workstation.
• Secure Ingestion - This provides security rules around what software and dependencies can be pulled in externally.
• This protects against attacks on all the systems that use the third-party software, in other words, all the systems.
• Secure Dev - This provides security rules around isolated and ephemeral Development Environments.
• This protects against attacks on Development Environments from crossing security boundaries into other systems like Workstations, Build Systems, etc.
• Secure Software Factory - This is a secure build system that enforces strict practices around what is allowed to build, how things are built, and how things are published.
• This protects systems downstream from the build system like the Production Environment from running software that was compromised by the build process.
• Software Authorization - This is the process and systems that control gating around what is allowed to operate in Production Environments as well as continuously enforcing runtime policy.
• This protects privileged environments like the Production Environments from running software that hasn’t gone through the other pieces of the Secure SDLC.

The above functions are wrapped up by governance functions:

• System Delivery Lifecycle Control Plane - This is the process and tooling that provides consistent security rules and automation around the other SDLC functions like Secure Dev, Endpoint Protection, etc.
• Supply Chain Knowledge Graph - This is the datastore that ingests security metadata, documents, and attestations from the System Delivery Lifecycle Control Plane as well as documents externally, e.g. SLSA attestations and SBOMs for third-party dependencies.

The System Delivery Lifecycle Control Plane pulls or receives security attestations and metadata from the various other systems that make up the secure SDLC, and feeds them into the Supply Chain Knowledge Graph. That updated Supply Chain Knowledge Graph feeds back into the System Delivery Lifecycle Control Plane for governance and automated policy to orchestrate and manage the systems that make up the Secure SDLC.

We also believe that securing the SDLC and achieving supply chain security is only possible through modern techniques like zero trust. In followups to this blog, we’ll learn how we can apply zero trust to the concepts here to better secure the Software Supply Chain, as well as how tools and software that Kusari is building and helping build like GUAC can meet many of the functional requirements required to secure the Software Supply Chain.

This is a lot to take in, and it might seem a bit overwhelming. We’ve been there. The best thing you can do today is pick a facet of your security posture that needs improvement and begin to follow open standards, frameworks, and best practices that can improve your security. Some examples are SLSA for securing elements of the build or CNCF SSCP for general cloud native supply chain security. Regardless of where you are in your Software Supply Chain Security journey, Kusari would love to hear about your challenges.

‍