A bounded pilot.
A measurable result.
Proposed delivery scope for the first customers. This is the offer definition, not a claim that automated monitoring is already running.
Commercial shape
Four weeks, one customer organisation, up to 500 component records and 25 distinct product/version combinations requiring lifecycle research. One initial review, four weekly HTML/CSV reports and an exception register. An MSP can pilot one client organisation; each client's data stays separate.
Initial product coverage
| Area | Initial named scope | Boundary |
|---|---|---|
| Operating systems | Windows Server 2016/2019/2022; Ubuntu Server 20.04/22.04/24.04 LTS; Debian 11/12/13; RHEL 8/9 | Version, edition, package channel and entitlement matter. Point releases and extended support need evidence. |
| Runtimes / databases | Node.js, Python, PHP, PostgreSQL and MySQL release series | Distinguish upstream builds from distribution-maintained packages. No blanket matching from version alone. |
| Golden / container images | Components from the named families, supplied in the same CSV | Image identity/digest and deployment relationships must be supplied. No image scanning or registry access. |
| JavaScript dependencies | Customer-supplied npm package names and versions, including transitive dependencies present in the export | Only documented support policies produce lifecycle deadlines. Other packages are explicitly unknown. No assumed expiry from age. |
| Other Windows/Linux applications | Up to five named products agreed during onboarding, within the 25-combination research cap | Coverage is confirmed before inclusion. All other products remain outside confirmed coverage. |
One input: UTF-8 CSV
One row per component occurrence on an asset or image. A component on 20 assets means 20 rows. Import limit: 500 rows and 2 MB per submission. Existing inventory tools and SBOM exports can be mapped into this format; direct SBOM ingestion and a custom npm collector come later.
Required fields: asset_id, asset_type (server, vm, golden_image, container_image, application), product, version. A stable customer reference is sufficient; real hostnames are unnecessary.
Optional context: vendor, edition, distribution, distribution_version, package_release, package_source, purl, image_ref, parent_image_ref, environment, exposure, service, owner, criticality, support_provider, support_until, support_evidence_ref. Missing context stays unknown. Parent image references link deployments to images only when supplied; never infer that relationship.
Support and matching rules
Normalise vendor, product, release and packaging context. Exact documented matches can be confirmed; ambiguous names or versions are held for review. Keep upstream support, distribution support and third-party support separate. Record source URL or customer evidence reference, checked date and confidence for every conclusion.
Record full vendor lifecycle phases rather than treating the end of mainstream support as the end of all security updates. Distribution backports can keep a packaged version supported beyond upstream EOL. Third-party coverage requires evidence of active entitlement, the covered product/build and expiry. Customer-claimed coverage remains unverified until reviewed.
Unknowns and exceptions
Unknown is a support status, not a low-risk rating. Missing policies, incomplete versions, ambiguous matches and unverified entitlements go into the review queue. Excluded items remain in coverage totals. An accepted exception records the reason, approving customer, owner, compensating controls and review/expiry date; it never changes the underlying support status.
Prioritisation
| Action | Proposed default rule |
|---|---|
| Urgent review | Confirmed loss of applicable support plus customer-confirmed internet exposure or critical service. Ask the owner to assess within two working days; this is not an automatic vulnerability severity. |
| Plan upgrade | Confirmed support ending within 180 days, or unsupported internal software without an urgent exposure flag. |
| Monitor | Applicable support verified beyond 180 days, or verified extended/distribution support. Track the actual support deadline. |
| Review evidence | Uncertain status, conflicting sources, missing entitlement or missing context required for a priority decision. |
| Accepted exception | Customer-approved, time-limited deviation; underlying finding stays visible and reopens when the exception expires. |
Delivery and success measures
Check agreed lifecycle sources daily during the pilot, send a weekly digest, and notify at agreed 180/90/30-day thresholds or a confirmed change in support status. Deduplicate alerts. Inventory freshness is displayed on every report; absent refreshed exports, deployment changes are unknown.
Measure confirmed matches, unknowns, exclusions, incorrect matches, customer-accepted actions, import time and manual review time per customer. Aim for zero falsely “supported” conclusions in the reviewed sample. Test willingness to pay and weekly operating effort before expanding coverage. No coverage percentage is promised before inspecting the inventory.
Handling customer data
Before real onboarding: establish authenticated transfer, per-customer access isolation, encrypted transport and off-server backups, a deletion schedule and agreed retention. Request no passwords, source code or API secrets. The landing-page enquiry does not accept inventories. Pilot intake must be connected separately before real customer data is accepted.
Use the existing DigitalOcean server
For the first small pilot: static pages served by the existing web server, a Python batch job, SQLite and systemd timers. Process one inventory at a time. This avoids a continuously running database/API stack on the smallest machine. Build assets off-server; use an external mail provider and off-server backups.
Check current RAM, free disk and competing processes before deploying. Keep the first batches bounded and measure peak memory. Move to PostgreSQL or a larger machine only when concurrency, data volume or observed load warrants it. No server upgrade is required to build or host this static website.
Launch details still to connect
Confirm the brand/domain and enquiry recipient; wire the enquiry to a real inbox or backend; configure secure inventory intake, scheduled processing and email delivery. The present preview contains the offer, templates and report design. It does not claim that those backend services are live.