Pet Laravel Package

Product Decisions This Supports

• Build vs. buy for supply-chain security: Decides whether to stand up an in-house dependency-audit script or adopt a maintained CLI. Vet wraps the audit logic your team would otherwise hand-roll, so the real comparison is Vet vs. composer audit + Dependabot vs. a paid SCA platform (Snyk, Socket) — not Vet vs. nothing.
• CI gating policy: Informs the decision to make dependency hygiene a blocking check rather than a periodic report. Vet's exit codes make "fail the PR on a known-vulnerable or abandoned dependency" a policy choice you can turn on per-repo.
• Release-age ("cooldown") policy — the clearest differentiator vs. native tooling: Vet supports minimum release age settings, i.e. refusing to adopt a package version until it has been public for N days. That is a policy control composer audit does not give you, and it is the strongest argument for Vet over the built-in audit: it defends against the compromised-or-yanked-release window, not just against known CVEs. This is the decision to make explicitly — whether "we don't take brand-new versions of third-party code" becomes a team norm encoded in vet.json.
• Security roadmap sequencing: Gives a cheap, quantified baseline (count of advisories, abandoned packages, outdated majors) that lets you rank "dependency remediation" against other security work instead of arguing from anecdote.
• Compliance and procurement evidence: Produces repeatable, timestamped output suitable for SOC 2 change-management controls, security questionnaires, and customer due-diligence asks about third-party components. Cheaper than a platform license for teams that only need an artifact, not a dashboard.
• Vendor and OSS intake: As a pre-adoption gate for new Composer packages — feeds the "is this dependency safe and maintained?" decision before it lands in composer.json, which is where remediation cost is lowest.
• Licensing risk: Supports the legal/procurement conversation about copyleft and unlicensed transitive dependencies in a distributed PHP product.
• Deprecation planning: Abandoned-package detection feeds upgrade roadmaps — it's an early-warning signal for framework/Laravel major upgrades, not just a security tool.

When to Consider This Package

Adopt when:

• Your stack is PHP/Composer and you want audit signal inside CI, in the same developer workflow as tests, without procuring an SCA vendor.
• You want release-age gating or an encoded abandoned-package policy that Composer's native audit doesn't express. As of v0.2.1 the config can be as small as one setting — an otherwise-empty vet.json carrying just the minimum release age — so trialing the policy costs a config file, not a rollout.
• You have multiple Laravel/PHP services and no consistent dependency-review step — the marginal cost of trying it is a day, not a quarter.
• You need a lightweight, auditable artifact for compliance or a customer questionnaire and don't need dashboards, SBOM export, or container/OS-layer scanning.
• You want a Laravel-ecosystem-native tool from a maintainer the team already trusts, reducing the "who owns this?" objection.

Look elsewhere when:

• You need org-wide visibility, ticketing integrations, or non-PHP ecosystems. This is a single-language CLI, not a platform; polyglot estates will end up with N tools.
• You require vendor-backed SLAs, CVE triage SLAs, or reachability analysis. A 181-star package with zero dependents has essentially no production validation surface — treat it as promising but unproven, and pin the version.
• Composer's native composer audit already covers you and you have no appetite for cooldown. Since Composer 2.4 that ships in the box; it reports advisories but does not enforce a minimum release age. If your only requirement is "tell me about known CVEs," don't add a dependency to audit your dependencies. Vet has to earn its place on policy, not on prettier output.
• You're air-gapped or regulated to the point of requiring a vetted vendor. Single-maintainer, MIT-licensed tooling needs a fork-and-own plan before it goes in a critical pipeline.
• The release cadence doesn't hold. The advertised last release is dated 2026-09-27 — verify that against the actual repo before you commit; a stale audit tool silently rots, because its advisory database freshness is the whole product. v0.2.1 is a single-line config fix, so treat cadence as still unproven rather than as renewed momentum.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can add a dependency-audit gate to our PHP CI in about a day, using a small MIT-licensed Laravel-ecosystem tool instead of a six-figure SCA contract. It turns "we think our dependencies are fine" into a blocking check that fails builds on known-vulnerable or abandoned packages, and — the part native Composer tooling doesn't do — it can enforce a minimum release age so we're not the first company to install a compromised version. It produces evidence we can hand to auditors and enterprise customers. Risk is low and reversible: it's a dev-only dependency, it doesn't ship to production, and it complements rather than replaces composer audit and Dependabot. Treat it as a tactical control while we decide whether a platform purchase is warranted.

To engineering (the real pitch): It runs in CI next to your tests, fails the build on advisories and abandoned packages, and gives you the same answer locally so you're not learning about a CVE in a ticket three weeks later. It's also the cleanest way to codify "don't install a version that's less than a week old" — that lives in a vet.json that can be a single setting if that's all you want. Zero runtime footprint, no config required to start, and it's PHP-native so there's no second toolchain to learn.

Framing for the decision: This is a cheap option on a security control, not a platform commitment. Success criteria to revisit in one quarter: advisory catch rate, false-positive rate on blocking builds, whether the cooldown policy caused real friction with legitimate patch releases, and whether the release cadence holds. If it doesn't clear those bars, we drop it and consolidate on Composer's native audit plus our existing SCA tooling — no migration cost, because it never touched production.