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 […]
