Secret scanning has a new, AI-powered regular expression generator for custom patterns. Within the existing custom patterns page, GitHub Advanced Security users can launch a generative AI experience where you input a text description of what pattern you would like to detect, include optional example strings that should be detected, and get matching regular expressions in return.
The generator is in a limited beta and access will be granted through a waitlist.
A new asset in security management is now available for GitHub enterprise users. Reinforcing the “shift left” philosophy, this feature is designed to integrate security into the heart of the development lifecycle, empowering your organization to proactively identify and address vulnerabilities.
By comparing historical and current data, you can visibly track improvements in your security landscape and demonstrate the value of security investments.
Sharpen your focus with filters that dissect your security data by teams, repositories, or any categorization that aligns with your goals. Whether it’s tracking team performance or monitoring metrics across a core group of repositories with the repository topic filter, there’s a plethora of options available to meet your needs.
With clear insights into severity and net resolve rate—security’s version of developer velocity—the dashboard shows you if your resources are aligned with the most severe threats and if remediation speed is in harmony with security demands.
Gain a strategic perspective with the Repositories “Top 10” list, which shows you repositories with the largest number of open alert counts, to understand where to direct your attention first.
The dashboard, which is accessible by everyone in the organization, helps you drive best security practices by understanding potential issues as early as possible, reducing risk and workload down the line.
This overview dashboard is now available as a beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.13.
Learn more about the new overview dashboard and send us your feedback
Secret scanning will now detect the following non-provider patterns:
Detection of these patterns must be enabled within a repository or organization’s security settings by checking the box next to “Scan for non-provider patterns.” Resulting secrets will appear in a new, separate tab on the secret scanning alert list called “Other.”
Detection of non-provider patterns is currently in beta and is available for enterprises with a GitHub Advanced Security license only. Additional patterns will be added throughout the beta.
GitHub Advanced Security users can now filter their secret scanning alerts by validity in the UI at the repository, organization, and enterprise level. Valid statuses are active, inactive, or unknown. Validity checks must be enabled for the repository, organization, or enterprise.
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 Onfido to scan for their tokens to help secure our mutual users in public repositories. Onfido tokens allow developers to interact with Onfido's API in order to integrate secure and reliable identity verification solutions into their applications and services, helping to enhance user onboarding processes and protect against fraud. GitHub will forward any exposed tokens found in public repositories to Onfido, who will then notify the customer about the leaked token. Read more information about Onfido API tokens.
GitHub Advanced Security customers can also scan for and block Onfido tokens in their private repositories.
The GitHub Advanced Security billing REST API and CSV download now includes the email addresses for active committers. This provides information for insights into Advanced Security license usage across your business. Here is an example response from the GitHub Advanced Security billing REST API:
"advanced_security_committers_breakdown": [
{
"user_login": "octokitten",
"last_pushed_date": "2023-10-26",
"last_pushed_email": "octokitten@email.com"
}Read more about the GHAS billing API here and the GHAS billing CSV download here.
This is available now on GitHub.com and will ship to GitHub Enterprise Server 3.12
GitHub Advanced Security users can now use the REST API to retrieve the validity status of a secret scanning token and retrieve all tokens of a particular validity status. The API will return the status of the token as of the last validity check. Valid statuses are active, inactive, or unknown. Validity checks must be enabled for the enterprise, organization, or repository.
Auto-triage rules are a powerful tool to help you reduce alert and pull request fatigue substantially, while better managing your alerts at scale.
Starting today, you can define your own rules to control and enforce Dependabot behaviors across organizations and individual repositories.
Auto-triage rules are defined by alert targeting criteria, the behaviors you'd like Dependabot to automatically perform for these alerts, as well as how you want the rule to be enabled or enforced across your organization.
Alerts can be targeted based on metadata related to the advisory, dependency, and how it's used. For this public beta, currently supported attributes at the organization level are: severity, scope, package-name, cwe, and ecosystem. At the repository level, you can also target specific manifest files.
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, choose which alerts open Dependabot security updates, and – as rules apply to both future and current alerts – manage existing alerts in bulk.
This feature is free for open source (all public repositories) and available for use in private repositories through GitHub Advanced Security.
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 a flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns and has helped millions of repositories filter out false positive alerts. Today’s ship exposes our rules engine at the organization and repository levels, so you can create and enforce custom rules, too.
From your organization or repository settings page, admins and security managers can navigate to Code security and analysis settings. Under Dependabot, select Dependabot rules to add or modify your own custom rules or modify GitHub presets.
At the organization level, rules can be set with the following states.
| State | Description |
|---|---|
Enabled |
This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Any individual repository can choose to disable the rule. |
Enforced |
This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Individual repositories cannot override this setting. |
Disabled |
This rule will be disabled and hidden across your organization. |
At the repository level, rules can be set to enabled or disabled if they're not enforced.
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. |
Note: manifest is only available at the repository level.
You can use the alert criteria (above) to indicate which alerts Dependabot will attempt to open pull requests to resolve. To use auto-triage rules with Dependabot updates, you must disable Dependabot's option to always open pull requests to resolve all open alerts from the repository Code security and analysis settings.
Similar to Dependabot pull request rules, you can control how Dependabot filters out false postives (with dismiss indefinitely) or snoozes alerts (with dismiss until patch).
At the time of public beta, you can create 20 rules per organization and 10 rules for each repository. Want more? Let us know!
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.
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 and at the organization level.
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).
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.
Let us know what you think by providing feedback — we’re listening!
Secret scanning automatically detects leaked secrets across all public packages on the npm registry. If secret scanning detects a potential secret, we notify the service provider who issued the secret. The service provider validates the string and then decides whether they should revoke the secret, issue a new secret, or contact the committer directly. Package maintainers will not receive secret scanning alerts for these detections.
You can now access CodeQL, Secret Scanning, and other features of GitHub Advanced Security as part of your GitHub Enterprise Cloud trial. Enterprise admins can enable GitHub Advanced Security under Enterprise licensing.
Code scanning default setup now automatically attempts to analyze all CodeQL supported languages in a repository. This means default setup supports all CodeQL languages at the organization level, including enabling code scanning from an organization's Security Overview coverage page or settings page.
Previously, users would have to manually include the languages C, C++, C#, Java, or Kotlin in a default setup analysis, and enabling these languages was not supported at the organization level. Now, code scanning default setup automatically attempts to analyze all languages supported by CodeQL in a repository. If any analyses fail, the failed language will be automatically deselected from the code scanning configuration. Any alerts from the successfully analyzed languages will be shown on GitHub. This means code scanning will automatically set up the best possible configuration to get started easily with CodeQL and show the most relevant alerts to developers.
A warning banner is shown in the repository settings page if any languages fail and are deseslected. The "edit configuration" page shows all languages in the configuration, and allows users to change the language selection if required. For more information about the languages and versions supported by CodeQL and code scanning, see Supported languages and frameworks. To learn more about code scanning, see About code scanning.
This change is already available on GitHub.com and will be available in GitHub Enterprise Server 3.12.
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 Authress to scan for their service client access keys and their user API tokens to help secure our mutual users in public repositories. Authress access keys allow users to secure applications and platforms through machine-to-machine authentication and they enable granular resource-based authorization. GitHub will forward any exposed access keys found in public repositories to Authress, who will automatically revoke the exposed access key, create an audit trail message that can be ingested by SIEM technologies, and send an email alert to your Authress account admin. Read more information about Authress API access keys.
All users can scan for and block Authress keys from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block Authress keys in their private repositories.
To enable developers to write code as securely as possible in their language of choice and using the latest features available, we constantly update code scanning with CodeQL. As such we are happy to announce that CodeQL now supports analyzing code written in Go 1.21.
Go 1.21 support is available by default in GitHub.com code scanning, CodeQL version 2.14.6, and GHES 3.11. For more information about the languages and versions supported by CodeQL and code scanning, see Supported languages and frameworks. To learn more about code scanning, see About code scanning.
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 Mercury to scan for their license keys and help secure our mutual users on public repositories. Mercury tokens allow users to automate your banking needs through their API. GitHub will forward tokens found in public repositories to Mercury, who will then revoke them, keeping your account safe. Read more information about Mercury tokens.
All users can scan for and block Mercury tokens from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block Mercury tokens in their private repositories.
GitHub Advanced Security customers that have validity checks enabled for secret scanning will see the validation status for the following Discord tokens:
View our supported secrets documentation to keep up to date as we expand validation support.