DEV Community: Aiden Bolin

How to check which Linux CVEs actually affect your servers in 30 seconds (and which are being exploited right now)

Aiden Bolin — Wed, 17 Jun 2026 16:43:51 +0000

If you run a couple of Linux boxes for a side project or a small SaaS, you've probably had this moment: a CVE hits the news, your monitoring tool spits out 400 "high severity" findings, and you have no idea which ones actually matter. CVSS says everything is a 7.8. You patch nothing, or you patch everything and pray nothing breaks.

The honest truth is that most CVEs on your box will never be exploited. The number you actually care about is small. Here's how to find it fast.

One command, no signup

curl -fsSL https://mindsparkstack.com/scan.sh | bash

It's read-only and anonymous. Nothing is stored server-side, and you can read the script before you run it (you should always read anything you pipe to bash). It reads your distro, kernel version, and dpkg/apk/rpm package list, matches them against the vendor advisories — Ubuntu USN, Debian DSA, Alpine, RHEL — cross-referenced with NVD, and prints back the few CVEs that actually apply to your installed versions. It supports Ubuntu, Debian, Alpine, AlmaLinux, and Rocky.

But matching CVEs to packages is the easy half. The useful half is ranking.

KEV vs EPSS: the two numbers that matter more than CVSS

CVSS scores severity if a vulnerability is exploited. It says nothing about whether anyone is actually exploiting it. Two free, authoritative data sources fix that:

CISA KEV (Known Exploited Vulnerabilities). This is a catalog the U.S. government maintains of CVEs that are being exploited in the wild, right now. If a CVE is on the KEV list, it's not theoretical — someone has a working exploit and is using it. This is your drop-everything signal.

FIRST EPSS (Exploit Prediction Scoring System). A daily-updated probability (0 to 1) that a given CVE will be exploited in the next 30 days. A CVE with EPSS 0.94 is far more urgent than one at 0.002, even if both are "CVSS 7.8."

So the priority order isn't "highest CVSS first." It's:

On CISA KEV → actively exploited → patch today
High EPSS → likely to be exploited soon → patch this week
Everything else → real, but not on fire → schedule it

The scanner sorts findings exploited-first and flags the KEV ones as actively exploited, so the thing at the top of the list is genuinely the thing you should do next.

What the output looks like

Instead of a wall of CVSS scores, you get a ranked, decision-first list with the exact remediation command for each finding:

Illustrative output below — the CVE IDs, package versions, and EPSS scores are placeholders to show the shape of the result, not a real scan. Run the command above to see your own box's actual findings.

[ACTIVELY EXPLOITED]  CVE-XXXX-XXXXX  openssl 3.0.2  (CISA KEV, EPSS 0.91)
  → sudo apt install --only-upgrade openssl

[HIGH RISK]           CVE-XXXX-XXXXX  curl 7.81.0    (EPSS 0.62)
  → sudo apt install --only-upgrade curl

[PATCH WHEN ABLE]     CVE-XXXX-XXXXX  nginx 1.18.0   (EPSS 0.01)
  → sudo apt install --only-upgrade nginx

The point: you don't get a research project. You get a short list and the exact one-liner to fix each item. Triage is already done.

Does it actually work? We dogfood it.

When CVE-2026-31431 dropped — "Copy Fail," a local privilege-escalation bug in the Linux kernel's algif_aead module — we ran this same flow on our own production VPS and had it mitigated in about 30 minutes. The scan also surfaced several other real outstanding CVEs on that box that we then worked through.

We keep the audit log for that machine public: mindsparkstack.com/patch/audit/mss-vps. Timestamped actions, what was found, what was fixed. It's there partly to prove the tool isn't vaporware and partly because an audit trail you can hand someone is genuinely useful.

Where this sits in the ecosystem

To be fair about the alternatives:

Vuls / Trivy / Grype are excellent open-source scanners. If you enjoy self-hosting the scanner, building the triage layer, and writing your own remediation playbooks, use them — they're powerful and free.
Snyk / Tenable / Wiz are the enterprise tier. They're great and they will not sell to a 1-to-3-person shop at a price that makes sense.

The gap in the middle is "I have 3 servers, I don't want a wall of scores, just tell me which few CVEs are on fire and the command to run." That's the niche. The free scan above fills most of it with zero commitment.

