[ricardosrib]

Description

Consolidates six open Dependabot PRs into a single branch so they can be reviewed and merged together.

GitHub Actions (CI only) — supersedes #441

• actions/checkout 4 → 7
• astral-sh/setup-uv 3 → 7
• actions/setup-python 4 → 7
• actions/upload-artifact 4 → 7
• actions/setup-node 4 → 7
• dependabot/fetch-metadata 2 → 3
• actions/create-github-app-token 1 → 3
• pypa/gh-action-pypi-publish 1.14.2 → 1.14.3

Locked dependencies (uv.lock only) — supersedes #440, #431, #425, #423, #403

• pyasn1 0.6.4 → 0.6.5 — transitive (via cryptography); DoS-class fixes
• litellm 1.99.0 → 1.100.4 — dev dependency; privilege-escalation fix affecting the litellm proxy server (not the client-side API)
• filelock 3.32.5 → 4.2.1 — transitive only (not imported by the SDK); major bump, no CVE
• virtualenv 21.7.13 → 21.14.9 — build/dev tool; shell-activation fixes
• oauthlib 3.3.1 → 4.0.0 — used client-side via requests-oauthlib; fixes device-flow / token-revocation issues

No runtime constraints in pyproject.toml change — all five lock bumps are transitive or dev-only. The virtualenv upgrade also pulls python-discovery 1.6.0 → 1.9.4 and adds a packaging dependency edge, both required by the new virtualenv release.

The individual bumps were regenerated with targeted uv lock --upgrade-package <pkg>==<version> rather than cherry-picked, since all five Dependabot PRs touch uv.lock and would conflict. uv lock --check passes.

Related Issue

N/A

Type of Change

Please check the relevant option:

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Code refactoring
• Dependency update

How to Test

1. CI gates run on this PR (the decisive check, since the Actions bumps are exercised only when the workflows run on the new versions): check-version-bump (version must stay unchanged), checks (uv lock --check → uv sync --all-extras → pre-commit), test, codeql, reuse, commit-validation, integration-tests.
2. Locally: uv lock --check (verifies the lock matches pyproject.toml) and uv sync --all-extras.
3. Runtime smoke check of the oauthlib 4.0 client path (the only non-trivial runtime change): drive an OAuth2 client-credentials flow through the SDK and confirm token acquisition + an authenticated call succeed.

Expected result: all CI checks green; uv lock --check reports the lock up to date; OAuth2 client-credentials calls return 200.

Checklist

Before submitting your PR, please review and check the following:

• I have read the Contributing Guidelines
• I have verified that my changes solve the issue
• I have added/updated automated tests to cover my changes — N/A (dependency bumps, no source changes; covered by existing suite in CI)
• All tests pass locally — uv lock --check passes locally; the full suite runs in CI
• I have verified that my code follows the Code Guidelines — N/A, no source code changed
• I have updated documentation (if applicable) — N/A
• I have added type hints for all public APIs — N/A, no source code changed
• My code does not contain sensitive information (credentials, tokens, etc.)
• I have followed Conventional Commits for commit messages
• (New modules only) I have attached e2e evidence showing the module working against a real BTP service — N/A
• (Security-sensitive changes only) I have run /security-review and addressed all ❌ findings — N/A, no source code changed (these bumps address upstream advisories; no SDK logic is modified)

Breaking Changes

None for SDK consumers. oauthlib 4.0.0 and filelock 4.x are major upstream releases, but:

• filelock is a transitive dependency and is not imported by the SDK.
• The oauthlib 4.0.0 breaking changes (JSONP removed from the revocation endpoint; grant_type validated before authentication) are server-side; the SDK uses oauthlib only as a client, and requests-oauthlib>=2.0.0,<3 resolves against 4.x.

Additional Notes

• The package version in pyproject.toml is intentionally left unchanged — the repo's check-version-bump workflow rejects manual bumps; versioning is handled by the release pipeline.
• uv.lock is not shipped to SDK consumers (they resolve from pyproject.toml constraints), so these lock bumps primarily harden the SDK's own CI/dev environment.

[ricardosrib]

Security Review: #449 — chore(deps): batch dependency bumps (#441, #440, #431, #425, #423, #403)

Author: ricardosrib Branch: chore/dependency-bumps-batch → main
Verdict: ✅ No security issues

---

#	Criterion	Status	Finding
S1	Tenant subdomain validation	➖ N/A	No code accepting tenant/subdomain parameters changed
S2	URL construction (structured, not str.replace)	➖ N/A	No URL-building code changed
S3	Credential emptiness checks	➖ N/A	No credential-reading code changed
S4	JWT tokens verified before trust	➖ N/A	No JWT handling code changed
S5	No hardcoded credentials/secrets	✅ Pass	Workflow files reference only ${{ secrets.* }} expressions — no literals
S6	Sensitive data not logged	➖ N/A	No logger calls changed
S7	No path traversal from external input	➖ N/A	No filesystem code changed
S8	HTTP base URLs validated	➖ N/A	No HTTP request code changed
S9	Multi-tenant cache isolation	➖ N/A	No cache or in-memory state changed
S10	New/updated dependencies checked for CVEs	✅ Pass	See note below
S11	No verify=False in HTTP calls	➖ N/A	No HTTP calls changed
S12	Audit log for mutating tenant operations	➖ N/A	No mutating operations added

---

✅ Things Done Well

• S10 — CVE direction is strictly positive. Every lock bump either resolves known advisories (pyasn1 4×HIGH, litellm CVSS 9.9, oauthlib 2×HIGH, virtualenv 2×HIGH) or is a benign transitive pull (filelock, python-discovery). No new CVEs are introduced. pyproject.toml runtime constraints are unchanged — consumers are unaffected.
• S5 — Workflow credential hygiene maintained. All secrets (CLOUD_SDK_BOT_APP_ID, CLOUD_SDK_BOT_PRIVATE_KEY, GITHUB_TOKEN) continue to be referenced via ${{ secrets.* }} expressions only. No literals introduced.
• GitHub Actions provenance. All bumped actions are first-party (actions/*) or well-established official publishers (astral-sh/setup-uv, pypa/gh-action-pypi-publish, dependabot/fetch-metadata). No third-party or forked actions introduced.
• pypa/gh-action-pypi-publish 1.14.2 → 1.14.3 specifically resolves the critical CA chain revocation issue in the Sigstore/Trusted Publishing path — a supply-chain security improvement to the SDK's own release pipeline.
• No new workflow permissions added. Permission scopes in all 13 workflow files are unchanged between old and new versions.

❌ Blocking Issues

None.

⚠️ Non-Blocking Suggestions

None.

Unit Test Coverage Gaps

None — no criteria flagged ❌ or ⚠️; no test stubs needed.

---

This PR is clear to merge from a security standpoint. The only outstanding gate is CI going green (in particular the GitHub Actions jobs running on the newly bumped action versions, and a re-run of the flaky test_search_memories integration test).