Vulnetix EOL Check Skill

Use when

• Quarterly upgrade planning: which runtimes hit EOL in the next 90 days?
• Audit: any past-EOL runtimes in production?
• CI gate: block deploys if any EOL runtime is detected.
• Container base-image EOL check (alpine 3.16, debian 10, etc.).
• Cross-reference: an EOL runtime + an unpatched CVE = critical priority.

Don't use for

• Vulnerability scanning — use vulnetix scan --sca or repo-impact.
• License auditing — use license-check.

Conventions

Follows skills/_lib/contract.md. In short: use the vulnetix_* MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes.

Step 1: Load capabilities

Read .vulnetix/capabilities.yaml. Use derived.primary_package_manager and repo.dockerfile to decide which surfaces to scan.

Step 2: Run gated scan

vulnetix scan --block-eol -o json

Exit code is non-zero on EOL hits. Capture findings.

Step 3: Cross-check runtimes

For each detected runtime, fetch authoritative dates:

vulnetix vdb product "<runtime>" -o json   # node, python, java, golang, dotnet

Step 4: Render

| Runtime / package | Installed | EOL date | Days past EOL | Action |
| Node.js          | 16.x      | 2023-09-11 | 600          | upgrade to 20 LTS |

If --strict, also flag versions reaching EOL within 90 days.

Memory update

event: eol-check with EOL items per vuln entry (or a top-level runtimes block in memory.yaml if entries don't exist).

Edge cases & gotchas

• vulnetix scan --block-eol exits non-zero on EOL hits — wrap with || true to capture without aborting.
• EOL dates are from vulnetix vdb product — authoritative for major runtimes, less complete for niche libraries.
• --strict mode flags items reaching EOL within 90 days. Default mode only flags past-EOL.
• Container base images need a Dockerfile/Containerfile in the repo; the skill cannot scan a --image registry tag without one.
• For runtimes with overlapping LTS schedules (Node 18 vs 20), EOL dates can shift; re-run periodically rather than caching.
• Output flags EOL but does not propose an upgrade path — pair with dependency-choice for the recommended target.