Starting today for GitHub Enterprise Cloud and as part of GitHub Enterprise Server version 3.13, enterprise and organization audit log events will include the applicable SAML and SCIM identity data associated with the user. This data provides increased visibility into the identity of the user and enables logs from multiple systems to quickly and easily be linked using a common corporate identity. The SAML identity information will be displayed in the external_identity_nameid field and the SCIM identity data will be displayed in the external_identity_username field within the audit log payloads.
In GitHub Enterprise Cloud Classic, SAML SSO gives organization and enterprise owners a way to control and secure access to resources like repositories, issues, and pull requests. Organization owners can invite GitHub users to join an organization backed by SAML SSO, allowing users to become members of the organization while retaining their existing identity and contributions on GitHub.
If your Enterprise Cloud Classic organization uses SAML SSO, you can use SCIM to add, manage, and remove organization members’ access to your organization. For example, an administrator can deprovision an organization member using SCIM and automatically remove the member from the organization.
GitHub Enterprise and organization owners now have improved visibility into authentication activity via personal access token (classic), fine-grained personal access token (FGP), OAuth token, SSH key or deploy key. The audit log may now contain hashed renderings of the token or key used for authentication and the programmatic_access_type field describing the type of token/key used for authentication. Enterprise and organization owners can query by specific token or key to identify and track activity.
GitHub Enterprise Cloud customers can now participate in a public beta displaying SAML single sign-on (SSO) identities for relevant users in audit log events.
SAML SSO gives organization and enterprise owners a way to control and secure access to resources like repositories, issues, and pull requests. Organization owners can invite GitHub users to join an organization backed by SAML SSO, allowing users to become members of the organization while retaining their existing identity and contributions on GitHub.
With the addition of SAML SSO identities in the audit log, organization and enterprise owners can easily link audit log activity with the user's corporate identity used to SSO into GitHub.com. This provides increased visibility into the identity of the user and enables logs from multiple systems to quickly and easily be linked using a common SAML identity.
In October 2022, we released a private beta adding linked SAML single sign-on (SSO) identities for relevant users to GitHub Enterprise audit log events.
We are expanding the private beta to now include linked identities within git events, making this information available across all relevant events.
In early July, GitHub announced a new rate limit was coming for the audit log API endpoints. Starting today, each audit log API endpoint will impose a rate limit of 1,750 queries per hour per user, IP address, enterprise, or organization. This is higher than the previously stated change to 15 queries per minute, in order to allow integrators more time to adjust workflows and scripts which programmatically query the audit log API. We intend to enforce a limit of 15 queries per minute on or after November 1st, 2023.
This rate limit will be enforced on each combination of an individual user, IP address and entity path (/orgs/<org_name>/audit_log or /enterprises/<enterprise_name>/audit_log) independently.
To adapt to these changes and avoid rate limiting, programs or integrations querying the audit log API should query at a maximum frequency of 1,750 queries per hour. Additionally, applications querying the audit log API should be updated to honor HTTP 403 and 429 responses to dynamically adjust to the back-pressure exerted by GitHub.
In April, we announced that GitHub Enterprise Cloud customers could join a public beta for streaming API request events as part of their enterprise audit log. As part of that release, REST API calls against enterprise's private and internal repositories could be streamed to one of GitHub's supported streaming endpoints.
However, we've discovered the need to expand our api call coverage against private and internal repositories in order to capture other security significant api routes. Additionally, we've determined several api routes targeting internal and private repositories generate significant event volumes with little auditing or security value. To address these concerns, we partnered with GitHub's security team to define a set of auditing and security significant controllers to serve as the basis for the public beta. These adjustments to the beta should increase signal and decrease the noise generated by the api request event being streamed.
Note: hashed_token and token_id have been redacted for security reasons.
GitHub provides Enterprise customers with the ability to programmatically retrieve enterprise and organization audit log events in near real-time using the audit log API. A high-quality audit log is an essential tool used by enterprises to ensure compliance, maintain security, investigate issues, and promote accountability. To support these objectives, the audit log API needs to be highly reliable, consistently available, and extremely scalable.
Recognizing the audit log API's importance as a data source to enterprises, each audit log API endpoint will impose a rate limit of 15 queries per minute per enterprise or org starting August 1st, 2023. Based on a thorough analysis of event generation data, we are confident that the new rate limit will continue to support customers in accessing near real-time data via the audit log API. Additionally, query cost is a crucial consideration, and in the future, the audit log may impose further rate limiting for high-cost queries that place significant strain on our data stores.
What can you do to prepare for these changes? First, programs or integrations querying the audit log API should be adjusted to query at a maximum frequency of 15 queries per minute. Additionally, applications querying the audit log API should be updated to be capable of honoring HTTP 429 responses, enabling them to dynamically adjust to the back-pressure exerted by our systems. Alternatively, Enterprises seeking access to near real-time data should consider streaming your enterprise audit log.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
The Enterprise and Organization audit log UI and user security logs UI now include an expandable view that displays the full audit log payload of each event.
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.
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.
GitHub Enterprises and Organzations can now join a private beta to try our new expandable event payload view in their audit log.
We have gotten a lot of feedback that the information available in the audit log U/I is not the same as the data available in the audit log's exports, API and streaming payloads. In response, GitHub is adding a new expandable view of an event's payload in the audit log U/I. This brings data consistency to all the ways of consuming audit logs.
Enterprise and Organization 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. Make sure to let us know what you think using our beta feedback community discussion post.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
GitHub Enterprise Cloud customers can now join a public beta for streaming API request events as part of their enterprise audit log.
As part of this beta, REST API calls against enterprise's private and internal repositories can be streamed to one of GitHub's supported streaming endpoints.
Note: hashed_token and token_id have been redacted for security reasons.
Many GitHub users leverage GitHub's APIs to extend and customize their GitHub experience. However, use of APIs can create unique security and operational challenges for Enterprises. With the introduction of targeted audit log streaming API requests, enterprise owners are now able to:
Better understand and analyze API usage targeting their private and internal repositories;
Identify and diagnose potentially misconfigured applications or integrations;
Identify the authentication tokens being used by specific applications or integrations;
Troubleshoot API contributing to API rate limiting;
Leverage API activity when performing forensic investigations; and
Develop API specific anomaly detection algorithms to identify potentially malicious API activity.
GitHub organization owners can now opt-in to a public beta to display organization members' IP addresseses in audit logs events. When enabled, IP addresses will be displayed for all audit log events performed by organization members on organization assets other than public repositories, which will be treated differently due to privacy obligations.
The inclusion of IP addresses in audit logs helps software developers and administrators protect their systems and data from potential threats and improve their overall security posture by providing the source of an action or event within a system or network. This information is crucial for troubleshooting issues or investigating security incidents. IP addresses are often used in forensic investigations to trace the origin of cyberattacks, unauthorized access, or other malicious activities.
GitHub Enterprise Cloud customers can now join a private beta which allows API request events to be streamed as part of their enterprise audit log.
In this private beta, REST API calls against enterprise private repositories can be streamed to one of GitHub's supported streaming endpoints. Further iterations on this feature are planned to expand the API events captured and make this data available via the audit log API.
Many GitHub users leverage GitHub's APIs to extend and customize their GitHub experience. However, use of APIs can create unique security and operational challenges for Enterprises.
With the introduction of targeted audit log streaming API requests, Enterprise owners are now able to:
Better understand and analyze API usage targeting their private repositories;
Identify and diagnose potentially misconfigured applications or integrations;
Troubleshoot API activity targeting private repositories that may be contributing to API rate limiting; and
Develop API specific anomaly detection algorithms to identify potentially malicious activity.
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, you should begin seeing API request events in your audit log stream. Feedback can be provided at our beta feedback community discussion post.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Data exploration: Examine streamed events using your preferred tool for querying large quantities of data. The stream contains both audit and Git events across the entire enterprise account.
Data continuity: Pause the stream for up to seven days without losing any audit data.
Data retention: Keep your exported audit logs and Git events data as long as you need to.
To expand on this offering, enterprises streaming their audit log to AWS S3 now have the ability to use AWS CloudTrail Lake integration to automatically consolidate and ingest GitHub audit logs into AWS Cloud Trail Lake. AWS CloudTrail Lake is a managed security and audit data lake that allows organizations to aggregate, immutably store, and query events. By deploying this integration in your own AWS account, AWS CloudTrail Lake will capture and provide tools to analyze GitHub audit log events using SQL-based queries.
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.
