On September 27, 2023, we began blocking npm package publishes with differing name or version fields between the manifest and tarball package.json. This blocking protects against obfuscation. The different fields in the manifests have been assessed from a risk-based perspective. We will continue to analyze for other mismatches that can be blocked that won’t have adverse effects on the ecosystem. If a package is blocked, a user may receive an error message similar to “Package ‘version’ is “1.0.4”. It should match “1.0.3” from “package.json” in packaged tarball. Make all changes to package.json before packaging a tarball to publish.” In addition, a new tool, npm pkg fix, can help users fix any validation errors from the registry when they attempt to publish a package.
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.
To learn more, read our documentation on identifying audit log events performed by an access token.
Announcing changes to permissions for packages.
We are restricting the refs REST API endpoint from accepting POSTs from users and apps that only have the permission to read and write packages. Previously, this endpoint accepted updates to both tags and branches.
If that ability is critical to your development flows you will now be required to add explicit contents permissions to create refs.
- Users will need to add the
public_reposcope to their PAT token.
- Apps will need to use the
read and writecontents permission.
- GitHub Actions customers will need to add
contents:writeto their workflow YAML.permissions: contents: write
A small cohort of customers relying on this flow have been notified of these changes and will have additional time to remediate.
We appreciate your feedback in GitHub's public feedback discussions.
To help users better understand the state of a pull request, we now provide more details in two specific cases.
Merged indirectly
If a pull request's commits are merged into the base branch by another pull request (or directly), the pull request is still marked as merged, but previously, it was not clear from the timeline that the pull request was merged this way. This could result in confusion if the pull request was still awaiting approvals or had failing status checks. Now, the timeline provides more details, including a link to the merged pull request that caused the pull request to be marked as merged.
Note: this message only appears when using rulesets.
Pushed commits are still being processed
If new commits are pushed to a pull request's branch and it takes longer than usual for them to be processed and appear in the commit list, an informational message is now presented at the top of the pull request page.
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.
To learn more, read our documentation about SAML SSO authentication data in our audit logs. Enterprise and organization owners can provide feedback at the logging SAML SSO authentication data for enterprise and org audit log events community discussion page.
npm provenance is now generally available.
npm packages built on a supported cloud CI/CD system can publish with provenance. Today this includes GitHub Actions and GitLab CI/CD.
Publishing with provenance verifiably links the package back to its source repository and build instructions. Provenance is restricted to public packages and public source repositories only.
npm will check the linked source commit and repository when you view a package's provenance information on npmjs.com. If the linked source commit or repository cannot be found, an error displays at the top of the page and alongside the provenance information to let you know that provenance for this package can no longer be established. This can happen when a repository is deleted or made private.
Once published, packages display provenance on the registry website:
For more information, see generating provenance.
Starting tomorrow Tuesday, September 26, 2023 we are updating the service endpoints for organizations with GitHub Copilot Chat beta enabled. If your organization uses a firewall to restrict network traffic, we recommend updating your allowlist to include *.githubcopilot.com if you haven’t done so already. This endpoint is required to deliver Copilot Chat messages.
If you are not ready to upgrade to this new endpoint, you can pin your GitHub Copilot Chat version to 0.7.1 or earlier.
If your organization doesn’t use a firewall to restrict network traffic, then no change is necessary. For a complete list of GitHub Copilot service endpoints, see our docs.
Node 16 has reached its end of life, prompting us to initiate its deprecation process for GitHub Actions. Our plan is to transition all actions to run on Node 20 by Spring 2024. We will actively monitor the migration's progress and gather community feedback before finalizing the transition date. Starting October 23rd, workflows containing actions running on Node 16 will display a warning to alert users about the upcoming migration.
What you need to do
For Actions maintainers
Modify your actions to run on Node 20 instead of Node 16. For guidance, refer to the Actions configuration settings.
For Actions users
Ensure your workflows use the latest versions of actions that are running on Node 20. For more information, see Using Versions for Actions.
For self-hosted runner administrators:
Update your self-hosted runners to runner version v2.308.0 or later to ensure compatibility with Node 20 actions.
Passkeys are a replacement for passwords when signing in, providing higher security, ease-of-use, and loss-protection. They are now generally available on GitHub.com for all users. By using a passkey you no longer need to enter a password, or even your username, when you sign in – nor do you need to perform 2FA, if you have 2FA enabled on your account. This is because passkeys validate your identity, as well as possession of a device, so they count as two authentication factors in one. Once enrolled, you can register a brand new passkey and upgrade many security keys to passkeys.
To learn more, check out our documentation "About passkeys", as well as this previous blog post from the passkeys beta announcement. If you have any feedback, please drop us a note in our public discussion – we're excited for this advance in account security, and would love to understand how we can make it better for you.
Actions customers will now be able to clear stuck workflows by forcing a cancel request from the REST API. This is a new feature and the existing endpoint to cancel a workflow run will remain unchanged.
Sometimes an Actions workflow can become stuck in a state that will not respond to a cancel request. This could block other workflows from executing and would often require customers to contact GitHub Support to resolve the issue. Going forward, customers can invoke force-cancel from the REST API, which will bypass conditions that would otherwise cause the workflow execution to continue. Customers should still only use force-cancel if the workflow fails to respond to POST /repos/{owner}/{repo}/actions/runs/{run_id}/cancel.
For more details see the GitHub Actions workflow runs REST API documentation.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.
Now generally available, GitHub Enterprise Cloud customers with enterprise managed users (EMU) can integrate with Ping Federate as a formally supported SSO and SCIM identity provider. To get started, download the Ping Federate "GitHub EMU Connector 1.0" from the add-ons tab on the download page, under the "SaaS Connectors" heading. Add the connector to your Ping Federate installation and consult the Ping Federate documentation in addition to GitHub's SAML SSO and SCIM documentation for configuration.
The "GitHub EMU Connector" is maintained and supported by our partner, Ping Identity. Ping additionally maintains their own release notes for this connector.
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:
- Extending CodeQL coverage with CodeQL model packs in default setup
- Extending CodeQL coverage with CodeQL model packs in advanced setup
For more information about using the CodeQL model editor, see Using the CodeQL model editor.
After a successful public beta, we're launching support for Bitbucket Server and Bitbucket Data Center migrations in GitHub Enterprise Importer.
You can now easily use GitHub Enterprise Importer to migrate your source code, revision history, pull requests, reviews and comments when moving to GitHub from your self-hosted Bitbucket instance.
To learn more about the benefits of switching from Bitbucket to GitHub, check our brand new blog post.
For a step-by-step guide on migrating from Bitbucket Server or Bitbucket Data Center, check out "Migrating repositories from Bitbucket Server to GitHub Enterprise Cloud" in the GitHub Docs.
If you have feedback or questions, please join our Community Discussion.
GitHub Actions Importer now supports migrations from Bitbucket, Bamboo Server, and Bamboo Data Center. Companies using those tools can plan, test, and automate the migration of pipelines to GitHub Actions more easily than ever before.
GitHub Actions Importer is available via the GitHub CLI or IssueOps. To get started, please visit our docs. For questions and feedback, check out the GitHub Actions Importer community.
GitHub-hosted runners now support up to 1000 concurrent jobs for our 4 – 64 vCPU runners, enhancing their capability to handle large-scale CI/CD workloads.
Our runners are designed to automatically scale to meet your needs. The concurrency limit feature allows users to specify the maximum number of jobs that can run simultaneously to execute Actions workflows. Previously capped at 250, we've made backend improvements to now support a maximum of 1000 concurrent jobs for runners within the 4-64 vCPU range for Windows and Linux operating systems.
Enterprise or organization administrators can set this concurrency limit under the Auto-scaling setting. GitHub-hosted runners with 4 or more vCPUs are available on both the GitHub Team and Enterprise plans.
If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.
We've added the ability to retrieve a repository's Contributing Guidelines via the GraphQL API. There is a new ContributingGuidelines object that's available under Repository object, when a CONTRIBUTING.md file is present.
This addition brings API parity with the other Community health files like CODE_OF_CONDUCT.md, which were previously available.
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?
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?
- About the auto-triage feature
- Dependabot alerts REST API
- Dependabot alerts GraphQL API
- Dependabot alerts webhook
How do I provide feedback?
Let us know what you think by providing feedback — we’re listening!
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.
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 and organization owners can provide feedback at the logging SAML SSO authentication data for enterprise and org audit log events community discussion page.
We have implemented a fix so that GITHUB_REF and the github.ref context value return a fully-formed ref (e.g – refs/heads/main) when a workflow is triggered as a result of a pull request being merged. This change only impacts a small subset of workflows that trigger as a result of a pull request closing after being merged and that make use of GITHUB_REF or github.ref.
Previously, GITHUB_REF and github.ref were incorrectly returning a shortened ref (e.g. – main). These should always return a fully-formed ref regardless of the scenario.
Please visit our documentation for more details about using Actions context and variables.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.
Self-serve enterprise accounts can now grant member organizations permission to create sponsorships. Sponsorships created by a member organization will charge the enterprise account's credit card on file.
Learn more about granting permissions.