security-and-compliance

Subscribe to all “security-and-compliance” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

GitHub Advanced Security customers that have validity checks enabled for secret scanning will see the validation status for the following Discord tokens:

  • discord_api_token_v2
  • discord_bot_token

View our supported secrets documentation to keep up to date as we expand validation support.

See more

GitHub secret scanning protects users by searching repositories for known types of secrets such as tokens and private keys. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with MaxMind to scan for their license keys and help secure our mutual users on public repositories. MaxMind keys allow users to run queries against minFraud®, GeoIP®, and GeoLite services, and download GeoIP and GeoLite databases. GitHub will forward license keys found in public repositories to MaxMind, who will then email the user about the leaked key. You can read more information about MaxMind keys here.

All users can scan for and block MaxMind keys from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block MaxMind keys in their private repositories.

Learn more about secret scanning
Partner with GitHub on secret scanning

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Pinterest to scan for their API tokens and help secure our mutual users on public repositories. Pinterest tokens allow developers to interact with Pinterest's API in order to build experiences and apps for creators, advertisers, merchants and users on top of Pinterest. GitHub will forward access tokens found in public repositories to Pinterest, which will then notify the user about the leaked token. You can read more information about Pinterest tokens here.

All users can scan for and block Pinterest's tokens from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block Pinterest tokens in their private repositories.

See more

GitHub Advanced Security customers that have validity checks enabled will see the validation status for select AWS, Google, Microsoft, and Slack tokens on the alert.

The following tokens are supported:

  • aws_access_key_id
  • aws_secret_access_key
  • aws_session_token
  • aws_temporary_access_key_id
  • aws_secret_access_key
  • google_oauth_access_token
  • google_api_key
  • nuget_api_key
  • slack_api_token

AWS tokens will have validation checks performed periodically in the background, with on-demand validity checks to come in the future.

View our supported secrets documentation to keep up to date as we expand validation support.

See more

In February 2022, we introduced experimental CodeQL queries that utilize machine learning to identify more potential vulnerabilities. This feature was only available for JavaScript / TypeScript code and was available to code scanning users that enabled the optional security-extended or security-and-quality query suites.

We disabled this experimental feature for new code scanning users in June 2023. Today, we're sunsetting it for all users.

Any currently open code scanning alerts from these queries (Rule ID starts with js/ml-powered/) will be closed. Closed alerts will still be visible in the code scanning alerts view in your repository’s Security tab. The complete history of each alert will remain accessible by clicking on the alert.

CodeQL will continue to run the existing non-ML versions of these queries and provide you with highly precise and actionable alerts.

We’ve learned a lot from the feedback and experience of the repositories that participated in this experiment, and we’ve since ramped up our investment in AI-powered security technology. This new technology is already boosting our ability to cover more sources and sinks of untrusted data in order to significantly increase the coverage and depth of all queries.

See more

You can now now see the list of recent jobs that Dependabot has run to check for updates and create or rebase pull requests directly from the repository-level dependency graph section of the insights tab. This list will show whether a job was successful, any error messages, and provide links to both the full logs for the job and any pull request affected by the job. This will give you more visibility into the Dependabot process and help you debug.

Screenshot of a list of details about recent Dependabot jobs for a repository

Learn more about troubleshooting Dependabot issues

See more

GitHub Advanced Security now automatically only consumes licenses for commits and pushes made after a repository is migrated to GitHub, rather than considering all historic contributions from before the migration.

When a repository is migrated to GitHub, all historic commits are combined into a single push. This meant that when GitHub Advanced Security was enabled the repository would use licenses for all commits in that combined push, and so consume licenses for all historic commits. Previously this would be resolved manually, but this ship automates this work. GitHub Advanced Security now only uses licences for commits and pushes made after migration and does not consider legacy pushes that occurred in migrated repositories.

This has shipped to GitHub.com and will ship to GitHub Enterprise Server 3.12. Read more about billing for GitHub Advanced Security.

See more

With CodeQL model packs for Java, users can improve their code scanning results by ensuring that any custom Java libraries and frameworks used by their codebase are recognised by CodeQL.

The out-of-the-box CodeQL threat models provide great coverage for identifying large numbers of potential vulnerabilities in GitHub repositories using code scanning. We are continually working to improve CodeQL's ability to recognize and track potential sources of untrusted data to potentially-vulnerable locations ('sinks'). To do that, we keep a close eye on the most widely-used open-source libraries and frameworks. That way, CodeQL can recognize untrusted data that enters an application through, for example, commonly-used web frameworks. We are even using advances in AI to boost our threat modeling efforts and help developers write even more secure code.

