The repository dependency graph GraphQL API preview now returns dependencies that have been submitted using the dependency submission API.
Code scanning have shipped an API for repositories to programmatically enable code scanning default setup with CodeQL.
The API can be used to:
- Onboard a repository to default setup:
gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=configured - Specify which CodeQL query suite to use in the default setup configuration:
gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f query_suite=extended - View the current default setup configuration for a repository:
gh api /repos/[org]/[repo-name]/code-scanning/default-setup - Offboard a repository from default setup:
gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=not-configured
When you onboard a repository via the API, you will recieve a workflow run ID which can be used to monitor the setup progress. This can be used to see the status and conclusion of the run: gh api repos/[org-name]/[repo-name]/actions/runs/[run-id] --jq '.status, .conclusion'
{
"state": "configured",
"languages": ["javascript", "ruby"],
"query_suite": "default",
"updated_at": "2023-02-24T20:00:42Z"
}For more information, see "Get the code scanning default setup configuration" and "Update the code scanning default setup configuration".
You can now enable the "security extended" query suite for repositories using code scanning default setup with CodeQL. This query suite can be selected during set up, or changed at any time by viewing and editing the CodeQL configuration.
Code scanning's default query suites have been carefully designed to ensure that they look for the security issues most relevant to developers, whilst also minimizing the occurrence of false positive results. However, if you and you developers are interested in seeing a wider range of alerts you can enable the security extended query suite. This suite includes the same queries as in the default query suite, plus:
- extra queries with slightly lower severity and precision.
- extra experimental queries.
If you enable the security extended suite you may see more CodeQL alerts in your repository and on pull requests. For more information, see "About code scanning alerts".
Read more about code scanning default setup.
Enabling CodeQL analysis with code scanning default setup for eligible repositories in your organization is now as easy as a single click from the organization’s settings page or a single API call.
You can use code scanning default setup to enable CodeQL analysis for pull requests and pushes on eligible repositories without committing any workflow files. Currently, this feature is only available for repositories that use GitHub Actions and it supports analysis of JavaScript/TypeScript, Python and Ruby. We plan to add support for additional languages soon.
To help you identify which repositories are eligible for the “enable all” feature, two new security coverage filters have been added:
code-scanning-default-setup: returns a list of enabled, eligible or not eligible repositoriesadvanced-security: returns a list of repositories with GitHub Advanced Security enabled or not enabled
This feature has been released as a public beta on GitHub.com and will also be available as a public beta on GitHub Enterprise Server 3.9.
Learn more about configuring code scanning at scale using CodeQL and the “Enable or disable a security feature for an organization” REST API
We announced two weeks ago that we are changing how you receive notifications for secret scanning alerts. From today, those changes are in effect.
What action should I take?
If you are a repository administrator, organization owner, security manager, or user with read access to secret scanning alerts:
- Watch your repositories of interest by choosing "All activity" or "Security alerts." This helps you choose what events GitHub will notify you about.
- In your user notification settings, you must choose "Email" in the "Watching" section. This tells GitHub how to notify you. Secret scanning only supports email notifications at this time.
If you're a commit author:
As long as you are not ignoring the repository in your watch settings, commit authors always receive notifications for new secrets that are leaked. This means you receive a notification for any secret committed after an initial historical scan has run on the repository.
Learn more
Code scanning is now using a new way of analysing and displaying alerts on pull requests. The change ensures code scanning only shows accurate and relevant alerts for the pull request.
Previously, code scanning presented all alerts unique to the pull request branch, even if they were unrelated to the code changes the pull request introduced. Now, the tool reports only alerts inside the lines of code that the pull request has changed, which makes it easier to fix these contextualised alerts in a timely manner.
The complete list of code scanning alerts on the pull request branch can be seen on the Security tab of the repository.
In addition, code scanning will no longer show fixed alerts on pull requests. Instead, you can check whether an alert has been fixed by your pull request on the Security tab of the repository by using search filters: pr:111 tool:CodeQL. If you fix an alert in the initial commit in the pull request, it will not be present on the PR branch.
This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.10.
Learn more about viewing an alert on your pull request.
Learn more about GitHub Advanced Security.
If you use versioned reusable workflows in GitHub Actions, you can now use Dependabot version updates to keep those workflows up-to-date in your repositories! This is useful for anyone using reusable workflows and pinning references to them from the caller workflow, either by commit SHA or by tag.
Dependency graph and Dependabot now parse and update package-lock.json files set with lockfileVersion: 3, which is used by npm v9. Users will receive Dependabot alerts for dependencies with known vulnerabilities.
Code scanning configurations can now be deleted from the code scanning alert page. This could be used to delete stale configurations causing alerts to remain open, or delete old configurations which are no longer used.
Code scanning can be configured to use different tools, target different languages, or even analyze different parts of the codebase in the same repository. In certain circumstances more than one of these configurations may produce the same alert. However, if one of the configurations is no longer used and becomes 'stale' you may find that the alert is fixed in one configuration but not in the stale configuration, which is potentially confusing. Today we are releasing a new feature that allows you to easily delete stale configurations which cause alerts to remain open after they've been fixed.
In the code scanning alert page, the counter in the 'Affected branches' sidebar shows the number of configurations for the branch. Click a branch to view the configuration details, and delete configurations as required. A configuration is deleted for a branch, so may have an impact on the status of other alerts on the same branch. When a configuration is deleted, a timeline entry is recorded on the alert, and repositories in an organization also record an audit log entry. If a configuration is deleted by mistake, re-run the analysis to update the alert and reinstate the configuration.
Read more about removing stale code scanning configurations and alerts.
Today we have released multi-repository variant analysis for CodeQL in public beta to help the OSS security community power up their research with CodeQL.
CodeQL is the static code analysis engine that powers GitHub code scanning. Out of the box, CodeQL is able to find many different types of security vulnerability and flag them up in pull requests.
But one of CodeQL’s superpowers is its versatility and customizability: you can use it to find virtually any pattern in source code. As such, it’s a great tool for finding new types of vulnerabilities – once you’ve identified an interesting pattern, model it as a CodeQL query, and then run it against your repository to find all occurrences of that pattern! But most vulnerabilities are relevant to many codebases. Wouldn’t it be amazing if you could easily run your query against many repos at the same time? Well, now you can with multi-repository variant analysis — which we’ve just shipped in public beta!
This new feature will allow security researchers to run CodeQL analyses against large numbers of repos, straight from the CodeQL extension for VS Code, making it possible to identify new types of security vulnerabilities in the most popular open-source codebases.
Checkout the CodeQL for VS Code documentation to get learn how to get started with multi-repository variant analysis. We'd also love to hear your feedback on this GitHub community discussion.
You can now designate different types of credits to users who contribute to GitHub security advisories.
These new credit types mirror those in the CVE 5.0 schema:
finderreporteranalystcoordinatorremediation developerremediation reviewerremediation verifiertoolsponsorother
Going forward, GitHub will automatically apply the the reporter credit type to anyone credited after submitting a private vulnerability report and the analyst type to anyone credited after submitting an edit to the global Advisory Database. We've also retroactively applied those labels to previously credited individuals who took those actions.
Further reading:
Dependency graph no longer ingests go.sum files for Go repositories, and Dependabot no longer alerts on vulnerabilities for dependencies found in go.sum files. Dependencies previously ingested from go.sum files have been removed from the dependency graph for all repositories on github.com.
go.sum files are not lock files but a log of all packages downloaded by Go when building a project. They may include multiple versions of a dependency, which may result in false positive Dependabot alerts for a vulnerable version that isn't actually used in the project.
Dependency graph continues to support go.mod files, the recommended format for Go projects. Use Go 1.17 or higher to ensure your go.mod file is a comprehensive view of all direct and transitive dependencies.
We are changing how you receive notifications of secret scanning alerts. Previously, to receive secret scanning alert notifications, you had to watch a repository with "All activity" or "Security alerts" and enable Dependabot email alerts to receive notifications.
Beginning March 16, here are the steps you need to take to continue to receive notifications from secret scanning:
- (No change required) Watch repositories of interest by choosing "All activity" or "Security alerts". This help you choose what events GitHub will notify you about.
- (Action needed) In your user notification settings, choose "Email" in the "Watching" section. This tells GitHub how to notify you. Secret scanning only supports email notifications at this time.
Code scanning default setup can now be easily enabled for a single repository from the slide-out panel on your organization's "Security Coverage" page, without needing to navigate to the repository's "Settings" tab.
The feature automatically detects the languages in your repository and enables analysis for pull requests and pushes, without requiring you to commit a workflow file. Default setup currently supports JavaScript, Python, and Ruby, with more languages to come. The feature is available for repositories using GitHub Actions and can be accessed by organization owners, repository administrators and security managers. Expect one-click enablement functionality for all organization repositories to be rolled out next.
This has shipped as a public beta to GitHub.com and will be available in GitHub Enterprise Server 3.9.
Learn more about automatically setting up code scanning for a repository and send us your feedback
Learn more about GitHub Advanced Security