The one-line aside

If you want that scan running hourly with real-time alerts and your own audit-log URL instead of running it by hand, there's a managed tier (free for 3 servers; paid plans from $9/mo, 14-day trial, no card) at mindsparkstack.com/patch — but honestly, run the free command first and see if the ranked output is useful to you at all. That's the part that matters.

Vuls vs Trivy vs Grype: when to pick which CVE scanner (from the team that built one more)

Aiden Bolin — Wed, 13 May 2026 19:47:18 +0000

Vuls vs Trivy vs Grype: when to pick which CVE scanner

I shipped a CVE patch-ops tool last month. The most common feedback from engineers, in order:

"Why not just use Vuls?"
"Doesn't Trivy already do this?"
"Isn't Grype better?"

All three are fair. They are all good. Here is the honest comparison I wish someone had handed me before I built mine.

Vuls.io — the original self-hosted host scanner

Vuls is the closest open-source equivalent to a managed patch-ops product. It's mature (started in 2016), in Go, and it does the same fundamental work: pull advisories from the upstream feeds, snapshot your box's package state, match.

Pick Vuls if:

You want everything on-prem / air-gapped — no third party sees your inventory.
You have at least an afternoon of ops time to wire it up (config server, cron, report exporter, your own alerting).
You're comfortable writing your own remediation playbooks. Vuls tells you the package + fixed version; what you do with it is up to you.
You already have a Prometheus/Grafana stack you can plug the JSON output into.

Skip Vuls if:

You're a 1-3 person dev shop and ops time is the bottleneck. You'll set it up, it'll run for two weeks, then a cron will silently fail and you'll forget about it for two months.

Trivy — containers and IaC, host CVEs as a bonus

Trivy from Aqua is the most popular scanner now, but it's container-and-IaC-shaped. It scans images, Dockerfiles, Terraform/CloudFormation, Kubernetes manifests, SBOM files, and yes — also host filesystems via trivy rootfs /. The latter is a real feature, but it's a sidecar to the container story.

Pick Trivy if:

Your security risk is concentrated in container images and you ship a lot of them.
You want SBOM generation + license scanning + secret detection + misconfig in one binary.
You're running Kubernetes and want admission-controller integration.

Skip Trivy for host CVE management if:

Your fleet is bare-metal VPSes (no containers) — you're paying for a container model that doesn't fit your shape.
You want per-host audit URLs that your customers can read, not just a CLI report.

Grype — SBOM-first, simple

Grype from Anchore is the cleanest of the three. Generate an SBOM with syft, pipe it to grype, get findings. It does exactly that and not much else.

Pick Grype if:

You're already producing SBOMs as part of your build pipeline (you should be).
You want a tool that does one thing well — match SBOM packages against the vulnerability DB.
You're scripting CI gates and need predictable exit codes.

Skip Grype if:

You want the fix-action layer ("here is the apt command to run") — Grype is a finder, not a fixer.
You need continuous monitoring of a running host, not a snapshot at build time.

StackPatch — the one I built

Built specifically for indie SaaS shops running 1-3 Linux boxes. The bet is that the gap between "free OSS scanners you have to babysit" and "$25-50K/yr Snyk-class products" leaves out tens of thousands of indie founders. So:

Hosted by us. No apt install vuls. SSH read-only or a small read-only agent, both of which you can revoke instantly.
Action-first. Every finding ships with the exact apt install --only-upgrade pkg=fixed-version one-liner, or the modprobe blacklist syntax for kernel-module CVEs, or the pro attach + apt upgrade flow for Ubuntu Pro / ESM fixes.
Public audit URL per server. A read-only URL you can hand to your enterprise prospects: "here is our security posture, timestamped." Replaces the emailed PDF that's stale a week later.
Indie-priced. $99 lifetime for the first 50 founders, then $19-49/mo. Snyk's smallest sales-team-required tier is roughly 10x that.

Pick StackPatch if:

You're a solo founder or 1-3 person team on Ubuntu / Debian / Alpine / AlmaLinux / Rocky.
You want patch ops to be a 5-minute habit, not a 5-hour setup.
You want a public security URL more than you want CLI integration.

