Vigie Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for application-layer threat detection. This package is the glue between a PHP app and CrowdSec (crowd-sourced IP reputation / IPS). It lets you skip building your own log-emission and decision-consumption layer if CrowdSec is already — or will be — part of your security posture. v0.3.0 materially lowers the buy side of that equation.
• Deployment topology and log shipping. The new output.syslog option (v0.3.0) sits alongside the default file handler. This is a real infra decision: it removes the need for a sidecar/log-shipper on containerized or 12-factor deployments, and it enables direct-to-collector emission. Worth revisiting any "we need Fluent Bit/Vector in front of this" assumption.
• Roadmap: is security telemetry a feature or a platform concern? The package emits request/record data in a CrowdSec-parseable shape and consumes decisions back. That framing lets you decide whether in-app blocking lives in your product surface (feature) or is delegated to edge/WAF/ingress (platform). This release gives you a cheap way to prototype the in-app option.
• Onboarding cost of a security control. Shipping a CrowdSec parser for syslog lines (PR #11) plus an idempotent install snippet (PR #10) converts "weeks of parser authoring and config drift" into "copy a documented snippet." That shifts the calculus for piloting in a single service before committing org-wide.
• Detection coverage as a measurable SLO. The max_length warning on oversized syslog datagrams (PR #13) turns silent log loss into an observable signal. This supports a decision to treat "decisions received" and "log emission failures" as monitored metrics rather than assumed-100% guarantees.
• Incident response and auditability. De-duplicating removed-decision reporting (PR #6) and enriching removed decisions from the store (PR #7) make the app-side enforcement trail cleaner and more defensible for post-incident review — a prerequisite if you ever need to answer "why was this IP blocked at 14:02?"
• Security debt triage. The docs fixes in this release (record.ip_address must be true on the emitting kernel; host.hostname is the container ID under Docker) are silent-failure landmines. If you ship without them, you get a control that looks deployed and produces unusable data. This is a "fix the config before you claim the capability" decision, not just a docs patch.

When to Consider This Package

Good fit when:

• CrowdSec is already running, or is on the roadmap as your reputation/decision engine. Without CrowdSec this package has no job to do.
• You run a PHP/Laravel app you control, where you can add middleware-level enforcement and you don't have (or don't want) a WAF/integres in front of every route.
• You're containerized or running a dynamic fleet and want syslog emission rather than mounting shared volumes — v0.3.0 explicitly unlocks this.
• You value the reduced operational surface: bundled parser + idempotent install snippet means the CrowdSec-side setup is now mostly copy-paste.
• You've accepted that enforcing blocks in-app is a complement to edge controls, not a replacement — you want defense in depth on the application tier.

Look elsewhere or wait when:

• You need a stable public API. This is v0.3.0; it is pre-1.0 with a single maintainer (IQ2i) and a small PR cadence. Expect churn. If you need versioning guarantees or a support SLA, this isn't the tool yet.
• Nobody on the team owns CrowdSec operations. The package assumes a CrowdSec agent, a profile install, a parser, and correctly configured kernel settings (record.ip_address = true, syslog max_length, container hostname semantics). Misconfiguration degrades silently into useless data. Treat CrowdSec ops competency as a hard prerequisite.
• You need per-service or per-tenant attribution. Under Docker, host.hostname resolves to the container ID — not a stable service identity. If your correlation model depends on hostnames, budget for a mapping layer or reassess.
• Your threat model demands sub-millisecond inline decisions at very high RPS. Enforcement in application middleware has a latency and blast-radius cost that edge enforcement does not. Benchmark before committing.
• You want a managed product. This is an open-source integration kit; the operational and security-expertise burden is yours.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, open-source integration that connects our application to CrowdSec, the crowd-sourced IP reputation service we can run ourselves. It gives us application-level blocking of known-bad actors without buying a commercial WAF, and it's the cheapest way to test whether in-app enforcement is worth investing in. The main caveats are maturity — it's a pre-1.0 package with one primary maintainer — and the fact that it only works if we're prepared to operate CrowdSec. Recommendation: fund a scoped pilot on one service, not an org-wide rollout.

For engineering (short): v0.3.0 is the release that makes this pilotable. It adds syslog output alongside the file handler (no more sidecar shipper), ships the CrowdSec parser so we stop hand-authoring log parsing, provides an idempotent install snippet for the CrowdSec profile, and fixes the duplicate-reporting and dropped-decision issues we'd otherwise have to write around. Two config footguns are now documented rather than silent: record.ip_address must be enabled on the emitting kernel, and under Docker host.hostname is the container ID, so plan your identity mapping accordingly. It also warns when a syslog datagram exceeds max_length, which converts a silent data-loss mode into an alertable signal — wire that into monitoring on day one. Nothing here is breaking, but at v0.3.0 pin the version and assume the API will move.

Ask: one service, one sprint, with CrowdSec ops time explicitly allocated and the max_length warning plus decision-ingest rate added to dashboards before we call it done.