Vet Laravel Package

Product Decisions This Supports

• Making dependency-adoption policy a reviewed artifact. The real deliverable of adopting laravel/vet is not the Artisan command — it is a committed vet.json at the repo root. That turns "which dependency versions are acceptable here" from reviewer memory or a wiki page into a diffable file that security, the owning team, and product can approve in the same PR as the change that motivated it. That is a governance decision, and it is yours to make, not the tool's.
• Choosing a minimum release age as an explicit gate. The one rule the changelog and config surface actually document is a quarantine on versions published within the last N days. The decisions are the threshold (start at 7, move to 14 or 30 once you can measure the blocked-bump rate) and the blast radius (one repo, then dependency-touching PRs, then all merges plus a scheduled re-audit). The tooling is the cheap part.
• Build vs. buy vs. adopt. Alternatives are a hand-rolled Composer/CI script, a bespoke internal policy engine, or a hosted supply-chain platform. Adopt when the desired policy surface is narrow — release age plus a trust list — and you want it in version control rather than in CI YAML. Build only once you can name a rule Vet does not cover.
• Incident-response freeze as an auditable commit. During a supply-chain scare, "freeze new packages" becomes a dated, attributed one-line vet.json change with an obvious revert. Write the rollback into the runbook at the same time as the freeze, not during the incident.
• Review evidence in context. Policy drift surfaces in the PR that caused it, next to the dependency bump, rather than at audit time. This is the argument that usually wins with engineering leadership: it moves a review conversation earlier and makes it smaller.
• A scope correction that must land before any commitment. The public framing is inconsistent. The manifest description sells Laravel-aware static analysis — request input, mass assignment, queries, views, "PHPStan-powered." The changelog and config surface describe a Composer trust file whose only documented rule is minimum release age. These are different products with different buyers. Resolve which one ships in the version you pin before anyone puts "AppSec scanner" on a roadmap slide; teams that read "audit" assume CVE coverage and will over-trust it.
• Pilot sequencing as a distinct decision. One release-age rule, one non-critical repository, report-only, is a days-scale experiment. Portfolio-wide enforcement is a separate decision gated on that pilot's blocked-bump data and runtime measurements. Do not merge the two on a roadmap.
• Explicit non-coverage. Vet is not a CVE scanner and does not produce an SBOM. The decision this supports is keeping composer audit and Dependabot/Renovate in the pipeline alongside it, sequenced before it — otherwise week one reads as "this tool blocks security fixes," and you lose the argument for keeping it.

When to Consider This Package

Consider it when:

• You maintain a PHP/Composer codebase with composer.lock committed and no formal, reviewable dependency-adoption policy today.
• Your primary desired control is release-age quarantine, and you want that number in version control rather than in CI YAML or a reviewer's head.
• The realistic alternative is a hand-rolled Composer or CI script. Vet costs one require-dev entry plus one pipeline step, so it wins on maintenance cost if its rules fit your policy.
• You can name a single owner for vet.json and accept pre-1.0 churn: pin the exact version, and treat each minor upgrade as a reviewable PR because the config schema can move under you.
• You are willing to start report-only on one non-critical repository and ratchet deliberately — measure runtime on your largest lockfile, then enforce only on PRs touching composer.json/composer.lock, then widen.
• You can tolerate ambiguity being resolved by reading src/. The provided sources are a changelog and a contributor guide written for coding agents, not a user manual; budget roughly an hour to answer "does this version do the Laravel code checks the description advertises, or only the trust-file checks the changelog documents?"

Look elsewhere — or do not rely on it — when:

• You need vulnerability/CVE scanning, SBOM generation, license compliance, artifact signing, or a general-purpose policy engine. composer audit covers advisories; Vet is not a substitute, and neither replaces the other.
• You need vendor support, an SLA, stable public APIs, or broad community validation. At ~185 stars, zero dependents, and v0.2.x, you would be among the first production users; unknown edge cases are yours to diagnose, and the fastest debugging path is often reading src/ rather than searching issues. Budget for the possibility of maintaining a fork.
• Your dependency graph leans on private registries, path repositories, or VCS dependencies. That is the unverified surface — and it is exactly where the riskiest dependencies live. Determine whether those are skipped (fail open) or failed (fail closed); if it fails open, your enforcement design is a suggestion, not a control.
• Your runners are air-gapped or egress-restricted. Age checks imply Packagist metadata lookups, so outages become build outages; decide explicitly whether offline fails open or closed.
• Anyone would put the resulting evidence into an audit narrative before you have verified what installed (composer show laravel/vet) — the advertised last release date is 2026-09-27, a future date, and exit codes are not enumerated in the sources. Capture $? for pass, fail, and config-error cases and assert them in a small CI test so a minor bump fails loudly in one place instead of quietly disabling the gate.

How to Pitch It (Stakeholders)

For executives — one paragraph: We have no written rule for how quickly we adopt newly published dependency versions. laravel/vet lets us write that rule as a small file in the repository, reviewed like code, instead of leaving it to reviewer judgment. The ask is not a platform commitment: it is one dev-only dependency and one CI step on a single non-critical service, running in report-only mode for two weeks, with a go/no-go on measured data — runtime cost and how many routine bumps it would have blocked. If the numbers are bad, we drop it at near-zero cost. If they are good, we widen enforcement to dependency-changing PRs only. It does not replace vulnerability scanning; it sits beside it and answers a different question.

For engineering — the framing that prevents the wrong expectation: This is a dependency-trust policy file, not an AppSec scanner. It makes release-age policy diffable and reviewable in the PR that motivated it, and it gives us a one-line, attributed freeze during a supply-chain incident with an obvious revert. It does not detect CVEs, does not emit an SBOM, and does not replace composer audit or Dependabot — those govern what has CVEs and when we move; this governs which versions are admissible. Sequence it after them, or the first-week experience is "this tool blocks security fixes."

For the adopting team — the honest caveats to state up front: v0.2.x, pre-1.0, ~185 stars, zero dependents. Pin the exact version and treat minor upgrades as PRs. The manifest description and the changelog describe two different products; assume the narrower one until someone reads src/. Exit codes are our integration contract and are undocumented — we verify them empirically and assert them in CI. And name an owner for vet.json before adoption, because exceptions are a PR to that file, dated and reversible, not a Slack override.