Add eol_check.py — lifecycle / End-of-Life intel tool (endoflife.date, pure-stdlib)

[venkatas]

What this adds

tools/eol_check.py — a small, pure-stdlib recon/intel tool that maps a target's
detected tech fingerprints to endoflife.date product slugs and
reports the lifecycle status of each release: supported, security-only, EOL-soon,
extended/ESM support, or past-EOL. Past-EOL software is a factual, verifiable finding
(unsupported = no security patches), so this complements CVE lookup during recon.

$ python3 tools/eol_check.py --tech "php=7.4,ubuntu=20.04,php=8.2,nextjs" --target example.com
  [CONFIRMED]     php 7.4 (cycle 7.4)     :: EXPIRED — EOL 1322d ago
  [POSSIBLE]      ubuntu 20.04 (cycle 20.04) :: EXTENDED — EOL 407d ago  [extended/ESM may apply — verify entitlement]
  [INFORMATIONAL] php 8.2 (cycle 8.2)     :: SECURITY_ONLY  [active support ended; security-maintenance only]
  [INFORMATIONAL] nextjs                  :: UNKNOWN  [no version supplied]

Why it fits the repo

• Pure stdlib (urllib/json/ssl) — nothing to install, so it can never be the
  "missing dependency" that skips a scan. Drops into tools/ alongside the other Python tools.
• No traffic to the target — endoflife.date is a public metadata API.
• Uses the repo's confidence tags: [CONFIRMED] / [POSSIBLE] / [INFORMATIONAL].
• Offline-cached (24h, ~/.cache/bughunter/eol), so repeat runs are free.

Design principle: prefer "indeterminate" over guessing

A lifecycle checker that guesses is worse than useless in a security context. So:

• An unmatched or absent version yields unknown — the tool never classifies an
  install from an unrelated release, and never emits [CONFIRMED] it can't substantiate.
• Standard EOL is distinguished from extended/ESM support (reads support + eol +
  extendedSupport), so an ESM-covered release (e.g. Ubuntu 20.04 → 2030) is reported as
  [POSSIBLE] extended, not [CONFIRMED] no fixes.
• String-based cycle matching on canonical identifiers — handles v-prefixed and
  patch-level versions and refuses ambiguous / mixed-identifier matches (e.g. won't match
  an AWS-Lambda nodejs18.x runtime against a ruby4.0 cycle).
• Product slugs are validated against /api/all.json; genuinely ambiguous fingerprints
  (iis, bare powershell) are omitted rather than mapped to a wrong product.

Safety / robustness (hardened against malformed / hostile data)

• Rejects control / format / separator characters by Unicode category (Cc/Cf/Cs/Zl/Zp)
  in any identifier, so a malformed cycle id or version can't be str.strip()-canonicalized
  into a false match; requires canonical YYYY-MM-DD dates so a non-schema date can't
  substantiate a verdict.
• Validates API and cache payload types (degrades to unknown instead of crashing on a
  non-list / rate-limit / truncated body), only matches string cycle ids, treats duplicate
  or ambiguous cycles as indeterminate, and downgrades a past-EOL record whose extended/ESM
  support can't be ruled out to [POSSIBLE] rather than [CONFIRMED].
• Sanitizes slugs (no path traversal, no raw slug in the URL), caps both response and cache
  size, dedups fetches per run, and fails soft on every I/O / parse / cache-write path.
• NO_COLOR + non-TTY aware; strips terminal control characters from rendered output and
  from the --json artifact.
• CLI exit codes for automation: 2 = a [CONFIRMED] past-EOL item is present;
  3 = --strict and something was indeterminate (lets CI tell "checked, fine" from
  "couldn't check"); 1 = a requested --json artifact could not be written; else 0.

Tests

tests/test_eol_check.py — 58 deterministic tests (network mocked; all dates built
relative to "today" so nothing rots). Covers the no-fabrication contract, version matching
edge cases (v-prefix, patch-level, boundary, mixed/duplicate identifiers, Unicode-separator
rejection), extended/security-support semantics, malformed-payload and crash robustness,
slug + output sanitization, dedup, and CLI exit codes.

The tool was hardened across several adversarial review passes specifically to ensure it
prefers "indeterminate" over ever emitting an unsubstantiated [CONFIRMED] finding.

Notes

• Targets the stable endoflife.date REST endpoint. A future enhancement could move to
  /api/v1/products/{product} to consume its native isEoas/isMaintained fields.
• Lifecycle data is courtesy of endoflife.date (MIT licensed); the credit string is
  retained in both the tool output and the JSON export.