Phpstan Sensitive Parameter Values Laravel Package

Product Decisions This Supports

Security hardening roadmap — "secrets never reach logs." The package makes PHP 8.2+/8.4's #[\SensitiveParameter] redaction mechanism legible to PHPStan. That converts a policy ("don't log credentials") into a CI-enforceable check instead of a code-review convention. This is the core product decision it supports: do we enforce redaction mechanically or socially?

Whether an automated gate will actually be trusted. Release 1.2.0 is explicitly a false-positive reduction. That matters more than it sounds: analyser adoption dies by alert fatigue. A rule that cries wolf on correct code gets @phpstan-ignore comments and baseline entries, and the gate becomes theatre. This release is the package moving from "technically detects the thing" to "detectable findings are worth acting on" — which is the difference between a gate engineers respect and one they route around. The product decision: is this precise enough to be blocking, or only advisory?

Static analysis investment / ruleset scope. Adopting it is a decision about how far to push PHPStan beyond stock levels. It answers "is our analyser smart enough to reason about wrapped/redacted values, or will it silently type secrets as plain string and let them flow into loggers, exception messages, and telemetry?"

Build vs. buy for internal tooling. A PHPStan extension of this kind is roughly a rule plus one or two dynamic-return-type/type-specifying extensions — on the order of a day of senior engineer time to write and then forever to own. This is MIT-licensed and free. The decision is not cost, it's ownership: adopting means either trusting a low-star, single-vendor artifact or vendoring/forking a few hundred lines.

PHP 8.4 upgrade gating. SensitiveParameterValue is 8.4-only. If the upgrade is on the roadmap, this package is part of the "is our tooling ready?" checklist — and part of the argument for deferring if the tooling story is thin.

Dependency risk posture. Low stars, low dependents, single org (LycheeOrg, a photo-management project) — this reads as an internal utility extracted for convenience, not a supported product. 1.2.0 is a positive signal (maintainer merged an external-looking fix promptly, and 1.0.1 → 1.2.0 shows active iteration), but one maintainer fixing one thing is maintenance, not a community. The correct PM decision is still to classify it as vendored code, not a dependency: pin the version, plan to fork.

Definition of Done changes. Adding it to phpstan.neon changes the release gate for any code path handling auth tokens, API keys, payment data, or PII. That's a process decision, not a technical one — and 1.2.0 makes that gate meaningfully more defensible to the engineers who have to live with it.

When to Consider This Package

Adopt when all of these hold:

• Runtime is PHP 8.4+ (or 8.2+ if only the attribute is in play) and the upgrade is committed, not speculative.
• PHPStan is already in CI and the team treats analyser failures as blocking.
• The codebase genuinely moves secrets through function signatures — auth, API clients, payments, PII, session tokens — so redaction is a real risk surface, not a hypothetical.
• You specifically need type-aware handling of SensitiveParameterValue (type preservation through the wrapper, or diagnostics when a sensitive value is passed where a plain one is expected). If you only need the attribute to be syntactically valid, stock PHPStan is likely enough.
• Someone owns the fork.

Look elsewhere — or skip — when:

• No PHPStan. Obvious, but worth stating: this is a dev-only analyser plugin. Zero production value.
• PHPStan core already covers it. Still the first diligence item. Support for SensitiveParameter has been landing upstream over time; run a spike on your pinned PHPStan version with the extension removed before committing.
• You need real taint analysis. This package is about redaction semantics, not dataflow. If the goal is "trace untrusted input to a sink," Psalm's taint mode or Semgrep are the right tools.
• You need a supported vendor. No meaningful community issue surface. If procurement or a security review requires a maintained upstream, this fails that bar regardless of code quality — and a single false-positive fix in 1.2.0 doesn't change the procurement answer.
• The team won't fork it. With one maintainer and a single org behind it, abandonment is a when-not-if. If nobody will adopt the code, don't adopt the dependency.

What changed with 1.2.0. The main practical objection to adopting this class of rule — first-run noise — is now partially addressed by the vendor rather than by you. Two consequences: the spike gets cheaper (a shorter baseline exercise, less triage of junk), and the first-run findings become more credible as a deliverable. It does not change the ownership calculus, and it does not close the upstream-coverage question. Also verify the version history: the changelog compares 1.0.1...1.2.0 with no 1.1.0 notes, so confirm whether an intermediate release exists before pinning, and read PR #3 to see exactly which false positives were removed — a fix aimed at their codebase's patterns may not cover yours.

The high opportunity score against low adoption remains the interesting signal: the problem is real and under-served, this artifact hasn't captured the market, but it is now visibly being maintained. Value the idea, discount the package a little less than before.

How to Pitch It (Stakeholders)

For executives (one paragraph). We can turn a security policy — "credentials must never appear in logs or exception traces" — into an automated check that runs on every pull request. The mechanism is a small, free, MIT-licensed plugin for the static analyser we already run; it never ships to production and adds no runtime cost or licensing cost. The latest release specifically reduces false alarms, which is the difference between a check engineers trust and one they learn to suppress. Effort is measured in hours, not sprints. The risk remains maintenance: the project has essentially one maintainer, so if we adopt it we pin the version and treat it as code we own, not a vendor relationship. Recommendation: approve a short spike to confirm our analyser version doesn't already do this, and adopt behind a pinned version if the spike shows a gap.

For engineering (the substance).

• Dev-only Composer dependency, loaded into PHPStan's ruleset. No production artifact, no autoloader impact, no measurable CI cost at our codebase size.
• It closes a specific failure mode: values marked #[\SensitiveParameter] get redacted in stack traces, but static analysis loses the type once the value is wrapped in SensitiveParameterValue. That gap is where a secret silently becomes mixed and flows into a logger unnoticed.
• Integration is a few lines in phpstan.neon plus a baseline pass. 1.2.0 cuts the false-positive surface, so expect a smaller and higher-quality first-run finding set — those findings are the deliverable.
• Before merging: verify against our pinned PHPStan version that the behaviour isn't already upstream; confirm the extension's rules don't duplicate anything in our existing config; read PR #3 to see which false positives were fixed and whether any pattern in our codebase still trips it; and check whether a 1.1.0 exists that the changelog omits.
• Ongoing: pin the exact version (1.2.0) rather than a caret range — a young package with two releases in quick succession is likely to keep shifting rule behaviour, and rule changes silently move our release gate. Vendor the source into our own namespace if we depend on it beyond one release cycle, and assign an owner. Bus factor is still one.

Bottom line for the decision meeting. Low cost, low technical risk, non-trivial maintenance risk, and a genuinely high-value failure mode addressed — now with better signal-to-noise than at first evaluation. The correct framing is not "should we add a dependency" but "should we own a small analyser rule" — and if the answer is yes, using this as the starting point is cheaper than writing it.