Bump the actions group with 2 updates

[dependabot]

Bumps the actions group with 2 updates: github/codeql-action and ossf/scorecard-action.

Updates github/codeql-action from 4.37.2 to 4.37.3

Release notes

Sourced from github/codeql-action's releases.

v4.37.3

No user facing changes.

Changelog

Sourced from github/codeql-action's changelog.

4.37.3 - 22 Jul 2026

No user facing changes.

Commits

• e4fba86 Merge pull request #4031 from github/update-v4.37.3-72f6a9da0
• fb50ab5 Update changelog for v4.37.3
• 72f6a9d Merge pull request #4030 from github/mbg/fix/no-proxy
• 3b5ee58 Use default request options instead of undefined
• bfb6be4 Merge pull request #4028 from github/mergeback/v4.37.2-to-main-e0647621
• 526ab84 Rebuild
• d6217b9 Update changelog and version after v4.37.2
• See full diff in compare view

Updates ossf/scorecard-action from 2.4.3 to 2.4.4

Release notes

Sourced from ossf/scorecard-action's releases.

v2.4.4

What's Changed

This update bumps the Scorecard version to the v5.5.0 release. For a complete list of changes, please refer to the Scorecard v5.4.0 release notes and the Scorecard v5.5.0 release notes.

• log POST failures instead of failing entire action by @​spencerschrock in ossf/scorecard-action#1625

Full Changelog: ossf/scorecard-action@v2.4.3...v2.4.4

Commits