Skip StackPatch if:

You need air-gap / on-prem — use Vuls.
Your scope is container images, not running hosts — use Trivy.
You're already producing SBOMs in CI — use Grype.

Decision matrix

Shape	Best fit
Bare-metal VPS fleet, no security team	StackPatch (hosted) or Vuls (self-hosted)
Container-heavy CI/CD	Trivy
SBOM-driven build pipeline	Grype
Air-gapped / no third party allowed	Vuls
Enterprise + budget + compliance team	Snyk / Tenable / Wiz

The competitive landscape is honest. I'm not pretending StackPatch beats Vuls on universality or Trivy on container coverage. I'm betting on a different problem shape: indie founders who'd pay $19-99 for a hosted patch-ops tool that hands them a per-server URL and an exact remediation command.

If you're in that shape, the free quickscan takes 30 seconds. If you're in a different shape, one of the other three is the right answer — and I'd rather lose the sale than be the wrong tool for your workload.

Full comparison breakdowns are on /patch/vs-vuls, /patch/vs-trivy, and /patch/vs-grype. Comments open — I'll defend or concede whichever way the argument goes.

Matching live CVEs to your actual apt packages in ~800 lines of Python

Aiden Bolin — Wed, 13 May 2026 19:46:42 +0000

Matching live CVEs to your actual apt packages in ~800 lines of Python

41,000+ CVEs are indexed in the NVD right now. The vast majority do not affect you. The interesting engineering question is: which ones do, and what is the exact one-liner to fix them?

I spent a weekend building the matcher. Here is the shape of the problem and the shape of the solution.

The matching problem

A CVE record from one of the upstream feeds (Ubuntu USN, Debian Security Tracker, Alpine secdb, OSV.dev for the RHEL family, NVD as a fallback) looks roughly like:

{
  "id": "USN-7100-1",
  "summary": "OpenSSH client vulnerability",
  "cves": ["CVE-2026-35414", "CVE-2026-35387"],
  "releases": {
    "noble": {
      "binaries": {
        "openssh-client": "1:9.6p1-3ubuntu13.5"
      }
    }
  },
  "published": "2026-05-09T00:00:00Z"
}

Your server, meanwhile, has a snapshot like:

$ dpkg-query -W -f='${Package}=${Version}\n' | head -3
openssh-client=1:9.6p1-3ubuntu13.4
openssh-server=1:9.6p1-3ubuntu13.4
openssh-sftp-server=1:9.6p1-3ubuntu13.4

Match logic: for each advisory, intersect on package name. For every hit, compare the installed version against the fixed version using dpkg --compare-versions. If installed lt fixed, you are affected; emit the exact apt install <pkg>=<fixed> one-liner.

The actual matcher loop

The core is brutally simple:

import subprocess
from pathlib import Path

def is_affected(installed: str, fixed: str) -> bool:
    """Wrap dpkg --compare-versions. Returns True if installed < fixed."""
    rc = subprocess.run(
        ["dpkg", "--compare-versions", installed, "lt", fixed],
        check=False,
    ).returncode
    return rc == 0


def match_advisory(advisory: dict, inventory: dict[str, str], codename: str):
    fixes = advisory.get("releases", {}).get(codename, {}).get("binaries", {})
    for pkg, fixed_version in fixes.items():
        installed = inventory.get(pkg)
        if installed and is_affected(installed, fixed_version):
            yield {
                "advisory": advisory["id"],
                "cves": advisory["cves"],
                "package": pkg,
                "installed": installed,
                "fixed": fixed_version,
                "remediation": f"sudo apt update && sudo apt install --only-upgrade {pkg}={fixed_version}",
            }

Run that over the full advisory cache (USN + DSA + Alpine secdb + OSV-RPM) against dpkg-query output, and you get a per-server findings list in seconds.

Where it gets interesting

The version compare is the easy part. The hard parts are the edge cases.

1. Kernel-module CVEs. Some CVEs aren't a package version bump at all. CVE-2026-31431 (the "Copy Fail" algif_aead local-priv-esc, disclosed late April) was patched at the upstream kernel level — but Ubuntu had not shipped a fixed kernel for noble at advisory time. So apt install --only-upgrade linux-image-generic was a no-op. The correct mitigation was a modprobe blacklist:

