chore(deps): take Dependabot to zero — every alert resolved, none introduced - #60

Takes https://github.com/convertcom/php-sdk/security/dependabot to zero. Every alert on the repo is resolved — not just the critical and high ones — and nothing this PR adds carries an advisory. Two commits, all checks green.

Zero, measured three ways

1. Every alert clears. 88 alerts exist on main: 79 open and 9 auto-dismissed. Each was evaluated against this branch by matching the installed version against the advisory's own vulnerable_version_range (not just "is it newer than the fix", which gets the two separate picomatch lines wrong).

The auto-dismissed nine are easy to miss: GitHub had filtered them off the Security tab, but the vulnerable versions were still in the tree. One is a critical — tar ≤ 7.5.18, GHSA-23hp-3jrh-7fpw — which never appeared as an open alert at all. So this clears two criticals: that one and handlebars GHSA-2w6w-674q-4c4q.

2. Nothing new is introduced. The branch adds 189 dependencies and removes 261, so "did we trade one set of advisories for another" is a fair question. GitHub's dependency-review API answers it against the same database Dependabot uses:

GET /repos/convertcom/php-sdk/dependency-graph/compare/main...chore/security-dependabot-critical-high

dependency changes: 450  (added 189, removed 261)
ADDED deps carrying advisories: 0
advisories carried by REMOVED deps: 90  {critical: 2, high: 27, moderate: 59, low: 2}

3. Both native auditors agree. composer audit on each lock and yarn npm audit --recursive --all report no advisories.

What changed, per manifest

composer.lock — guzzle 7.10.0 → 7.15.3, psr7 2.9.0 → 2.13.0, symfony/http-kernel 8.0.8 → 8.0.15, symfony/http-foundation 8.0.8 → 8.1.4, plus transitives. No composer.json constraint moved, so nothing changes for Packagist consumers — they resolve against their own tree.

demo/laravel/composer.lock — laravel/framework 13.1.1 → 13.24.0, league/commonmark 2.8.2 → 2.9.0, guzzle/psr7 as above, and symfony {http-kernel, mime, routing, http-foundation, cache, polyfill-intl-idn} to their patched releases.

yarn.lock — handlebars → 4.7.9, lodash-es → 4.18.1, js-yaml → 4.3.1, ip-address → 10.4.0, tar → 7.5.22, picomatch → 2.3.2 and 4.0.5, brace-expansion → 5.0.9, sigstore → 4.1.1.

packages/Utils/composer.lock — removed from version control.

Three things that need real eyes

