3 strategies to expand your threat model and secure your supply chain

As GitHub’s Chief Security Officer and SVP of Engineering, one of the most common discussions I have with other engineering and security leaders is the state of supply chain security. We all know it’s been an interesting few years, and supply chain security has rocketed into the mainstream—but where should one start when it comes to securing the supply chain? There are many acronyms and security “solutions” out there. How can teams get the bigger security picture?

I recently talked about this problem at the BlackHat CISO Summit and want to share a few prompts you can discuss with your teams and customers to broaden your perspective on supply chain security. These prompts can help open up your aperture for thinking about the breadth and complexity of supply chain security while realizing some quick wins that you can do today—without any extra tooling or purchases.

Strategy #1: Understand and account for your build pipelines

The SolarWinds incident was a watershed moment that woke the world up to the threat of supply chain attacks. It involved a sophisticated attack on various organizations and government agencies by exploiting vulnerabilities in SolarWinds’ Orion platform, a widely used network management software suite.

This incident showed us that the pipelines we use to produce software applications are just as important to secure as the application code itself.

Build systems are production systems, period. They are extensions of your production environment and must be protected with the same level of rigor as you protect your most sensitive operations. The problem is that many organizations don’t know the sprawl of their build systems and don’t treat the ones they know about as production systems.

Ask yourself: what controls do you have in place for all your code and artifact systems? How many build systems do you have? How many tech stacks do you use? As we saw with SolarWinds, we need to understand exactly what inputs are coming into the software artifacts we’re producing and account for them in the build process.

Strategy #2: Require users to use 2FA

As an industry, we still need help with basic security hygiene and controls, like adopting 2FA. At GitHub, security starts with the developer, and as such, we now require 2FA for all code contributors on GitHub.com. Empowering developers to prevent open source ecosystem attacks by better securing their accounts from theft or takeover is one of the most critical steps we can take to secure the supply chain.

We made this decision after rolling out the npm registry for high-impact package maintainers. By requiring 2FA on the accounts of code contributors, maintainers, and publishers, we’re working to address one of the top, long-standing security threats: phishing. While parts of the security industry love to focus on more exotic threats and more complex capabilities, the reality is we need to start with the basics.

With 2FA, GitHub dramatically reduces the likelihood of account takeover of popular package maintainers on npm and GitHub.com contributors—and by extension, mitigates the risk to other developers who depend on that code.

You should be using 2FA everywhere you can. We have resources that can help you easily set up 2FA for your account or require 2FA for your organization. This simple step will go a long way in preventing your accounts from being compromised by unauthorized users while maintaining a seamless user experience.

Strategy #3: Build and consume artifact provenance

Do you know where the packages you pick up and use are from? Just like you wouldn’t pick up a random flash drive you found on the street and plug it into your laptop, you shouldn’t pick up random open source packages, either.

Last year, GitHub partnered with the Sigstore project to bring provenance to npm, which helps solve this issue. Now, package maintainers can easily generate signed statements about where the software came from and how it was built. This helps developers make statements about the packages they publish and allows consumers to make their own judgments. Sigstore has seen excellent community adoption, and we think this will be extremely helpful in improving package security. So, if you are maintaining npm packages, build them with provenance. If you’re consuming npm packages, use provenance to verify them.

The bottom line

Supply chain security is a unique challenge, and I think we’re still in the early days of helping people to better understand the true depth of the supply chain ecosystem. But we need to focus on the forest, not the trees—and ruthlessly prioritize how we can all do our part to secure the broader ecosystem to maintain the integrity of the open source code and third-party dependencies we all use. To recap, some ways you and your team can start thinking bigger about the problems in this space are:

Do you understand your build systems?

Start by simply making a list of all of them.

Are you using 2FA? Do you require users to use 2FA?

If not, this is a simple tool you can implement to prevent your accounts from being compromised by unauthorized users.

Do you trust the third-party dependencies you use?

Understand how the places you get your dependencies from are secured and make a list of all the packages you have.

Have you taken full stock of your third-party integrations to ensure they meet your own security standards?

Look at all the integrations you have wired to your GitHub org and give them only the minimum amount of access needed to complete the task.

Supply chain security is a collective responsibility of all of us who contribute and consume software dependencies. By taking these and other concrete steps, you can easily expand your threat model to improve the security of your supply chain.