Filament Cybersecurity Laravel Package

Getting Started

This is the first assessment; v1.3.2 is a bug-fix release with no breaking changes. Start by upgrading and re-running your existing lifecycle checks, especially if you monitor SQL Server. The headline fix makes SQL Server version detection use SERVERPROPERTY('ProductVersion'), so the package matches endoflife.date branch 16.0 instead of the marketing year. The second fix strips CU/GDR suffixes from latest patch names before patch-lag comparison.

First steps:

1. Install/upgrade via Composer and review the package config for database connections and product mappings.
2. Run the package’s audit command in staging against a SQL Server connection and confirm it reports branch 16.0 for SQL Server 2022-era instances.
3. Use the first real use case: detect end-of-life database versions and measure patch lag against endoflife.date.
4. If you previously saw SQL Server matched against a year-like value instead of 16.0, this release should fix that; verify the output before relying on alerts.

Look first at:

• The package’s config file for connection names, product keys, and thresholds.
• The artisan command or programmatic checker used to run lifecycle probes.
• The SQL Server probe output: detected product version, matched endoflife.date branch, latest available patch, and computed patch lag.

Implementation Patterns

Use the package as a scheduled audit rather than a request-time check. A typical daily workflow:

• Schedule the lifecycle check once per day in app/Console/Kernel.php or routes/console.php, depending on your Laravel version.
• Run it per database connection when you manage multiple SQL Server instances.
• Send results to Laravel notifications, Slack, mail, or your observability stack when a branch is EOL or patch lag exceeds your threshold.
• Persist results in a table if you want trend reporting, e.g. patch lag over time or version drift across environments.

Common integration patterns:

• CI/CD gate: Run the check in CI against staging or a disposable database. Fail the pipeline when an unsupported branch or excessive patch lag is detected. Confirm the command’s exit-code behavior first.
• Health check endpoint: Wrap the programmatic check in a Laravel health route or custom health check, but cache results so you do not call endoflife.date on every request.
• Multi-connection audit: Loop over configured connections and run the probe for each. Keep connection-specific thresholds in config rather than hard-coding them.
• Custom probes: If you use PostgreSQL, MySQL, or another engine, implement the package’s probe contract and register it in config. Follow the SQL Server probe’s pattern: detect the real engine version, map it to an endoflife.date product/branch, then compare patch levels.
• Notification routing: Separate “EOL soon” from “patch lag exceeded” so the right team gets the right alert.

For SQL Server specifically, v1.3.2 improves two things you should lean on:

• Branch matching now uses the product version branch (16.0) rather than a marketing-year string.
• Patch-lag comparison strips CU/GDR suffixes from latest patch names, so names like 16.0.x CU15 do not break comparison.

Gotchas and Tips

• SQL Server branch expectations: After v1.3.2, expect 16.0 for the SQL Server 2022 family, not 2022. Update any dashboards or assertions that pinned the old marketing-year value.
• CU/GDR suffix stripping is not full version normalization: The fix strips suffixes from latest names, but you should still test against your actual endoflife.date payload. If latest names use unusual formats, patch lag may still miscompare.
• Permissions and drivers: SERVERPROPERTY('ProductVersion') is generally available to normal SQL Server logins, but confirm your connection user can query it. Azure SQL and managed instances may report versions differently, so validate the probe output in each environment.
• Network dependency: endoflife.date calls can fail or rate-limit. Cache responses with Laravel’s cache and provide a fallback or “unknown” state rather than crashing the scheduled job.
• Do not run on every web request: Lifecycle checks are slow and external. Schedule them, cache them, or run them in CI.
• Exit codes and thresholds: If you gate deployments, verify the command returns non-zero on failure. Configure patch-lag thresholds explicitly; defaults may not match your security policy.
• Config quirks: Connection names, product keys, and probe class mappings are easy to misconfigure. Start with one connection, confirm the raw probe result, then expand.
• Debugging: Use verbose command output and log the detected version, matched branch, latest patch name, and computed lag. When a match fails, inspect the raw endoflife.date response before changing thresholds.
• Extension points: Prefer custom probes and result formatters over forking the package. Keep engine-specific version parsing in the probe, not in shared reporting code.
• Upgrade note: v1.3.2 is low-risk but directly affects SQL Server results. Re-run your SQL Server audits after upgrading and compare against previous output to confirm the branch and patch-lag fixes are active.