audit-log

Subscribe to all “audit-log” 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

Dependabot alerts now automatically dismiss false positives for npm (public beta)

Starting today, Dependabot will be able to auto-dismiss npm alerts that have limited impact (e.g. long-running tests) or are unlikely to be exploitable. With this ship, Dependabot will cut false positives and reduce alert fatigue substantially.

On-by-default for public repositories, and opt-in for private repositories, this feature will result in 15% of low impact npm alerts being auto-dismissed moving forward – so you can focus on the alerts that matter, without worrying about the ones that don’t.

What’s changing?

When the feature is enabled, Dependabot will auto-dismiss certain types of vulnerabilities that are found in npm dependencies used in development (npm devDependency alerts with scope:development). This feature will help you proactively filter out false positives on development-scoped (non-production or runtime) alerts without compromising on high risk devDependency alerts.

Dependabot alerts auto-dismissal list view

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. Today’s ship, our first application, leverages GitHub-curated vulnerability patterns to help proactively filter out false positive alerts.

Why auto-dismissal, rather than purely suppressing these alerts?

Auto-dismissing ensures any ignored alerts are 1) able to be reintroduced if alert metadata changes, 2) caught by existing reporting systems and workflows, and 3) extensible as a whole to future rules-based actions, where Dependabot can decision on subsets of alerts and do things like reopen for patch, open a Dependabot pull request, or even auto-merge if very risky.

How does GitHub identify and detect low impact alerts?

Auto-dismissed alerts match GitHub-curated vulnerability patterns. These patterns take into account contextual information about how you’re using the dependency and the level of risk they may pose to your repository. To learn more, see our documentation on covered classes of vulnerabilities.

How will this activity be reported?

Auto-dismissal activity is supported across webhooks, REST, GraphQL, and the audit log for Dependabot alerts. In addition, you can review your closed alert list with the resolution:auto-dismissed filter.

How will this experience look and feel?

Alerts identified as false positives will be automatically dismissed without a notification or new pull request, and appear as 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.

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.

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 can I enable or disable the feature?

This feature is on-by-default for public repositories and opt-in for private repositories. Repository admins can opt in or out from your Dependabot alerts settings in the Code Security page.

Is this feature available for enterprise?

Yes! In addition to all free repositories, this feature will ship immediately to GHEC and to GHES in version 3.10.

What’s next?

Next, we’ll expose our underlying engine – which enables Dependabot to perform actions based on a rich set of contextual alert metadata – so you can write your own custom rules to better manage your alerts, too.

How do I learn more?

How do I provide feedback?

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

See more

False-alert flags will appear in audit logs due to a bug in branch protections

Organizations and enterprises using branch protections may see false-alert flags in their security log for protected_branch.policy_override and protected_branch.rejected_ref_update events between January 6 and January 11, 2023.
These events were improperly emitted due to a change in the underlying logic that checks if branch protection criteria have been met.

No action is required from impacted users with regards to these events. GitHub has a policy to not delete security log events, even ones generated in error. For this reason, we are adding flags to signal that these events are false-alerts.

an audit log entry with the flash message displayed above it

See more

Audit log improvements for Dependabot alerts

GitHub's audit log allows organization and enterprise admins to quickly review the actions performed by members of their organization or enterprise. For Dependabot alerts, the audit log includes actions such as repository enablement, creation or reintroduction of alerts, dismissal of alerts, and resolving of alerts.

The audit log now supports the following improvements:

  • Dismissal comments, if provided with a Dependabot alert, are now displayed in the audit log
  • The audit log API for Dependabot alerts now supports several new fields: alert_number, ghsa_id, dismiss_reason, and dismiss_comment.
  • Additional minor improvements, including links back to the alert and correct timestamps added to events.

This release is available for organization and enterprise admins (including GHES 3.7 and later).

For more information, view documentation on Dependabot alerts in the GitHub audit log.

See more

Secret scanning enterprise-level enablement events now in the audit log

The enterprise audit log now records changes to GitHub Advanced Security, secret scanning, and push protection enablement.

The organization-level audit log now also records when a push protection custom message is enabled, disabled, or updated.

For more information:

See more

Audit Log Streaming to Datadog is generally available

GitHub Enterprise Cloud customers can now stream their audit log to a Datadog endpoint. Enterprise owners need to be able to use the right tools for their job, whether that be short-term investigation or longer-term threat analysis and prevention. With audit log streaming to Datadog, customers can be assured that:

  • no audit log event will be lost,
  • they may satisfy longer-term data retention goals, and
  • they can analyze GitHub's audit log data using Datadog products.

For GitHub Enterprise Server customers, this feature is planned to come to GHES 3.8.

For additional information, read our documentation about setting up streaming to Datadog.
“

See more

Display Authentication Token Data in your Enterprise Audit Log – Beta

GitHub Enterprise Cloud customers can now participate in a private beta enabling authentication token data to display for audit log events. In doing so, enterprise owners will be able to query their audit logs for activity associated with specific authentication tokens. With the introduction of this feature, enterprise owners will be better equipped to detect and trace activity associated with corrupt authentication tokens, which have the potential to provide threat actors access to sensitive private assets.

