Subscribe to all “security-and-compliance” 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

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:

For more information about using the CodeQL model editor, see Using the CodeQL model editor.

See more

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?

Create or edit a custom rule

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?

How do I provide feedback?

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

See more

Dependency review now works with your dependencies from the dependency submission API. Dependency review enforces policies around vulnerabilities and acceptable licenses in the pull request. Previously, dependency review could not be used with another feature of the dependency graph called the dependency submission API. The dependency submission API helps developers get a more accurate set of transitive dependencies, particularly for complex ecosystems like Gradle or Scala which require a build to resolve all transitive dependencies.

To take advantage of this improvement, update to the latest version of the dependency review action, or follow the instructions in our documentation.

For more information, see our documentation about dependency review, the dependency submission API, and some best practices for using dependency review and the dependency submission API together.

See more

Code scanning with CodeQL now supports Java codebases that use Project Lombok. Previously, code scanning users were able to scan Java applications that contained Lombok code, but all the contents of files containing Lombok code were either skipped or users had to apply a workaround to prepare the applications for scanning. The improved support means that code with Lombok features will be automatically scanned without requiring any workaround.

As more code will now be analyzed by the CodeQL engine, we can establish more accurate data flow (or lack thereof) through Lombok code. This might have an impact on the number of alerts produced by a scan. The most common scenario is that additional alerts appear in the newly-analyzed code. Conversely, there is a very small chance that some existing alerts are closed.

Improved support for Java applications built using Lombok is available for code scanning users on starting today and GitHub Enterprise Server users starting with 3.11. CodeQL CLI will provide out of the box support starting with the upcoming version 2.14.4. Security researchers can set up the CodeQL CLI and VS Code extension by following these instructions.

See more

The enterprise and organization level audit logs now record an event when the setting for automatic validity checks for secrets is enabled or disabled. This data helps GitHub Advanced Security customers understand actions taken on their secret scanning alerts for security and compliance audits.

See more

Dependabot version updates help you keep your dependencies up-to-date by opening pull requests when dependencies can be upgraded. With today's release, you can now use flexible grouping options in dependabot.yml to take control of how Dependabot structures its pull requests to make them more mergeable for you based on your context. Whether you'd like to simply update as many dependencies at once as possible (patterns: *) or minimize the risk of breaking changes (dependency-type: development or update-types: "patch"), there are grouping options for you.

Until today, Dependabot would always open individual pull requests for every dependency update in accordance with your configuration in dependabot.yml. Not only can this result in a large number of Dependabot pull requests, but there are some dependencies which must be updated in tandem with each other or the update will fail. In these cases, the individual Dependabot pull requests would always fail until you manually intervened to do the update.

The available grouping options are:

  • patterns, which will match based on package names
  • dependency-type, which will group based on development or production dependencies, for ecosystems where this is supported, and
  • update-types, which will group based on SemVer level update

At this time, grouping is not available for security updates or Dependabot alerts.

Learn more about grouping configuration options here

See more

Dependabot can now open pull requests to resolve alerts for your Gradle dependencies! If you have used the dependency submission API to upload your Gradle dependencies to the dependency graph and are receiving Dependabot alerts for those dependencies, Dependabot will now try to open a pull request to resolve them automatically if you have security updates enabled for your repository.

See more

In addition to scanning push and pull requests, code scanning default setup now also analyzes repositories on a weekly schedule. This ensures that a scan with the most recent version of CodeQL is run regularly on your code, better protecting both active and inactive repositories. This allows users to always benefit from CodeQL engine and query improvements which are continuously released, and which could uncover new potential vulnerabilities.

When setting up code scanning, the fixed time for the weekly scan is randomly chosen. The scan will take place at the same time every week, and the schedule is displayed after the setup is completed, so you can easily see when the next scheduled analysis will occur. The scheduled analysis will be automatically disabled if a repository has seen no activity for 6 months. Opening a PR or pushing to the repo will re-enable the scheduled analysis.

Screenshot that shows the weekly scheduled scan

This has shipped to and will be released with GitHub Enterprise Server 3.11.

See more

If you are using Dependabot grouped version updates (currently in public beta), you can now group your pull requests by semantic version update level. This addition is designed to help reduce the risk of introducing a breaking change through an update.
To use this new functionality, add a new update-types key in your group rule, as shown below:

    - "@angular*"
    - "minor"
    - "patch"

The update-types key accepts values "major," "minor," and "patch," following the SemVer structure of major.minor.patch.

This new key works alongside existing grouping parameters such as patterns, dependency-type, and exclude-patterns, allowing you to fine-tune the grouped pull requests that Dependabot creates for you!

Learn more about configuring grouped Dependabot version updates

See more

As of August 17, 2023, Dependabot updates no longer support Python 3.6 or 3.7, which have reached their end-of-life. If your code uses these versions, Dependabot will no longer be able to open pull requests in your repository and will log errors. Update to at least Python 3.8 to ensure your code is secure and Dependabot can still run.

