Security Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for auth/security plumbing. The bundle sits in the authentication/authorization layer — the part of the stack where a "buy" decision is cheapest to make early and most expensive to reverse later. This assessment supports a defer decision: don't standardize on it, but keep it on a shortlist for internal-only Symfony services where its conventions match our stack.
• Roadmap scoping for security/compliance features. If we are planning MFA, role/permission management, or token handling for an upcoming release, the bundle is a candidate reference implementation — useful for estimating what "batteries-included" looks like and how much of that we'd otherwise build in-house.
• License and dependency-risk register entries. AGPL-3.0 is the dominant product decision here, not the code. This package belongs in the "requires legal review before any production dependency" bucket; that classification is itself a decision the PM owns.
• Vendor concentration and maintainer-risk tracking. One star, zero dependents, and a single publishing organization means this is effectively a company's internal bundle released publicly. That informs our OSS dependency policy: acceptable for exploration, not for a system of record.
• Not a platform bet. Nothing here justifies architecture, hiring, or a multi-quarter commitment. Treat it as a tactical evaluation, not a strategic component.

When to Consider This Package

Consider it when all of the following hold:

• The service is internal-only or otherwise outside AGPL's network-use trigger, or we are prepared to open-source the combined work / pursue a commercial license from NetBull.
• The team is on Symfony (the "bundle" packaging and NetBull's conventions point there) and wants a pre-assembled security layer rather than wiring the native Security component by hand.
• We are comfortable vendoring or forking it, since AGPL permits this and the upstream maintenance signal is weak.
• The feature set maps closely to our requirements without customization — i.e., we are not asking a one-maintainer package to carry bespoke authorization logic.
• Timeline pressure makes a thin wrapper attractive for an MVP or prototype, with a documented plan to replace it before general availability.

Look elsewhere when:

• The product is commercial or closed-source SaaS — AGPL obligations around network use are a material legal and product constraint, and the cost of compliance likely exceeds the cost of building on framework-native primitives.
• We need Laravel-native solutions: Laravel Fortify, Breeze, Sanctum, and Passport are the idiomatic answers, with large user bases and security review history.
• We need audited, enterprise-grade security with a CVE process, a security contact, and maintainers who respond — one star and zero dependents do not provide that signal.
• We require long-term support commitments, SLAs, or indemnification.
• The security model is core to the product's differentiation; in that case even a well-maintained third-party bundle is the wrong layer to outsource.

How to Pitch It (Stakeholders)

To executives: This is a small, single-maintainer open-source security bundle under AGPL-3.0. The code may be useful, but the license is the headline: AGPL's network-use clause can obligate us to disclose source for services built on it, which is a business-model question, not an engineering one. Combined with one star and zero downstream dependents, it carries maintenance and continuity risk we would have to absorb ourselves. Recommendation: no roadmap dependency. Approve a time-boxed spike only if an internal, non-commercial service has a concrete need — and route it through legal first.

To engineering: Evaluate it as a reference implementation, not a foundation. Compare its surface area against the framework's native security primitives and against our own thin internal layer; the likely outcome is that the delta is small and not worth an AGPL-encumbered, single-maintainer dependency. If we do adopt, plan to vendor the code, pin the version, and budget for ownership — assume upstream fixes will not arrive on our schedule. Capture the license decision in the architecture record so it isn't relitigated, and set an explicit expiry on any prototype built on it.