Enterprise owners interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Once enabled, enterprise owners can find guidance and provide feedback at the displaying authentication token data in enterprise audit log events community discussion..

See more

Stream audit log to AWS S3 with OpenID Connect (OIDC)

The functionality for GitHub Enterprise Cloud customers to configure audit log streaming to AWS S3 with OpenID Connect (OIDC) is now generally available. Audit log streaming configured with OIDC eliminates storage of long-lived cloud secrets on GitHub by using short-lived tokens exchanged via REST/JSON message flows for authentication.

For additional information, please read about setting up audit log streaming to AWS S3 with OpenID Connect.

See more

Enhancements to Audit Log Exports

GitHub's audit log allows admins to quickly review the actions performed by members of their Enterprise. It includes details such as who performed the action, what the action was, and when it was performed. GitHub's audit log provides users with the ability to export audit log activity for your enterprise as a JSON or CSV file download. Moving forward, customers can expect to see the following enhancements to their audit log exports:

  • Audit log exports will contain the same fields as the REST API and audit log streaming, bringing consistency across these three audit log consumption modalities.
  • actions events will be present in audit log exports.
  • For Enterprises who have enabled the feature to display IP addresses in their enterprise audit logs, IP addresses will be present in audit log exports.
  • Audit log exports will be delivered as a compressed file.
  • Audit log JSON exports will be formatted with each line of the JSON file contains a single event, rather than a single JSON document with an array containing all the events as array elements.

This feature will be gradually enabled for an increasing percentage of GitHub Enterprise Cloud customers with a goal of 100% enablement by October 28, 2022. Should you encounter a problem with your audit log exports, please reach out to GitHub Support for assistance.

See more

Improvements to audit log search

We've made some improvements to audit log search to make it easier to discover events. Since audit log events are found through key:value pairs, we now show you a list of possible options to choose from.
key-value pair dropdown menu available in audit log search

We've also linked to our documentation in the filter dropdown so that you can more easily discover all the possible options for audit log queries.

view advanced search syntax added to audit log filter

To learn more about how to query the audit log, check out our documentation, "About search for the enterprise audit log".

See more

New Audit Log events and event context

GitHub's audit log allows admins to quickly review the actions performed by members of their Enterprise. It includes details such as who performed the action, what the action was, and when it was performed. To ensure the audit log can be used as an effective security and compliance tool, GitHub is constantly evaluating new audit log events and ensuring those events have the necessary fields to provide meaningful context. GitHub has made the following enhancements to the Enterprise audit logs:

  • business.sso_response and org.sso_response events will be displayed in the REST API and audit log streaming payloads for GitHub Enterprise Cloud (GHEC) and GitHub Enterprise Server (GHES) version 3.8 or later.
  • repo.rename, project.rename, and protected_branch.update_name events will now include the old_name field make clear the current and past name of renamed repos, projects, and protected branches.
See more

Audit Log Streaming to Datadog available as Public Beta

GitHub Enterprise Cloud (GHEC) customers can now participate in a public beta enabling audit log streaming to a Datadog endpoint. Joining this beta allows enterprises to continue to satisfy long-term data retention goals and also analyze GitHub audit log data using the tools offered by Datadog.

GHEC administrators interested in participating in the public beta can enable audit log streaming by following the instructions for setting up streaming to Datadog. Customers can provide feedback on their experience at the audit log streaming to Datadog community discussion.

See more

False-alert flags will appear in users security log due to a bug in 2FA recovery events

Users with 2FA enabled may see false-alert flags in their security log for recovery_code_regenerated events between July 15 and August 11, 2022.
These events were improperly emitted during an upgrade to the 2FA platform. The storage format of the per-user value GitHub uses to generate your recovery codes was updated, causing the watch job to trigger the erroneous recovery_code_regenerated event.

No action is required from impacted users with regards to these events. GitHub has a policy to not delete security log events, even ones generated in error. For this reason, we are adding flags to signal that these events are false-alerts. No recovery codes were regenerated, and your existing saved recovery codes are still valid.

image

See more

GitHub Enterprise Cloud customers can configure audit log streaming to AWS S3 with OpenID Connect (OIDC) – Public Beta

GitHub Enterprise Cloud customers can elect to participate in a public beta to configure audit log streaming to AWS S3 with OpenID Connect (OIDC). Audit log streaming configured with OIDC eliminates storage of long-lived cloud secrets on GitHub by using short-lived tokens exchanged via REST/JSON message flows for authentication.

For additional information, please follow the instructions for setting up audit log streaming to AWS S3 with OpenID Connect.

See more

GitHub Enterprise Cloud customers can access IP addresses for audit log entries for enterprise owned assets

The ability for GitHub Enterprise Cloud owners to display members’ IP addresses for all audit logs events for private repositories and other enterprise assets, such as issues and projects, is generally available.

These IP addresses can be used to improve threat analyses and further secure your software. Note, IP addresses will continue to not be displayed for activity related to public repositories.

For additional information, read about displaying IP addresses in the audit log for your enterprise.

See more
View more changes