This change impacts Dependabot pull requests only – you will continue to receive Dependabot alerts for dependencies with known vulnerabilities. To resolve the alert, you can upgrade the affected package yourself manually.

View the official release cycle for Python for more information on supported versions.

Learn more about supported package managers for Dependabot

See more

Users with secret scanning enabled on their free public repositories will now receive alerts for any potential secrets exposed in an issue’s title, description, or comments, including historical revisions. Alerts can be viewed within the UI or the REST API.

New issues are being scanned starting today and existing issues will be scanned over the coming weeks. You can expect all public repositories to be fully scanned by September 1, 2023.

See more

We have released a new API for people who write custom CodeQL queries which make use of dataflow analysis. The new API offers additional flexibility, improvements that prevent common pitfalls with the old API, and improves query evaluation performance by 5%. Whether you’re writing CodeQL queries for personal interest, or are participating in the bounty programme to help us secure the world’s code: this post will help you move from the old API to the new one.

This API change is relevant only for users who write their own custom CodeQL queries. Code scanning users who use GitHub’s standard CodeQL query suites will not need to make any changes.

With the introduction of the new dataflow API, the old API will be deprecated. The old API will continue to work until December 2024; the CodeQL CLI will start emitting deprecation warnings in December 2023.

To demonstrate how to update CodeQL queries from the old to the new API, consider this example query which uses the soon-to-be-deprecated API:

class SensitiveLoggerConfiguration extends TaintTracking::Configuration {
  SensitiveLoggerConfiguration() { this = "SensitiveLoggerConfiguration" } // 6: characteristic predicate with dummy string value (see below)

  override predicate isSource(DataFlow::Node source) { source.asExpr() instanceof CredentialExpr }

  override predicate isSink(DataFlow::Node sink) { sinkNode(sink, "log-injection") }

