Find secrets in your organization with the secret risk assessment

Find secrets in your organization with the secret risk assessment

GitHub is committed to empowering the developer community by helping organizations recognize and address the risks of secret leaks. That’s why we’re launching a new free tool next month which will provide clear insights into their exposure, along with actionable steps to strengthen their security and protect their code.

Scan your organization for aggregate insights on public leaks, private exposures, and token types.

The secret risk assessment provides insights about secret leak exposures

When will this feature be available?

The secret risk assessment will be available on April 1, 2025 as part of the launch of Secret Protection for GitHub Team and Enterprise plans.

What will this dashboard include?

Available in the ‘Security’ tab, organization and security admins will be able to run a scan in order to understand how their organization is affected by secret leaks and exposures. Once a scan is initiated, GitHub will look for secret leaks and exposures across your organization, returning a collection of insights including:

  • Number of secrets leaked per type
  • Number of publicly visible secrets in your public repositories
  • Number of repositories affected per secret type

No specific secrets will be stored or shared. The scan will be a point-in-time assessment across all public and private repositories. For organizations ready to adopt a continuous monitoring tool, we recommend enabling secret scanning for detection and incident management of specific secrets.

Why are we doing this?

We’re launching this feature to help organizations understand their secret leak footprint across their GitHub perimeter.

GitHub is committed to making a meaningful impact on the developer community by helping organizations recognize their risk from secret leaks. Our goal is to provide clear insights into their exposure and a clear path to stronger security.

Who can use this feature?

This feature will be available for free to organizations with a GitHub Team or Enterprise plan. Organization admins and security managers will be able to run the report and review any results.

To learn more about the launch of GitHub Secret Protection, please refer to this changelog. Have questions? Let us know what you think by starting a discussion in GitHub Community — we’re listening.

Improved pull request merge experience is now generally available

The improved merge experience on the pull request page is now generally available! This update is designed to help you better understand the state of your pull request and get it merged faster.

Screenshot of the updated merge box page on the pull request page showing it is approved, a list of status checks (some failing), and a message about not having any merge conflicts.

This experience supports all the usual ways of merging: direct, bypass and merge, auto-merge, and merge queue, and works with rulesets to ensure pull requests meet all the requirements to merge.

What’s new

The new experience is designed to feel familiar, but also improves on the previous experience. Here are some highlights:

  • Checks grouped by status: checks are now grouped by status with failing checks prioritized at the top of the list, making it easier to identify problems that need attention
  • Checks ordered logically: status checks are now ordered using natural ordering to make it easier to find a specific check, especially when the list gets long
  • Improved rule enforcement: errors resulting from failing commit metadata rules (like invalid commit messages) are now reported at the point of merging so they can be corrected
  • Improved accessibility: consistent keyboard navigation, focus management, and landmarks help make the experience more accessible to everyone

Get help

Learn more about merging a pull request.

To suggest a feature, report a problem, or discuss this improved experience, visit the GitHub Community.

See more

Easily distinguish between direct and transitive dependencies for npm packages

npm’s massive ecosystem of open source packages is one of its greatest strengths. But as a security-conscious developer, it can be tough to keep up with vulnerability reporting and updates once your project has more than a handful of dependencies, each of which has its own set of dependent packages. Dependabot notifies you of vulnerabilities and their fixes as they come in. Unfortunately, it’s hard to distinguish actionable alerts about direct dependencies you’ve added to your manifests from those transitive dependencies that were pulled in along the way… until now, that is.

GitHub’s dependency graph now tracks direct and transitive dependencies for npm packages. This helps you triage, prioritize, and remediate your Dependabot alerts. This capability shows up in user-facing features across the site:

  • Dependabot alerts will now contain a direct label if they are associated with a package you’ve directly included in a manifest. You can filter the list of alerts down to only these direct ones with the relationship:direct filter in the search bar.
  • Alerts for transitive dependencies now show transitive path information – the chain of packages which led from your direct dependency to the transitive one which has the vulnerability.
  • A repository’s dependency graph now distinguishes between direct and transitive relationships. Direct dependencies will have a label in the table UI, whereas indirect dependencies have a disclosure menu that shows the transitive path which led to their inclusion.
  • A repository’s SBOM will contain a relationships section that uses the SPDX relationshipType: DEPENDS_ON field to express the tree of package dependencies. Tools like guac.sh can help explore and visualize this tree.
  • The GraphQL API will now return a relationship field with direct, transitive, or unknown values in the DependencyGraphDependency object. See the API documentation for details.

A table of Dependabot alerts can now be filtered to show only direct dependencies

We started with npm because it’s the most popular package ecosystem in the known universe, but it’s just the beginning. Over the next few months, package types for other programming languages will also get the transitivity treatment. Up next: Maven packages for Java.

To try this out, you’ll need to make sure the dependency graph is enabled. To see the Dependabot labels, you’ll also need to enable Dependabot alerts. If the “Direct” labels aren’t showing up for you immediately, push a commit that updates one of your manifest files, which will trigger an update of the dependency graph.

Join the discussion within GitHub Community.

See more
View all changes