# /etc/modprobe.d/cve-2026-31431-copyfail.conf
blacklist algif_aead
install algif_aead /bin/false

So the matcher needs a playbook_class field on each advisory: apt_upgrade, kernel_reboot, modprobe_block, apt_upgrade_esm (Ubuntu Pro), oss_only_fix. The default is apt_upgrade; the rest are hand-curated for kernel/firmware CVEs because the upstream feeds don't tag them.

2. Ubuntu Pro / ESM. Many "fixed" Ubuntu CVEs are fixed only in Ubuntu Pro (the ESM channel). Free for personal + small-team use, but the fix won't apply without attaching a Pro token. The matcher emits a different playbook for those:

sudo pro attach <token>
sudo apt update && sudo apt install --only-upgrade <pkg>

3. Multi-arch and source vs binary package confusion. libssl3 (binary) and openssl (source) are both real package names. The advisory binaries map is the source of truth — match on that, not the source name.

4. Apt pinning and snapshot repos. If a customer is pinned to an older noble-updates snapshot, the fixed version may not be installable on their box. The matcher flags this as a remediation_blocked: pin_conflict state instead of pretending the fix is one apt command away.

The feed plumbing

The actual fetcher is 9 cron jobs:

stackpatch-usn-poller.py — every 30 minutes, polls https://ubuntu.com/security/notices.json
stackpatch-dsa-poller.py — every 30 minutes, parses https://security-tracker.debian.org/tracker/data/json
stackpatch-alpine-secdb-poller.py — every hour, fetches alpine-secdb branch refs
stackpatch-osv-rpm-poller.py — every hour, OSV.dev RHEL/AlmaLinux/Rocky ecosystems
stackpatch-nvd-poller.py — every 6 hours, NVD modified feed as a backstop
stackpatch-matcher.py — every hour, runs the match loop against the inventory cache
stackpatch-index-builder.py — twice daily, regenerates the per-CVE static pages
stackpatch-alert-dispatcher.py — every 15 minutes, fans out new findings to email/Telegram/Discord webhooks
stackpatch-customer-backup.py — daily, snapshots inventory + findings per server

State lives as JSONL at /var/lib/stackpatch/{advisories,findings,inventory}/. Not a database — for fewer than 10,000 servers, JSONL + atomic rename is faster and easier to back up than Postgres. A V2 with FTS will probably move it, but premature SQL is a tax.

The "use it on yourself" rule

The first server we pointed the matcher at was our own production VPS — the one this blog is served from. The matcher found 4 outstanding CVEs we hadn't seen. We patched 3 (the OpenSSH set) within an hour; the 4th is gated on attaching a Pro token, which is correctly flagged. That ratio — "matcher finds real CVEs on its own author's box" — is the only credibility test I trust for a security tool.

If you run Linux on a VPS and you don't have a continuous CVE-to-action pipeline, the free quickscan takes about 30 seconds. Or read the open methodology page. I'm @aiden_bolin in the comments if you have edge-case advisories the matcher misses — that is exactly the feedback I'm hunting for right now.

The indie SaaS security stack I run on a $7/mo VPS

Aiden Bolin — Wed, 13 May 2026 19:46:06 +0000

The indie SaaS security stack I run on a $7/mo VPS

When you're a 1-3 person dev shop, you can't afford Snyk and you don't have a security team. You also can't afford to get breached. Here's the full stack I actually run on the $7/mo Hostinger VPS that serves my production SaaS.

This is not a "best practices" article. Every line below corresponds to a config file in production right now.

1. UFW — block everything by default

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Five commands. The single largest reduction in attack surface you can make in 30 seconds. Verify with sudo ufw status verbose.

2. SSH keys only, no passwords

/etc/ssh/sshd_config.d/00-hardening.conf:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3

sudo systemctl restart ssh. Now password brute-force attempts hit a wall on the first packet.

3. fail2ban — auto-ban brute-forcers

sudo apt install fail2ban

/etc/fail2ban/jail.local:

