Software/Scripts 3 strategies to expand your threat model and secure your supply chain

[Git]

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

You do not have permission to view link please Вход or Регистрация

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

You do not have permission to view link please Вход or Регистрация

. 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

You do not have permission to view link please Вход or Регистрация

or require

You do not have permission to view link please Вход or Регистрация

. 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,

You do not have permission to view link please Вход or Регистрация

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.


Interested in setting up 2FA at your organization?

You do not have permission to view link please Вход or Регистрация

.


The post

You do not have permission to view link please Вход or Регистрация

appeared first on

You do not have permission to view link please Вход or Регистрация

.

 

[AI G]

Supply chain security has become a critical topic in recent years, and it's important for engineering and security leaders to have a comprehensive understanding of it. In this article, GitHub's Chief Security Officer and SVP of Engineering shares three strategies to expand your threat model and secure your supply chain.

Strategy #1: Understand and account for your build pipelines

The SolarWinds incident highlighted the importance of securing build systems, which are essentially production systems. It's crucial to treat them with the same level of rigor as your most sensitive operations. Start by understanding the sprawl of your build systems and identify all the inputs that go into the software artifacts you produce. Implement controls to protect these systems and ensure their integrity.

Strategy #2: Require users to use 2FA

Basic security hygiene is still a challenge in the industry, and adopting two-factor authentication (2FA) is a fundamental step towards securing the supply chain. GitHub has made 2FA mandatory for all code contributors on GitHub.com and requires it for high-impact package maintainers on the npm registry. By ensuring that accounts are protected from theft or takeover, the risk of open source ecosystem attacks is significantly reduced. Implement 2FA wherever possible to enhance security and mitigate unauthorized access.

Strategy #3: Build and consume artifact provenance

Knowing the origin of the packages you use is crucial for supply chain security. GitHub has partnered with the Sigstore project to bring provenance to npm, allowing package maintainers to generate signed statements about the software's origin and build process. This enables developers to make verifiable claims about their packages, giving consumers the ability to make informed decisions about the packages they use. If you maintain npm packages, incorporate provenance into your build process, and if you consume npm packages, use provenance to verify their authenticity.

In conclusion, securing the supply chain is a collective responsibility, and by implementing these strategies, you can expand your threat model and improve the security of your supply chain. It's important to understand your build systems, implement 2FA, and ensure the integrity of your third-party dependencies. By prioritizing supply chain security, you contribute to maintaining the integrity of the open-source code and third-party dependencies that we all rely on.