• 2d11466 Bump action tag for v2.4.4 release (#1688)
• 1bd3285 🌱 Bump the docker-images group across 1 directory with 2 updates (#1...
• 913edce 🌱 Bump github.com/containerd/containerd from 1.7.32 to 1.7.33 (#1671)
• 0957b8f 🌱 Bump golang.org/x/net from 0.56.0 to 0.57.0 (#1680)
• f0061eb 🌱 Bump google.golang.org/grpc from 1.81.1 to 1.82.1 (#1687)
• 20ee732 🌱 Bump github.com/sigstore/cosign/v2 from 2.6.3 to 2.6.4 (#1685)
• 9f295ef 🌱 Bump the github-actions group with 6 updates (#1686)
• 69bf556 🌱 Bump github.com/sigstore/sigstore-go from 1.1.4 to 1.2.0 (#1681)
• 94e8b96 🌱 Bump github.com/sigstore/rekor from 1.5.0 to 1.5.2 (#1673)
• c7a1b37 🌱 Bump github.com/sigstore/fulcio from 1.8.5 to 1.8.6 (#1675)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[semgrep-code-mongodb]

Semgrep identified an issue in your code:

Upload to code-scanning uses github/codeql-action/upload-sarif@v4.37.3, which is a movable tag rather than an exact commit. If that tag is repointed, the workflow could silently run attacker-controlled code with this job's access.

More details about this

github/codeql-action/upload-sarif@v4.37.3 pulls the upload-sarif action by tag name, not by a full 40-character commit SHA. If someone who can publish github/codeql-action retags v4.37.3 to a different commit, this Upload to code-scanning step would run that new code with this workflow's permissions and access to results.sarif.

A plausible attack looks like this:

1. An attacker compromises the action's release process or maintainer account for github/codeql-action.
2. They move the v4.37.3 tag to a commit that adds malicious code inside upload-sarif.
3. On the next workflow run, uses: github/codeql-action/upload-sarif@v4.37.3 fetches the attacker's commit because the workflow trusts the tag name.
4. That malicious action runs in the Upload to code-scanning step and can read files available in the job, including results.sarif, inspect environment values, and use the job's GitHub token to send data out or make repository API calls.
5. From the repository's point of view, this happens during a normal scan upload, so the malicious behavior is easy to miss.

To resolve this comment:

✨ Commit fix suggestion

1. Replace the mutable version reference in the uses: line with a full 40-character commit SHA for the same github/codeql-action release.
   Change github/codeql-action/upload-sarif@v4.37.3 to github/codeql-action/upload-sarif@<40-character-commit-sha>.

2. Keep the human-readable version as a trailing comment so future upgrades are easier to track, for example:
   uses: github/codeql-action/upload-sarif@<40-character-commit-sha> # v4.37.3

3. Get the SHA from the exact upstream release or tag you intend to trust, and make sure it is the commit that v4.37.3 currently points to.
   Pinning to a commit SHA prevents the action owner from silently moving the tag to different code later.

4. Update any nearby workflow comment that says this reference is immutable, because @v4.37.3 is still a movable tag and does not satisfy this rule unless it is replaced with the full commit SHA.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

• Fix the code
• Reply /fp $reason (if security gap doesn’t exist)
• Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
• Reply /other $reason (e.g., test-only)

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-mongodb]

Semgrep identified an issue in your code:

github/codeql-action/analyze@v4.37.3 uses a movable tag, so this CI step could run attacker-controlled code if that tag is repointed.

More details about this

Perform CodeQL Analysis pulls github/codeql-action/analyze@v4.37.3, which is a version tag, not a full 40-character commit SHA. If the v4.37.3 tag is ever moved, this workflow would silently run different code during CI with this job's contents: read and security-events: write permissions.

A plausible attack looks like this:

1. An attacker compromises the github/codeql-action release process or the upstream account that controls the v4.37.3 tag.
2. They repoint analyze@v4.37.3 to a new commit that adds malicious logic to the action.
3. The next time this analyze job runs, the Perform CodeQL Analysis step fetches and executes that new commit automatically because uses: github/codeql-action/analyze@v4.37.3 trusts the movable tag.
4. That malicious action code can read the checked-out repository contents available in the job and misuse the workflow token permissions, for example by altering uploaded code scanning results via security-events: write or exfiltrating source code over the network during the action run.

Because the reference here is mutable, the code executed in CI can change without any change to this repository.

To resolve this comment:

✨ Commit fix suggestion

1. Replace the mutable version reference in the uses: line with a full 40-character commit SHA for the same action release.
   Change github/codeql-action/analyze@v4.37.3 to github/codeql-action/analyze@<full-commit-sha> # v4.37.3.

2. Resolve the SHA from the action’s v4.37.3 release page or release commit, and use that exact commit hash instead of the tag.
   The goal is to pin uses: to a value like github/codeql-action/analyze@0123456789abcdef0123456789abcdef01234567 # v4.37.3.

3. Keep the trailing version comment after the SHA so future updates are easier to review.
   Pinning to a commit SHA prevents a tag like v4.37.3 from being silently moved to different code later.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

• Fix the code
• Reply /fp $reason (if security gap doesn’t exist)
• Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
• Reply /other $reason (e.g., test-only)

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-mongodb]

Semgrep identified an issue in your code:

github/codeql-action/init@v4.37.3 uses a movable ref, so repointing that tag could make this workflow run attacker-controlled action code.

More details about this

github/codeql-action/init is pulled with the tag v4.37.3 instead of a full 40-character commit SHA. If the v4.37.3 ref is ever repointed upstream, this Initialize CodeQL step would run different code in your workflow with this job's contents: read and security-events: write permissions.

A plausible attack looks like this:

1. An attacker compromises the github/codeql-action release process or gains permission to move the v4.37.3 ref.
2. They repoint github/codeql-action/init@v4.37.3 to a malicious commit that still looks like a normal CodeQL init step.
3. When this analyze job runs on master, release/*, feature/*, or the weekly schedule, GitHub downloads and executes that new action code in the Initialize CodeQL step.
4. That malicious action can read the checked-out repository contents and use the workflow token's security-events: write access to tamper with CodeQL results or hide real findings before the Perform CodeQL Analysis step runs.

To resolve this comment:

✨ Commit fix suggestion

1. Replace the mutable action reference github/codeql-action/init@v4.37.3 with a full 40-character commit SHA for that exact release, and keep the readable version as a trailing comment, for example uses: github/codeql-action/init@<40-char-sha> # v4.37.3.

2. Update the matching CodeQL step references in the same workflow to use the same pinning style, such as github/codeql-action/analyze@<40-char-sha> # v4.37.3, so every third-party action is locked to an immutable revision.

3. Add a short comment near these steps explaining that actions are pinned to full commit SHAs because tags like v4.37.3 can be moved to different code later. This prevents unreviewed upstream changes from being pulled into the workflow without a code change in this repository.

4. Get the correct SHA from the action’s release page or repository for v4.37.3, and make sure the SHA belongs to the exact version you intend to use.

Alternatively, if you must keep a version label visible for maintenance, keep the SHA in uses: and put the version only in a comment like # v4.37.3, not in the action reference itself.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

• Fix the code
• Reply /fp $reason (if security gap doesn’t exist)
• Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
• Reply /other $reason (e.g., test-only)

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[mongodb-drivers-pr-bot]

🧪 Performance Results

Commit SHA: dee4a64

The following benchmark tests for version 6a694f03c2276600076433b6 had statistically significant changes (i.e., |z-score| > 1.96):

Benchmark	Measurement	% Change	Patch Value	Stable Region	H-Score	Z-Score
BenchmarkBSONFlatDocumentDecoding	ops_per_second_min	-46.8570	1189.4651	Avg: 2238.2351 Med: 2371.7168 Stdev: 447.8976	0.7843	-2.3415
BenchmarkMultiInsertLargeDocument	ns_per_op	6.0712	31304744.0000	Avg: 29512948.2944 Med: 29470655.5000 Stdev: 882841.1635	0.7387	2.0296
BenchmarkBSONFlatDocumentEncoding	ops_per_second_max	3.7088	87397.3082	Avg: 84271.8324 Med: 84160.9157 Stdev: 1231.4049	0.7798	2.5381
BenchmarkSmallDocInsertOne	allocated_bytes_per_op	-0.2410	5680.0000	Avg: 5693.7232 Med: 5695.0000 Stdev: 5.0300	0.8406	-2.7283

For a comprehensive view of all microbenchmark results for this PR's commit, please check out the Evergreen perf task for this patch.

[mongodb-drivers-pr-bot]

API Change Report

No changes found!