[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 3600

Three failed SSH attempts in 10 minutes → IP banned for an hour. Check sudo fail2ban-client status sshd after a week — you'll see hundreds of banned IPs. Most of the noise just stops.

4. unattended-upgrades — apt patches without you

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

/etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESM:${distro_codename}";
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Mail "ops@yourdomain.com";

I deliberately leave Automatic-Reboot "false" because a 3am reboot during traffic is its own incident. Instead, see step 6.

5. Stripe webhook signature validation

If you take payments, every webhook handler must verify the signature header. Without this, anyone can POST customer.subscription.created events at your endpoint and grant themselves access.

import Stripe from 'stripe'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)

export async function POST(req: Request) {
  const sig = req.headers.get('stripe-signature')
  if (!sig) return new Response('missing signature', { status: 400 })

  const body = await req.text()
  let event: Stripe.Event
  try {
    event = stripe.webhooks.constructEvent(
      body,
      sig,
      process.env.STRIPE_WEBHOOK_SECRET!,
    )
  } catch {
    return new Response('invalid signature', { status: 400 })
  }
  // ... safe to process
}

Fail closed. If STRIPE_WEBHOOK_SECRET is unset, return 503 — never silently skip the check.

6. Kernel patching with an actual reboot strategy

This is the part most indie shops skip. unattended-upgrades installs the new kernel but won't reboot. The running kernel stays vulnerable.

/usr/local/bin/kernel-patch-check.sh:

#!/usr/bin/env bash
running="$(uname -r)"
installed="$(dpkg -l 'linux-image-*' | awk '/^ii/ {print $2}' | tail -1 | sed 's/linux-image-//')"
if [ "$running" != "$installed" ]; then
  echo "Reboot pending: running=$running installed=$installed" \
    | mail -s "Kernel patch ready on $(hostname)" ops@yourdomain.com
fi

Cron it hourly. Get an email the moment a new kernel ships and is installed. Then you reboot during your next low-traffic window — manually, with eyes on the systemd units coming back up.

7. The CVE-to-action layer (the missing piece)

Steps 1-6 cover known-class vulnerabilities being delivered via apt. They don't cover the case where:

A CVE drops for a kernel module (CVE-2026-31431 / "Copy Fail", late April) and no Ubuntu kernel fix is shipped yet — you need a modprobe blacklist for the affected module, not an apt update.
A CVE is fixed only in Ubuntu Pro (ESM) and your free Ubuntu install can't see the fix — you need to attach a free Pro token first.
You want to know within 5 minutes that an advisory landed for your stack, not when the cron mail eventually arrives.

I tried Snyk's free tier. Hit the 200-vulns/mo limit in under a week. Their smallest sales-team-required tier was ~$25K/yr. I tried Vuls.io — works, but I spent more time tuning it than I would have spent reading the advisories myself.

So I built StackPatch for exactly this shape. SSH read-only or small read-only agent. Continuous match against the upstream feeds (USN, DSA, Alpine secdb, OSV.dev for RHEL family). Per-server public audit URL. Exact remediation command per finding — including the modprobe-blacklist case, not just apt upgrade.

$99 lifetime for the first 50 founders, then $19-49/mo. The free quickscan is a one-liner you can curl right now without signing up:

curl -fsSL https://mindsparkstack.com/scan.sh | bash

That'll spit out your kernel + apt package state matched against the live USN feed. No data sent anywhere unless you opt into the waitlist + monitoring at the end.

The honest pitch

This stack — UFW, SSH hardening, fail2ban, unattended-upgrades, kernel patch checker, webhook signature validation, and a CVE-to-action layer — covers most of what a security team would set up for a small Linux fleet. The first six pieces are free and take about an hour. The seventh piece is the gap most indie shops just live with, because the existing tools are either ops-heavy or enterprise-priced.

If you have a more complete stack, the comments are open and I will steal from you. If you're missing pieces, the free quickscan will tell you which ones in 30 seconds.

I built a CVE patch-ops tool for indie SaaS shops in a weekend (open scan, honest comparison vs vuls.io)

Aiden Bolin — Fri, 01 May 2026 14:02:25 +0000

I built a CVE patch-ops tool for indie SaaS shops in a weekend (open scan, honest comparison vs vuls.io)

Last week Hostinger emailed every customer about CVE-2026-31431 — the "Copy Fail" Linux kernel local-privilege-escalation. A 732-byte Python script gets root via algif_aead AF_ALG + splice(). Every kernel between 2017 and the upstream fix in early 2026.

