Nadia Simple Security Bundle Laravel Package

Product Decisions This Supports

• Framework fit check at intake. This is a Symfony bundle (*Bundle suffix, kernel/DI registration), not a Laravel package. The decision this supports is procedural: fix the candidate-sourcing pipeline so Symfony artifacts don't enter Laravel roadmap reviews. One filtering rule at intake saves an evaluation cycle here.
• Build vs. buy on auth. If a Laravel squad is scoping "simple security," this evaluation supports build on native — Sanctum/Breeze/Fortify for authentication, Gate/Policy plus spatie/laravel-permission for authorization. The package offers nothing Laravel's first-party stack doesn't already cover with maintainers, docs, and a CVE process.
• Dependency policy for security-adjacent code. Reinforces a standing rule: no net-new single-maintainer dependencies on the auth path. 0 stars, 0 dependents, score 0.1 — the "buy" side of the ledger is empty, so there's nothing to weigh.
• Roadmap de-risking. If "simple security" surfaced as a roadmap theme, the right output is a spike against Laravel's native primitives, not a vendor evaluation. Cheap to run, produces reusable knowledge, and closes the question permanently.
• Rejected-candidate log entry. Useful as a rubric data point — adoption signals, maintenance cadence, framework match — not as a backlog item.

When to Consider This Package

Adoption criteria (all must hold — unlikely in a Laravel shop):

• You are on Symfony, not Laravel. This is non-negotiable; there is no adapter worth writing.
• You're pinned to an old Symfony major where the native authenticator system isn't available.
• You have read the full source and the surface is genuinely trivial and non-critical.
• You are prepared to vendor or fork it and own it — pin the commit, write tests around the auth paths, name an owner, and treat it as first-party code.

Look elsewhere — by default:

• Laravel: Sanctum (SPA/token), Passport (OAuth2), Fortify (auth backend), Breeze (starter kit), spatie/laravel-permission (roles). All maintained, documented, widely adopted.
• Symfony: symfony/security-bundle + security.yaml firewalls/authenticators; lexik/jwt-authentication-bundle for JWT.

Do not use for: production authentication, anything touching PII/PCI/regulated data, multi-tenant authorization, SSO, session handling, or password storage.

Disqualifying signals: 0 stars and 0 dependents means no community review of security logic; no visible test suite or CI; no support matrix (PHP/Symfony versions); unknown maintainer footprint. In a security-sensitive category, "nobody has looked at this" is itself a finding.

How to Pitch It (Stakeholders)

For executives — one paragraph: We evaluated nadialabs/nadia-simple-security-bundle and recommend not adopting it. Two reasons: it's a Symfony bundle, so it doesn't fit our Laravel stack, and it shows no adoption at all (0 stars, 0 dependents, minimal health score) in the most sensitive part of the codebase. The MIT license means we could fork it, but there's no reason to — Laravel's built-in authentication and authorization are better maintained, better reviewed, and free. Recommendation: close the candidate, keep the framework-native stack as the standard, and add a framework-fit check to package intake so this class of mismatch doesn't consume another evaluation.

For engineering — short version: Don't integrate. It targets Symfony's kernel and bundle lifecycle, which Laravel doesn't implement, and its scope duplicates what Laravel's Auth, Gate, and Policy already do. If someone is already depending on it in a Symfony context: fork-and-own — pin the commit, review the auth paths (hashing, session handling, timing-safe comparisons, input trust boundaries) before it reaches production, wrap it behind an internal interface, and plan an exit to native primitives. Do not add it to new work.

Decision requested: Approve the rejection and the intake-filter fix. No spend required.