Removing packages/Utils/composer.lock fixes rather than hides. Deleting a manifest makes its alerts disappear, so this deserves proof rather than assertion. .gitignore already lists /packages/*/composer.lock; this file predates the rule and stayed tracked, so it kept reporting a dependency set the package no longer has — stale enough that composer validate fails on it (phpunit locked at 10.5.45 against a ^11.0 constraint, and convertcom/php-sdk-types missing from the lock entirely). Resolving the package fresh from its composer.json, which is what a clean CI checkout does:

$ cd packages/Utils && composer install
phpunit/phpunit    11.5.56
guzzlehttp/guzzle  7.15.3
guzzlehttp/psr7    2.13.0
$ composer audit   → No security vulnerability advisories found.
$ composer test    → OK (148 tests, 176 assertions)

No vulnerable version exists in the real tree — the lockfile was the only thing claiming otherwise. The other eleven packages carry no lockfile, and libraries should not.

semantic-release 24 → 25, and @semantic-release/github 11 → 12 with it. This is the release path for the SDK, so it is the riskiest line in the diff. It was not optional: sigstore needs 4.1.1 but sits behind a ^3.0.0 range, so no in-range bump reaches it. It arrives via semantic-release → @semantic-release/npm → npm → libnpmpublish, and only the major bump pulls libnpmpublish 11 and sigstore ^4. The custom scripts/rollover-version-plugin.mjs was exercised directly across all six of its bump cases — patch below 9, patch rollover to minor, 2.9.9 rollover to major, refactor, breaking change, chore-only — with identical results to 24, and semantic-release --dry-run loads every configured plugin.

CI was never installing what yarn.lock says. The release job runs yarn install --immutable, but nothing pinned the package manager, so the runner's preinstalled Yarn 1.22.22 serviced it. Classic Yarn cannot read a Yarn 4 lockfile and does not recognise --immutable (it spells it --frozen-lockfile), so it re-resolved every dependency from the semver ranges and rewrote the lockfile on every run. The release log says it outright:

yarn install v1.22.22
[1/4] Resolving packages...
success Saved lockfile.

The lockfile was decorative. Fixed by committing the Yarn 4.18.0 binary under .yarn/releases and pointing yarnPath at it — see the review round below for why this rather than Corepack. Without this, the yarn.lock half of this PR would not have taken effect in CI.

Review round — what changed after @DmytroConvert's review

All three findings were reproduced and all three are fixed in 00e00ee.

1. The Corepack cliff — confirmed, and the date is exact. Node stopped distributing Corepack as of 25.0.0 (nodejs/node doc/contributing/distribution.md, History: "corepack … is no longer distributed as of Node.js 25.0.0"), and nodejs/Release schedule.json puts v26 at lts: 2026-10-28. So node-version: 'lts/*' plus corepack enable was a release job with about ten weeks of life left. (One correction to the review: nodejs/node#57617 is closed, not merged — the doc is the citation that holds.)

Fixed by removing the Corepack dependency rather than reinstalling it. yarn set version 4.18.0 --yarn-path commits the binary under .yarn/releases and sets yarnPath in .yarnrc.yml. Every yarn honours yarnPath, including the Yarn 1.22.x runners preinstall, so yarn resolves to 4.18.0 with no reference to Corepack and no coupling to which Node lts/* picks. The corepack enable step is deleted.

Measured in this repo, driving the runner's actual classic Yarn 1.22.22:

yarn --version                 → 4.18.0      (1.22.22 with yarnPath removed)
install --immutable, cold      → exit 0
install --immutable, drifted   → exit 1, YN0028 "The lockfile would have been
                                 modified by this install, which is explicitly forbidden"

So --immutable is now genuinely enforced through the same entry point that used to silently rewrite the lockfile.

Chosen over the two alternatives in the review: npm install -g corepack@latest fetches an unpinned global on every release run, which is new floating surface in a PR whose point is removing exactly that; and pinning node-version: '24' reschedules the failure to 2028-04-30 rather than removing it.

The vendored binary is byte-identical to upstream 4.18.0 from three independent sources — this file, Corepack's npm-sourced cache, and a fresh fetch of repo.yarnpkg.com/4.18.0/packages/yarnpkg-cli/bin/yarn.js:

sha256  fb8b1d20be72a0b544a35bcec4c7ed0ff55a9b173c01f191b02ba164b2051db5

Two details worth flagging. .gitignore needed .yarn/* rather than .yarn/ — git cannot re-include a path whose parent directory is excluded, so !.yarn/releases was inert under the old pattern and the binary would have been silently left out of the commit. And a new .gitattributes marks .yarn/ export-ignore so the 3.6 MB never reaches consumers through Composer's dist archive; it is scoped to .yarn/ only, since excluding anything else would change what consumers receive.

2. The .yarnrc.yml comment overstated the gate — correct. npmMinimalAgeGate is enforced at resolution, not install. Reworded to "refuse to resolve", and to spell out what it does not cover: a frozen yarn install --immutable never consults it, and a Dependabot PR arrives with the lockfile already resolved. It guards the act of choosing a version, not CI.

3. @semantic-release/release-notes-generator was locked twice — correct. package.json asked for ^14.0.0 (→ 14.1.0) while semantic-release 25 wants ^14.1.0 (→ 14.1.1). Bumped the devDependency to ^14.1.0; the lock now carries one copy, at 14.1.1.

Also restored two things yarn set version silently changed: it rewrote packageManager without the +sha512 integrity hash, and stripped the comment from .yarnrc.yml. Both are back.

Adjacent, not fixed here: the same Corepack cliff exists in convertcom/python-sdk release.yml (two jobs, lts/* + corepack enable) and convertcom/javascript-sdk qa.yml (corepack enable + corepack prepare yarn@stable). Both will break the same way on 2026-10-28 and want the same yarnPath treatment.

Also in here

npmMinimalAgeGate: 4320 (3 days) in .yarnrc.yml, matching convertcom/javascript-sdk#421 — php-sdk never got that hardening. No npmPreapprovedPackages entry is needed: this project has no internal npm dependencies (the PHP packages ship via Packagist), so nothing in our own release chain can stall on a freshly-published package. Every version in the lockfile is at least 3.5 days old, and re-resolving under the gate shifts nothing.

Worth knowing about the gate: Yarn's own lockfile migration writes hardening opt-outs — on first install it rewrote .yarnrc.yml with npmMinimalAgeGate: 0, enableScripts: true and approvedGitRepositories: ["**"], against Yarn 4.18 defaults of 1d, false and []. Those writes were discarded; the committed value is the deliberate 3-day one.

Verification

Locally on this branch: composer validate, composer build:validate (monorepo-builder), composer cs-check (0 of 130 files), composer analyze (phpstan, no errors), 648 unit tests, 474 cross-SDK parity tests, composer audit on both locks, yarn npm audit, semantic-release --dry-run loading every plugin, the packages/Utils fresh-resolve above, and install --immutable driven by classic Yarn exactly as CI drives it — passing cold and failing on drift.

On CI: the full matrix across PHP 8.2 / 8.3 / 8.4 in both prefer-lowest and prefer-stable, plus Code Style, Monorepo Validation, Generated Types Guard, PHPStan and CodeQL.

All 88 alerts were re-checked against the post-review lockfile. Still zero.

Supersedes — both can be closed, nothing is lost

#40 — handlebars, picomatch. Fully covered: this PR takes handlebars to the same 4.7.9 and picomatch further (2.3.2 / 4.0.5), plus the other npm advisories #40 does not touch.

#36 — phpunit in packages/Utils. Its alert (GHSA-vvj3-c3rp-c85p, phpunit < 10.5.62) is resolved here, and the fresh-resolve above shows the package landing on phpunit 11.5.56.

Its changes are deliberately not folded in, and that is worth stating rather than leaving it to look like an oversight. #36 is not only a lockfile bump — it also widens packages/Utils/composer.json:

     "require-dev": {
-        "phpunit/phpunit": "^11.0"
+        "phpunit/phpunit": "^11.0 || ^10.0"
     },

That is Dependabot bending the constraint backwards so the stale locked phpunit 10.5.45 becomes legal, rather than updating the lock to 11. It has two problems: it re-admits the phpunit 10 range the advisory is about, and it breaks monorepo validation. Applying that exact diff on this branch and running composer build:validate:

 packages/Utils/composer.json        ^11.0 || ^10.0
 composer.json                       ^11.0
 [ERROR] Found conflicting package versions, fix them first.

which is presumably why it has sat open since April. The root cause is that the lock was generated against an older composer.json and never regenerated, so the lock and the constraint disagree. Untracking the lock removes the disagreement instead of legalising it — and the repo's own .gitignore already asked for that.

Neither PR cuts a release, and neither does this one: all three are chore, and scripts/rollover-version-plugin.mjs returns null for chore.

🤖 Generated with Claude Code