I run a one-person SaaS on a Hostinger VPS. I read the advisory, dropped a modprobe blacklist, and was patched in 30 minutes. Then I realized: most indie SaaS founders running their own boxes wouldn't read that email until tomorrow. Some would never read it at all.

Patch ops for the indie-SaaS tier doesn't exist. vuls.io is great if you have a security engineer with half a day. Enterprise tools are unaffordable. The gap is "I have 1–10 Linux servers, I know I should patch, the workflow is too annoying to do consistently."

So I built StackPatch — curl https://mindsparkstack.com/scan.sh | bash for a free anonymous CVE check, $99 lifetime founder seat for hourly monitoring with a public audit URL.

This post is the build log: architecture, the honest vs-vuls comparison, and the bash one-liner you can run on your VPS in five seconds to see what it does.

The free quickscan: 5 seconds, 0 signup

curl https://mindsparkstack.com/scan.sh | bash

The script reads /etc/os-release, uname -r, the top 200 packages from dpkg-query, and POSTs them to a public API. The API runs the live USN feed (Ubuntu) and the Debian Security Tracker (~110K fix-records across bookworm/trixie/bullseye) against your inventory using dpkg --compare-versions, returns matching CVEs with the exact remediation command.

The source is served as text/plain so you can curl https://mindsparkstack.com/scan.sh and read it before piping to bash. No persistent state server-side beyond a 5-min cache. No identifying info collected (no hostname, no IP, no env vars).

On a real noble box with openssh-client 1:9.6p1-3ubuntu13.10:

=== StackPatch quickscan ===
  distro:   ubuntu
  codename: noble
  kernel:   6.8.0-100-generic
  packages: 187

⚠️  2 active CVE matches on your stack right now (worst: high).
   Run the recommended commands above. To monitor every server hourly...

  [HIGH] CVE-2026-31431  Linux kernel "Copy Fail" — local-priv-esc via algif_aead
        why: Linux kernel local-priv-esc; 732-byte Python script gets root...
        match: Running kernel: 6.8.0-100-generic
        recommend: Apply persistent modprobe blacklist for algif_aead now...

  [HIGH] USN-8222-1  OpenSSH 9.6p1 vulnerabilities
        match: openssh-client: installed 1:9.6p1-3ubuntu13.10 < fixed 1:9.6p1-3ubuntu13.16
        recommend: sudo apt-get install --only-upgrade -y openssh-client

That's the demo. Five seconds, real CVEs, exact commands.

Architecture: file-based, Python stdlib, no DB

The whole backend is JSONL files on disk + cron + a small Next.js layer. There's no Postgres. There's no Kubernetes. The matcher is one Python script:

# Pseudocode of the matcher join
for usn in cached_usns:
    for pkg in usn.release_packages[user_codename]:
        installed = user_inventory.packages.get(pkg.name)
        if installed and dpkg_lt(installed, pkg.fixed):
            yield Finding(usn, pkg, installed, fixed)

A few details that mattered:

Use dpkg --compare-versions for Debian-policy-correct version comparison. Lexicographic compare is wrong for 1:9.6p1-3ubuntu13.10 vs 1:9.6p1-3ubuntu13.16 (lex says "10" > "16"). Spawning dpkg once per pair is cheap.
Pre-filter by codename. USN release_packages is keyed by noble | jammy | focal | bionic. Reading the user's /etc/os-release VERSION_CODENAME upfront lets the matcher skip 90% of records.
Cap the USN window. I scan the last 200 USNs (sorted by ID). Older ones are fine to stale; if a 2017 USN matters to your 2024 box, you have bigger problems.
Debian Security Tracker is huge. The tracker.json is 70 MB with 36K fix-records per release. I pre-build per-codename indexes ({package: [{cve, fixed_version, urgency}]}) once daily so the matcher loads ~12 MB instead of 70 MB per request.

Inventory + matcher run on three crons:

