You will now be able to see whether Dependabot security updates are enabled or disabled in the security and analysis block within the repository information you can fetch from the REST API, and enable or disable them via API requests.
For more information, you can check out our repository API documentation.
Enterprise users will now notice added functionality where Dependabot security and version updates may be paused for repositories.
If you are an enterprise user that uses Dependabot updates and there has been no activity in a repository, such as merging, closing, or any other interaction, with Dependabot pull requests for a period exceeding 90 days, the updates will be paused. To resume activity, simply merge or close one of Dependabot's pull requests, or modify the Dependabot config file in the repository.
This change will help Dependabot be more focused to the repositories you care about and reduce use of GitHub Actions minutes on inactive Dependabot pull requests.
If you are using security overview with GitHub Advanced Security, you will be able to see which repositories in your organization have been paused from the security coverage view.
You will also be able to see whether Dependabot has been paused for a repository by querying the /repos/{owner}/{repo}/automated-security-fixes REST API endpoint, which will return both the enablement status and paused status of the repository.
This change only applies to repositories where Dependabot pull requests exist but remain untouched. If no Dependabot pull requests have been opened, Dependabot will never become paused.
The following must be true for at least 90 days:
Dependabot will add a notice to the body of all open Dependabot pull requests and add a dependabot-paused label to them. Dependabot will also add a banner notice in the UI of your repository settings page (under “Dependabot”) as well as your Dependabot alerts page (if Dependabot security updates are affected).
This change does not apply to Dependabot alerts or subsequent notifications. So, only repositories that have automated Dependabot version updates or security updates, but haven't interacted with these pull requests for a while, will be affected.
Learn more about this change
Learn more about how to interact with the REST API
Today's Changelog brings you board column limits, an improved item menu to move your board items and updates to Issue hierarchy powered by tasklists!
You can now set column limits on the board layout to help you limit your work in progress as well as promote focus on the items that really matter. Column limits are based off of the number of items in a column, and are unique to each board view.
To configure a limit, set the value from the column's ... menu. If you exceed the limit, the value will be highlighted in red.
As always, we'd love to hear from you! Let us know your feedback in our community discussion.
Following our support for bulk updates and keyboard shortcuts, we've made it even easier to move the items on your boards. Select the item ... menu to move an item to the top or bottom of a column, or to a different column altogether.
You may have noticed a new button has appeared on issues and the projects side-panel! You can now easily add tasklists to your issues without ever having to enter your issue's Markdown.
Items can be dragged into collapsed groups in the table layout. Items can also be dragged and dropped across groups when sorting is enabled.
You can now download a view by selecting the view menu and clicking Download CSV.
Historical charts will no longer support group by values. We will be phasing historical charts out over the next couple of months and no new accounts will be added to the existing support.
Make a copy iconDelete project and Issue transfer modalsAdd item bar now populates in the issue create modalassignees table cellsSee how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.
The "Remove a repository from an app installation" API has been updated to fail early if attempting to remove a repository from an application that is installed on all repositories.
To switch an application InstallationState from the all to some state in your organization, an organization owner or application manager must make this change within the UI, while picking up to 50 repositories for the app to continue to have access to. From there, additional repositories can be added via the UI or the "Add a repository to an app installation" API.
To learn more about managing application installations, see "Modifying repository access". For details on the GitHub App REST API, see "GitHub Apps".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Yes! In addition to all free repositories, this feature will ship immediately to GHEC and to GHES in version 3.10.
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.
Let us know what you think by providing feedback — we’re listening!
Fine-grained PATs can now call the GitHub GraphQL API. This was a limitation at the start of the public beta, and is now supported.
Like with the REST API, the resource owner set for the token must match the owner of the resource being accessed. For example, when you want to look up a specific repository in GraphQL:
query {
repository(owner:"octocat", name:"Hello-World") {
...The resource owner would need to be octocat to succesfully run the query.
In addition, GitHub Apps now have read access to public resources via GraphQL by default when using user-to-server tokens. This is true even if they are not installed on the organization or user that owns the resource.
This change brings consistency to the access control between REST APIs and GraphQL APIs for GitHub Apps. We made similar changes previously for REST APIs which you can read more about here.
To learn more about GraphQL, see "About the GraphQL API". For more details about fine-grained PATs, see "Creating a fine-grained personal access token". And finally, to learn more about GitHub apps, see "Setting permissions for GitHub apps".
After recently adding the archive date of repositories to the GitHub UI, the timestamp is now also available in GraphQL API responses.
Users can now query the archivedAt timestamp of when a repository was archived using the GitHub GraphQL API.
GitHub enterprise and organization owners can now use a REST API to delete their organizations and all corresponding repositories. Organization names will be locked for 90 days following the organization deletion.
We recommend reading our Terms of Service around account deletion before utilizing this endpoint.
To learn more, please read our Organization REST API documentation.
GitHub Enterprise Cloud administrators may need to review external identity information via the GraphQL API. Historically, this has required a token with the admin:org or admin:enterprise scope. We've taken a "least privilege" mindset in reviewing this flow and have now made this information available via the read:enterprise and read:org scopes for enterprise owner and organization owner actors.
For more information, see the GraphQL API documentation for Enterprise and Organization SAMLIdentity objects.
Organization owners can now automate the approval and auditing of fine-grained personal access tokens (PATs) in their organization using a GitHub app. New APIs and webhook events allow a GitHub app to be notified of new PAT requests in an organization, review the request, and then approve or deny the PAT. They also provide a view of all approved fine-grained PATs for an organization, with the ability to revoke their authorization as well. These APIs and events are part of the ongoing fine-grained PAT public beta that launched last year.
Details included in the webhook event and API listings include the repositories and permissions requested, the expiration time of the token, and the user's explanation for what they plan to do with the PAT. The personal_access_token_request events are generated when a request is created, approved or denied by an administrator or application, or cancelled by the requesting user.
Only a GitHub app is able to call these APIs, either acting on its own or on behalf of a signed-in organization administrator.
The organization_personal_access_tokens permission is needed to manage the active tokens, while the organization_personal_access_token_requests permission enables the app to recieve webhooks about requests and call the request management APIs.
Organizations must have the personal access token approval flow enabled in order to manage these requests, otherwise fine-grained personal access tokens are automatically approved for the organization (which generates a personal_access_token_request: approved event).
To learn more about these APIs, see "List requests to access organization resources with fine-grained PATs" and the "personal_access_token_request webhook event". To learn more about fine-grained PATs, and how to enable them for your organization, see "Setting a personal access token policy for your organization".
If you have feedback or bugs to report about fine-grained PATs, please let us know in the dedicated feedback discussion.
We are preparing to bring powerful new code search capabilities to GitHub. As part of that effort, on April 10, 2023, we will make several changes to the code search API:
To prepare for these changes, make sure your code handles rate limiting. And if you’re using code search to track changes or find security vulnerabilities in your codebase, consider using webhooks or GitHub Advanced Security.
These changes will take effect in 30 days, on April 10, 2023.
The Custom Repository Roles REST API has moved to general availability, with a breaking change to the path used.
Previously, the API was found at /orgs/{org}/custom_roles – it has been moved to /orgs/{org}/custom-repository-roles. With organization-level custom roles in progress, we found that the custom_roles path was wasn't specific enough and could generate confusion.
The deprecated beta API will be removed from api.github.com in 6 months, on September 7th, 2023.
On GitHub Enterprise Server, the API will be available at its new path in version 3.9. The previous API to list roles was added in GHES 3.4, and will be removed with the next API version.
To learn more about custom repository roles, see "About custom repository roles" and "Custom repository roles REST API".
This feature makes it easier to enable Dependabot alerts and check enablement status across all your repositories at an enterprise level, with updates across both enablement UI and APIs. These updates will ship today for GitHub.com and will ship for GitHub Enterprise Server users in 3.9.
Dependabot alerts have been added to existing endpoints:
You can also adjust your enablement settings from your enterprise settings page (under ‘code security and analysis’). Options include enable all, disable all, and enable for new repositories for your enterprise.
Today’s Changelog brings you updates to workflows, roadmaps, our API and makes cross organization projects a breeze!
Last month, we shared the latest automation to help you automatically add relevant items to your project! However, if your project pulls from multiple repositories, this wasn’t enough. Today, we’re shipping the ability to create up to 3 copies of the auto-add workflow.
After configuring and enabling the initial auto-add workflow, open the context menu in the workflow list and select Duplicate workflow to create a new auto-add workflow.
Note Multi-repository auto-add is currently only shipped to Enterprise users
Alongside sorting your roadmap items by a field to organize your view, you can now reorder your items by dragging and dropping them in the table. Quickly make adjustments to the ordering of your items or move them to a different group altogether with the new drag-and-drop functionality.
We’ve made it easier to use Projects across different organizations, previously this required pasting URLs to a project directly. With this improvement you can:
# followed by the organization name and a / to start searching within that organization. addProjectV2ItemById, which will now accept an Issue or Pull Request from a different organization when adding to a Project. 
We’ve released new endpoints to our Projects GraphQL API providing the ability to create new projects, create project fields and delete project fields. Check out the docs below to find out more:
createProjectV2Field: https://docs.github.com/en/graphql/reference/mutations#createprojectv2fielddeleteProjectV2Field: https://docs.github.com/en/graphql/reference/mutations#deleteprojectv2fielddeleteProjectV2: https://docs.github.com/en/graphql/reference/mutations#deleteprojectv2TGZ file uploads working on Safari and Firefox. See how to use GitHub for project planning with GitHub issues, check out what’s on the roadmap, and learn more in the docs.
Today’s changelog brings you the addition of colors and descriptions for single-select fields, as well as improvements to both roadmaps and tasklists!
Make it easier for your team to scan projects and take action by adding color and descriptions to single select fields. To update a field, go to settings and select the pencil icon next to the custom single-select field you want to update.
If plans change and you need to make adjustments to your roadmap, you can now resize and move items between iterations. Drag and drop your items to quickly make your changes when using an iteration as a Date field on your roadmap.
You are also now able to resize the table in a roadmap view to create the space you need, similar to resizing a column in a table view.
Tasklists are currently in private beta but we’re letting folks in as fast as we can. If you haven’t already, be sure to join the waitlist!
We’ve recently shipped the below improvements, so let us know what you think.
– Navigate via the side-panel when grouped by Tracked by
– Open and navigate in the side-panel by clicking the Tracks completion pill
– Automatically update your filter by clicking on the “Tracked by” text in the Tracked by field in board layout
copyProjectV2 in the GraphQL API to copy a projectEdit details menu option See how to use GitHub for project planning with GitHub Issues, check out what’s on the roadmap, and learn more in the docs.