supply chain security

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

Read More

A faster way to manage version updates with Dependabot

When the next Log4j lands, you don’t want to find out that you’re several versions behind, and that it’s going to take the team days to fix all of the breaking changes. Dependabot version updates automate the patching process, giving you a measure of protection from unwelcome surprises. But just as with any inbox, the sheer volume of available updates can quickly swell into a management hassle. And given that some types of related dependencies must be updated together–such as with Storybook, Angular, and AWS SDK–it’s all too easy to put off these tasks until it’s too late. Today’s general availability release is all about making it easier to stay on top of version updates and prevent breaking changes. Previously, Dependabot would open individual pull requests for each update, adding overhead to a developer’s workflow and raising the possibility that related dependencies could fall out of sync. Now, you can specify groups of dependencies to update with a single pull request. Grouped version updates confer significant benefits to your development process: simplified dependency management, a reduced risk of breaking changes, and an opportunity to phase out third-party tools and manual workarounds. I’ve been testing the grouped Dependabot updates and just wanted to say it is awesome! Grouping functionality and configuration are exactly what we want.– Nick Gibson, Causeway Capital Management How it works To take control of how Dependabot structures its pull requests, you can define groups of dependencies that will be updated together using groups in dependabot.yml. For example, you can configure groups that update many dependencies at once, or groups that minimize the risk of breaking changes. When you first configure a group, specify a group name that will display in pull request titles and branch names. Then, define other options to include or exclude specific dependencies from the group. dependency-type: specify a dependency type to be included in the group. dependency-type can be development or production. patterns: define strings of characters that match with a dependency name (or multiple dependency names) to include those dependencies in the group. update-type: specify the update type based on semantic versioning (for instance, where 1.2.3 equates to major.minor.patch) to include all updates of the same level in the same group. You can also exclude dependencies from groups to always manage their updates individually: exclude-patterns: define strings of characters that match with a dependency name to exclude them from a group. For these dependencies, Dependabot will continue to raise single pull requests to update the dependency to its latest version. Bear in mind that you can only create groups for version updates. Example 1: Group by dependency-type In this example, “production” and “development” dependencies are grouped together, excluding those that match the pattern “rubocop*”: # `dependabot.yml` file using the `dependency-type` option to group updates # in conjunction with `patterns` and `exclude-patterns`. groups: production-dependencies: dependency-type: “production” development-dependencies: dependency-type: “development” exclude-patterns: – “rubocop*” rubocop: patterns: – “rubocop*” Example 2: Group by patterns In this example, a group named dev-dependencies will update dependencies in the bundler ecosystem at a weekly interval: # `dependabot.yml` file with customized bundler configuration # In this example, the name of the group is `dev-dependencies`, and # only the `patterns` and `exclude-patterns` options are used. version: 2 updates: # Keep bundler dependencies up to date – package-ecosystem: “bundler” directory: “/” schedule: […]

Read More

Introducing auto-triage rules for Dependabot

Since the May beta release of our GitHub-curated Dependabot policies that detect and close false positive alerts, over 250k repositories have manually opted in, with an average improvement of over 1 in 10 alerts. The impact so far: auto-dismissal of millions of alerts that would have otherwise demanded a developer’s attention to manually assess and triage. Starting today, you can create your own custom rules to control how Dependabot auto-dismisses and reopens alerts, so you can focus on the alerts that matter without worrying about the alerts that don’t. Today’s ship—our public beta of custom auto-triage rules—makes that engine available for everyone, so you can specify and delegate specific decision making tasks to Dependabot with your own custom rules. Today’s release is part of a series of ships that make it easier to scale your security strategy, whether you’re an open source maintainer or an application developer on a centralized security team. Custom auto-triage rules for Dependabot are free for public repositories and available as part of GitHub Advanced Security for private repositories. Together with auto-triage presets and a renewed investment in alert metadata, custom auto-triage rules relieve developers from the overhead of alert management tasks so they can focus on creating great code. What are auto-triage rules? Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale. Rules contain criteria that match the targeted alerts, plus the decision that Dependabot will perform on your behalf. What can you do with rules? With auto-triage rules, you can proactively filter out false positives, snooze alerts until patch release, and – as rules apply to both future and current alerts – manage existing alerts in bulk. What behaviors can Dependabot perform? For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. Our first public beta release covers ignore and snooze-until-patch functionality with repository-level rules. We will follow-up soon with support for managing rules at the organization-level. Both are managed via the auto-dismiss alert resolution, which provides visibility into automated decisions, integrates with existing reporting systems and workflows, and ensures that alerts can be reintroduced if alert metadata changes. What alert criteria are supported by custom rules? Custom rules can target alerts based on multiple criteria, including the below attributes as of today. Attribute Description severity Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical. scope Scope of the dependency: development (devDependency) or runtime (production). package-name Packages, listed by package name. cwe CWEs, listed by CWE ID. ecosystem Ecosystems, listed by ecosystem name. manifest Manifest files, listed by manifest path. Who can use this feature? GitHub-curated presets–such as auto-dismissal of false positives–are free for everyone and on all repositories. Custom auto-triage rules are available for free on all public repositories, and available as a feature of GitHub Advanced Security for private repositories. What’s next for Dependabot? In addition to gathering your feedback during the public beta, we’re working to support additional alert metadata and enforcement options to expand the capabilities of custom rules. We’re also working on new configurability options for Dependabot security updates to give you more control over remediation flows. Keep an eye on the GitHub Changelog for more! In the meantime, try out […]

Read More