  override predicate isSanitizer(DataFlow::Node sanitizer) {
    sanitizer.asExpr() instanceof LiveLiteral or
    sanitizer.getType() instanceof PrimitiveType or
    sanitizer.getType() instanceof BoxedType or
    sanitizer.getType() instanceof NumberType or
    sanitizer.getType() instanceof TypeType

  override predicate isSanitizerIn(DataFlow::Node node) { this.isSource(node) }

import DataFlow::PathGraph

from SensitiveLoggerConfiguration cfg, DataFlow::PathNode source, DataFlow::PathNode sink
where cfg.hasFlowPath(source, sink)
select sink.getNode(), source, sink, "This $@ is written to a log file.",
  "potentially sensitive information"

To convert the query to the new API:

  1. You use a module instead of a class. A CodeQL module does not extend anything, it instead implements a signature. For both data flow and taint tracking configurations this is DataFlow::ConfigSig or DataFlow::StateConfigSigif FlowState is needed.
  2. Previously, you would choose between data flow or taint tracking by extending DataFlow::Configuration or TaintTracking::Configuration. Instead, now you define your data or taint flow by instantiating either the DataFlow::Global<..> or TaintTracking::Global<..> parameterized modules with your implementation of the shared signature and this is where the choice between data flow and taint tracking is made.
  3. Predicates no longer override anything, because you are defining a module.
  4. The concepts of sanitizers and barriers are now unified under isBarrier and it applies to both taint tracking and data flow configurations. You must use isBarrier instead of isSanitizer and isBarrierIn instead of isSanitizerIn.
  5. Similarly, instead of the taint tracking predicate isAdditionalTaintStep you use isAdditionalFlowStep .
  6. A characteristic predicate with a dummy string value is no longer needed.
  7. Do not use the generic DataFlow::PathGraph. Instead, the PathGraph will be imported directly from the module you are using. For example, SensitiveLoggerFlow::PathGraph in the updated version of the example query below.
  8. Similar to the above, you’ll use the PathNode type from the resulting module and not from DataFlow.
  9. Since you no longer have a configuration class, you’ll use the module directly in the from and where clauses. Instead of using e.g. cfg.hasFlowPath or cfg.hasFlow from a configuration object cfg, you’ll use flowPath or flow from the module you’re working with.

Taking all of the above changes into account, here’s what the updated query looks like:

module SensitiveLoggerConfig implements DataFlow::ConfigSig {  // 1: module always implements DataFlow::ConfigSig or DataFlow::StateConfigSig
  predicate isSource(DataFlow::Node source) { source.asExpr() instanceof CredentialExpr } // 3: no need to specify 'override'
  predicate isSink(DataFlow::Node sink) { sinkNode(sink, "log-injection") }

  predicate isBarrier(DataFlow::Node sanitizer) {  // 4: 'isBarrier' replaces 'isSanitizer'
    sanitizer.asExpr() instanceof LiveLiteral or
    sanitizer.getType() instanceof PrimitiveType or
    sanitizer.getType() instanceof BoxedType or
    sanitizer.getType() instanceof NumberType or
    sanitizer.getType() instanceof TypeType

  predicate isBarrierIn(DataFlow::Node node) { isSource(node) } // 4: isBarrierIn instead of isSanitizerIn


module SensitiveLoggerFlow = TaintTracking::Global<SensitiveLoggerConfig>; // 2: TaintTracking selected 

import SensitiveLoggerFlow::PathGraph  // 7: the PathGraph specific to the module you are using

from SensitiveLoggerFlow::PathNode source, SensitiveLoggerFlow::PathNode sink  // 8 & 9: using the module directly
where SensitiveLoggerFlow::flowPath(source, sink)  // 9: using the flowPath from the module 
select sink.getNode(), source, sink, "This $@ is written to a log file.", source.getNode(),
  "potentially sensitive information"

While not covered in this example, you can also implement the DataFlow::StateConfigSig signature if flow-state is needed. You then instantiate DataFlow::GlobalWithState or TaintTracking::GlobalWithState with your implementation of that signature. Another change specific to flow-state is that instead of using DataFlow::FlowState, you now define a FlowState class as a member of the module. This is useful for using types other than string as the state (e.g. integers, booleans). An example of this implementation can be found here.

This functionality is available with CodeQL version 2.13.0. If you would like to get started with writing your own custom CodeQL queries, follow these instructions to get started with the CodeQL CLI and the VS Code extension.

See more

GitHub Advanced Security customers can now perform on-demand validity checks for supported partner patterns, and the alert index view now shows if a secret is active. This builds on our release of enabling automatic validation checks for supported partner patterns back in April.

When the “Automatically verify if a secret is valid” setting is enabled on a repository, users will see a “Verify secret” button on the alert page. This sends the secret to our relevant partner provider to see if the secret is active and updates the status on the alert and index pages.

screenshot of an adafruit io key alert with a verify secret button

As we work with our partners to add support for more secrets, we'll update the "Validity check" column in the documented supported secrets list.

See more

If you are using the Dependabot grouped version updates feature (currently in public beta), you can now tell Dependabot to ignore updates in the group (similar to how you can do it for Dependabot's individual updates). While closing a grouped pull request will still not create ignore conditions, you can use Dependabot comment commands to tell Dependabot to ignore certain updates in the group – either a specific minor update, a specific major update, or all updates for one dependency.

On a grouped pull request, you can now also tell Dependabot to stop ignoring certain updates that you have already ignored. By commenting @dependabot unignore, you can specify either to stop ignoring a specific range of updates, all updates for a specific dependency, or all updates for every dependency in the group. Dependabot will now also list in the pull request body all the ignore conditions it used to build the pull request. Alternatively, you can comment @dependabot show <dependency-name> ignore conditions and Dependabot will list the ignore conditions for that dependency.

For more information on Dependabot ignore conditions and chat commands, please see the documentation.

See more

If you are using the Dependabot grouped version updates feature (currently in public beta), you can now group your pull requests by dependency type in ecosystems that support this. Instead of listing all the dependencies by name or pattern for your groups, you can now also use the dependency-type key (set to either "production" or "development") to create groups based on dependency type. Then, on your version updates schedule, Dependabot will try to open one pull request to update all available dependencies of that type.

For more information on how to use this feature, check out our documentation on configuring groups for Dependabot pull requests.

See more

Secret scanning's push protection feature prevents supported secrets from being pushed into repositories, and has to date been enabled at the repository, organization, or enterprise level.

Now, everyone across GitHub can enable push protection for themselves within your individual settings. This ensures your pushes are protected whenever you push to a public repository on GitHub, without relying on that repository to have push protection enabled.

To opt in, go to the "Code security and analysis" section of your personal settings. Next to "Push protection for yourself", click Enable.

GitHub will enable push protection for all GitHub Free individuals by default in January, 2024.

See more

The code scanning REST API updated_at field has been improved to help you review your most recently changed alerts.

The updated_at timestamp now returns the alert's most recent state change on the branch that you requested. We consider a state change to be a significant event, including an alert being introduced, fixed, dismissed, reopened or reintroduced. This is implemented in both the repo API and org API so it can be used consistently at scale.

Previously, the updated_at timestamp changed whenever an alert was found in an analysis or the alert state changed, and so was updated very regularly. This improvement lets you efficiently use updated_at to sort and focus on your most recently changed alerts.

The code scanning REST API list alerts endpoints code-scanning/alerts returns the value for the default branch, unless another branch is specificed. The alert endpoint code-scanning/alerts/{alert_number} reports at the alert level, so will return the maximum value for the alert across all branches.

This is now live on for the repository level API. This will be live for the organization level API over the next few days because it requires data reindexing. This will ship to GitHub Enterprise Server version 3.11. For more information, see the code scanning REST API documentation.

See more