There will always be cases which are not covered by CodeQL's standard threat models, such as custom-built or inner-sourced frameworks and libraries. Using CodeQL's new model pack functionality for Java (beta), security teams and security-conscious developers can create custom models that help CodeQL detect and flag additional security vulnerabilities. These custom model packs work seamlessly in GitHub code scanning, which means developers get the most relevant code scanning alerts during their day-to-day work.

CodeQL model packs are part of the CodeQL package management ecosystem. The packs contain structured data which describe whether a method within a library is a taint source, sink, or propagator (also known as a flow summary). You can create CodeQL model packs for Java using the CodeQL model editor, a new feature in the CodeQL extension for VS Code. The CodeQL model editor includes support for:

  • identifying methods in your codebase that aren't recognised by the standard CodeQL analysis
  • interactively classifying those methods as a source, sink, or summary
  • automatically generating a CodeQL model pack that can be easily added to code scanning.

For more information about using CodeQL model packs in code scanning, see:

For more information about using the CodeQL model editor, see Using the CodeQL model editor.

See more

Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale.

Starting today, you can now 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.

What’s changing?

For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. 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.

Frequently asked questions

Why is GitHub making this change?

At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.

That’s why, moving forward, we’re releasing a series of ships powered by an underlying, all-new, flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns. Today’s ship exposes our rules engine so you can create your own rules, too.

Which criteria are supported?

Rules can be created across the following attributes:

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.

What behaviors are supported?

Create or edit a custom rule

Today’s ship covers support for auto-dismissing alerts indefinitely as well as snoozing alerts until patch. Auto-dismissing ensures all activity is easily visible and can be caught by existing reporting systems and workflows, while also ensuring that alerts can be reintroduced if metadata across the alert changes.

How will this activity be reported?

Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.

Who can create and modify rules?

Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories.

How do I reopen an automatically dismissed alert?

Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again (by any other auto-dismiss rule).

What happens if alert metadata changes or advisory information is withdrawn?

Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more

Dependency review now works with your dependencies from the dependency submission API. Dependency review enforces policies around vulnerabilities and acceptable licenses in the pull request. Previously, dependency review could not be used with another feature of the dependency graph called the dependency submission API. The dependency submission API helps developers get a more accurate set of transitive dependencies, particularly for complex ecosystems like Gradle or Scala which require a build to resolve all transitive dependencies.

To take advantage of this improvement, update to the latest version of the dependency review action, or follow the instructions in our documentation.

For more information, see our documentation about dependency review, the dependency submission API, and some best practices for using dependency review and the dependency submission API together.

See more

Code scanning with CodeQL now supports Java codebases that use Project Lombok. Previously, code scanning users were able to scan Java applications that contained Lombok code, but all the contents of files containing Lombok code were either skipped or users had to apply a workaround to prepare the applications for scanning. The improved support means that code with Lombok features will be automatically scanned without requiring any workaround.

As more code will now be analyzed by the CodeQL engine, we can establish more accurate data flow (or lack thereof) through Lombok code. This might have an impact on the number of alerts produced by a scan. The most common scenario is that additional alerts appear in the newly-analyzed code. Conversely, there is a very small chance that some existing alerts are closed.

Improved support for Java applications built using Lombok is available for code scanning users on GitHub.com starting today and GitHub Enterprise Server users starting with 3.11. CodeQL CLI will provide out of the box support starting with the upcoming version 2.14.4. Security researchers can set up the CodeQL CLI and VS Code extension by following these instructions.

See more

The enterprise and organization level audit logs now record an event when the setting for automatic validity checks for secrets is enabled or disabled. This data helps GitHub Advanced Security customers understand actions taken on their secret scanning alerts for security and compliance audits.

See more

Dependabot version updates help you keep your dependencies up-to-date by opening pull requests when dependencies can be upgraded. With today's release, you can now use flexible grouping options in dependabot.yml to take control of how Dependabot structures its pull requests to make them more mergeable for you based on your context. Whether you'd like to simply update as many dependencies at once as possible (patterns: *) or minimize the risk of breaking changes (dependency-type: development or update-types: "patch"), there are grouping options for you.

Until today, Dependabot would always open individual pull requests for every dependency update in accordance with your configuration in dependabot.yml. Not only can this result in a large number of Dependabot pull requests, but there are some dependencies which must be updated in tandem with each other or the update will fail. In these cases, the individual Dependabot pull requests would always fail until you manually intervened to do the update.

The available grouping options are:

  • patterns, which will match based on package names
  • dependency-type, which will group based on development or production dependencies, for ecosystems where this is supported, and
  • update-types, which will group based on SemVer level update

At this time, grouping is not available for security updates or Dependabot alerts.

Learn more about grouping configuration options here

See more