Core Vendor Hardening Laravel Package

Product Decisions This Supports

• Deployment topology decision (the real one). vendor/ inside the docroot is an architectural choice, usually made for you by shared hosting or a legacy single-docroot layout. This package is a compensating control for that choice, not a fix. Adopting it is effectively a decision to accept a weaker architecture and mitigate it, and that trade-off should be recorded in the risk register rather than absorbed silently into a Composer file.
• Security posture and compliance evidence. It strips test suites, docs, examples, and CI configs from installed packages and writes deny rules (.htaccess / web.config) where the server honors them. That is a demonstrable hardening step for a security questionnaire, even though its protection is partial and server-dependent.
• Build vs. buy. The job is small: prune non-runtime files from vendor/ and drop access-control files in place. An equivalent deploy-time script is maybe a day of engineering. Choosing the package trades ~1 day of code for an external dependency with 17 stars, GPL-2.0, and low activity. That is a legitimate PM call, but it should be made explicitly, not by default.
• Dependency governance surface. It is a Composer plugin — it executes code at install/update time. That requires an allow-plugins entry and belongs in the supply-chain review alongside any other install-time hook.
• What it does not support. It enables no feature, moves no user-facing metric, and has no place on a roadmap. Treat any pitch that frames it as product work as mis-scoped.

When to Consider This Package

Adopt when:

• The vendor directory is, or must remain, inside the document root — constrained shared hosting, single-docroot legacy infrastructure, or a site you inherited and cannot re-platform on a useful timeline.
• You cannot change the docroot mapping within the planning horizon, and the exposure is therefore structural rather than incidental.
• You want reproducible pruning without hand-maintaining a shell script or post-install hook per project.
• Your team is already on Composer-based Drupal scaffolding where this fits the existing pattern.

Look elsewhere when:

• The project is Laravel or any conventional PHP app. Laravel's docroot is public/; vendor/ is a sibling, not a descendant. There is nothing web-reachable to harden. This package's premise does not apply, and adding it would be cargo-culting a control against a threat you do not have.
• You can move the docroot. Do that instead. A one-line server config change dominates a per-release file-pruning plugin, and it eliminates the whole class of problem rather than narrowing it.
• You need active maintenance, modern PHP guarantees, or a broad support community. The star count and score are weak signals here; the project is narrow and slow-moving by design. That may be fine for a frozen control, but it should not be assumed.
• GPL-2.0 is flagged by your legal or OSS policy. Unusual for dev-only tooling, but some organizations apply blanket rules, and it is cheaper to check up front than to unwind later.
• .htaccess is not honored (nginx, or Apache with AllowOverride None). The bundled deny rules become dead weight; only the file pruning remains useful.

How to Pitch It (Stakeholders)

To executives — one line: "It's a seatbelt, not a new car." A small Composer plugin that shrinks the blast radius if our third-party code is ever web-reachable. Low cost, no user-facing change, no performance impact. It does not fix the underlying exposure — it only narrows it — and we should describe it that way rather than report the risk as closed.

To engineering — differentiated by stack: For Drupal sites on restricted hosting where vendor/ genuinely sits under the docroot, adopt it as a pinned scaffolding dependency and move on. For our Laravel services, decline: the docroot already excludes vendor/, so there is no exposure and no benefit. If we ever land on single-docroot hosting, write a short deploy step — thirty lines, no license question, no external maintainer, and we control the PHP version support. Either way, route the install-time plugin execution through the allow-plugins review so it shows up in the supply-chain inventory.