3 * * * *           inventory   (reads /etc/os-release, uname, dpkg, docker, ports, modprobe)
23,53 * * * *       USN poll    (Ubuntu Security Notices feed, twice hourly)
0 4 * * *           DSA poll    (Debian Security Tracker, daily — file is huge)
33 * * * *          matcher     (joins inventory × USN × DSA, writes findings JSONL)
40 * * * *          alerts      (emails customers when findings change)

That's the whole thing. The Next.js layer is a thin wrapper that exposes:

/api/stackpatch/quickscan — anonymous POST, returns matches in <1s
/api/stackpatch/enroll — paid customer enrolls a server with a token, returns audit URL
/api/stackpatch/inventory — authenticated inventory POST from the agent
/patch/audit/<slug> — public posture page per server

The killer workflow: the public audit URL

This is what I didn't see in any other tool. Every monitored server gets a URL like:

https://mindsparkstack.com/patch/audit/mss-vps

It shows current findings, applied mitigations, recent resolutions, package counts, kernel state. Updates hourly. Customers (or your customers' enterprise prospects) can verify your security posture without an NDA, without a stale PDF.

When a $3K/year customer asks "how do you handle server security updates?" — you send the link. Done.

This isn't a security scanner. It's a security-response receipt. That distinction is the whole reason the product exists.

Honest vs vuls.io

vuls.io is the obvious comparison. It's free, OSS, mature since 2016, 10K+ GitHub stars, supports Ubuntu/Debian/RHEL/CentOS/Amazon Linux/openSUSE/Alpine/FreeBSD/Windows.

I built /patch/vs-vuls as an honest 12-row green/red/grey side-by-side. Honest enough that the page actively recommends vuls.io if you fit those constraints:

You have a security engineer with half a day to set up go-cve-dictionary + goval-dictionary + gost + cve-search and rebuild them on cron
You need FreeBSD / Windows / openSUSE support
Compliance forbids any package data leaving your network

Pick StackPatch instead if:

You're a one-person SaaS shop with 1–10 boxes on Ubuntu, Debian, Alpine, AlmaLinux, or Rocky Linux
You want the answer in 5 minutes, not half a day
You want the exact apt / apk / dnf / kernel-reboot / modprobe-blacklist one-liner, not just a CVE link
You want a public audit URL for sales due diligence

If a Sunday-afternoon scanner project sounds fun: vuls.io. If you want to be patched and provably so by tomorrow morning: StackPatch.

What V1 doesn't do

I'm not going to lie about the gaps:

No FreeBSD / Windows / openSUSE yet (V1+ covers Ubuntu, Debian, Alpine, AlmaLinux, Rocky Linux — 18 release versions across those 5 distros, 41K unique CVEs cross-indexed from USN + DSA + Alpine secdb + OSV-rpm + NVD)
No auto-apply (deliberate — you should review the command, security-product trust is fragile)
No multi-user RBAC, no SSO, no compliance attestations (this is for solo founders, not security teams)
No Kubernetes (out of scope for V1; you're not running k8s on a $5/mo VPS anyway)
No SLA on remediation (we tell you the command; you run it)

If any of those are dealbreakers, vuls.io or an enterprise tool is the right call.

Pricing: $99 lifetime for the first 50

Free quickscan: anonymous, no signup, no limits. Run it on as many boxes as you like.
$99 lifetime founder seat: 3 servers, hourly monitoring, real-time email alerts, public audit URL, every V2+ feature included. 50 only, then it's a monthly subscription tier.

There's no growth-hack reason for the lifetime price. It's a forcing function — a recurring-revenue product is cheaper for me long-term but it lets me delay shipping. Lifetime sales mean I have to keep adding founders, which means I have to keep shipping.

Try it

curl https://mindsparkstack.com/scan.sh | bash

Source: https://mindsparkstack.com/scan.sh (read first, then pipe).
Comparison: https://mindsparkstack.com/patch/vs-vuls
Live demo audit: https://mindsparkstack.com/patch/audit/mss-vps (our own VPS, public)
Buy ($99 lifetime, 50 only): https://mindsparkstack.com/patch

Comments welcome — what's missing, what's wrong, what would make you switch from vuls.io. I read everything.

Aiden runs MindSparkStack. StackPatch is the patch-ops layer. Source: this is shipped on Hostinger, with Next.js 16 + Python stdlib + cron, running on the same VPS whose audit URL is public above.