Staying on Top of Vulnerabilities When You're a Team of One

Look at the last couple of years:

And that's before last month. October 2026 alone brought:

• GitLab CVE-2026-97229, CVSS 10: unauthenticated code execution on self-managed GitLab through a crafted regex in a CI config. Added to CISA's exploited list on 29 October.
• Node.js security release on 21 October for ten issues, headlined by a Brotli decoder bug (CVE-2026-111497) with a public proof of concept. CISA added it to the exploited list six days later. Fixed in 22.23.4, 24.22.1 and 26.12.1; Node 20 and older get nothing.
• LiteLLM 1.107.0, published to PyPI and Docker Hub with a credential stealer on the same day. It was live for about two hours. LiteLLM's second compromise this year.
• PHP CVE-2026-109618 and CVE-2026-109619, added to CISA's exploited list on 26 October.

If you run a product alone, or with two or three people, reading that list raises one question: how is anyone supposed to keep up with this? Nobody's job is "security". It's yours, along with billing, support, and the landing page.

The good news is that almost every item above was either blocked or caught fast by something free. Pinning actions to a commit SHA defeated the Trivy and tj-actions attacks. A few days' install delay skipped the axios, LiteLLM and most worm releases. Dependabot alerts flagged React2Shell as soon as the advisory was published. You don't need a platform with a dashboard. You need the right alerts switched on, a way to stop bad packages from landing in the first place, an eye on the news for the things those alerts don't cover, and fifteen minutes a week.

This post sorts the options by what they cost, because that's usually the first question. Prices are as of November 2026; check each pricing page before you commit, because they move.

What you're actually covering

A small product has five places where vulnerabilities come from:

1. Dependencies. Known CVEs in packages you installed. This is most of the volume.
2. Supply chain. Packages that are malicious on purpose, like a hijacked maintainer account publishing a credential stealer. These don't have CVEs when they hit you.
3. Your own code. SQL injection, missing auth checks, unsafe deserialisation.
4. Secrets. API keys committed to git or printed in CI logs.
5. CI and infrastructure. GitHub Actions, container images, cloud config.

The free tools below cover all five reasonably well. The paid ones mostly add convenience, private-repo coverage and less noise.

Tier 1: Free and already built into GitHub

If your code is on GitHub, start here. It takes ten minutes and costs nothing.

Dependabot alerts and security updates are free on every repo, public or private. Alerts tell you when a dependency has a known advisory; security updates open a pull request that bumps it to a fixed version. Turn both on under Settings → Code security.

Dependabot version updates keep everything else current, so a security fix is a small bump instead of a three-major-version migration. You configure it with a file:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    groups:
      minor-and-patch:
        update-types: [minor, patch]
    cooldown:
      default-days: 3
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly

Two things in there matter for a solo maintainer. Groups turn twenty PRs into one, which is the difference between reading them and ignoring them. Cooldown makes Dependabot wait until a release has been out for a few days before proposing it. Since July 2026 a three-day cooldown is the default for version updates; security updates still open immediately.

The github-actions entry is easy to forget, and it's the one that keeps your CI pinned actions current.

Free on public repos only: secret scanning with push protection, CodeQL code scanning, the dependency review action, and private vulnerability reporting (so researchers can tell you about a bug without opening a public issue). If your repo is open source, switch all of them on. On private repos these are paid, which is where Tier 2 comes in.

Tier 2: Free and open source

These run locally, in a pre-commit hook, or in CI, on private repos too, with no account.

The Trivy caveat is a lesson about this whole category. In March 2026, attackers force-pushed malicious code to almost every version tag of trivy-action, so anyone using aquasecurity/trivy-action@v0.x ran a credential stealer inside their CI. A security scanner was the attack vector.

The fix is the same for every action you use: pin to a full commit SHA, not a tag, and let Dependabot's github-actions updates bump the SHA for you.

# not this
- uses: some-org/some-action@v2
# this
- uses: some-org/some-action@8f4b7f84864484a7bf31766abe9204da3cbe65b3 # v2.1.0

Tier 3: Free tiers of commercial platforms

If you want one dashboard instead of five CLIs, these free tiers are generous enough for a small product. They differ mostly in how many people and repos they allow.

Socket is the odd one out and the one I'd add first. Everything else on this list finds packages with known vulnerabilities. Socket looks at what a new version actually does, which is how you catch a worm like 2025's Shai-Hulud before an advisory exists.

The catch with free tiers is that they're free until your team grows past the limit, and then the next step is usually a big one.

Tier 4: Pay once (or close to it)

Honest answer: almost nobody in this space sells a one-time licence any more. Security tooling is subscription-shaped because the vulnerability data underneath it changes daily.

What you can do is self-host free software and pay only for the server:

• OWASP Dependency-Track ingests SBOMs from all your projects and tracks every component against several vulnerability feeds. One dashboard for everything you ship, on a small VPS.
• DefectDojo collects results from the scanners above into one triage queue.
• SonarQube Community Build does code quality and basic security rules, self-hosted.

The other genuinely one-off spend is a pentest before a big launch or an enterprise deal. Expect it to start in the low thousands of dollars. It's worth it once you have customers who will ask for a report; before that, the free tools find more per dollar.

Tier 5: When paying monthly is worth it

Pay when a free tool's limit is costing you more time than the subscription costs money. For a small team that's usually one of these:

• GitHub Secret Protection ($19 per active committer/month) if you have private repos and want push protection to block secrets before they're pushed. For two committers, that's cheap insurance against a leaked Stripe key.
• GitHub Code Security ($30 per active committer/month) for CodeQL and dependency review on private repos. Worth it if your code is private and you'd rather not maintain Semgrep in CI.
• Snyk Team or Socket Team (both around $25 per developer/month) when you hit the free test or member caps.
• Aikido paid plans (from roughly $350/month) only once you have several people and want one tool for everything. That's a small-company price, not a solo one.

Stop bad packages before they land

The scanners above react to known problems. The cheapest defence against the unknown ones is to not install brand-new releases.

Most malicious package versions are caught and pulled within hours to a few days. If your tools refuse anything younger than that, you skip most of them without doing anything:

• pnpm has minimumReleaseAge, and since pnpm 11 it defaults to 1,440 minutes (24 hours).
• npm added min-release-age (in days) in npm 11.10.
• Dependabot and Renovate both have cooldowns, as above.

Keep the numbers consistent. If pnpm refuses packages under a day old but Dependabot proposes them at zero days, you'll get PRs that fail pnpm install --frozen-lockfile in CI.

Also: commit your lockfile, use npm ci or --frozen-lockfile in CI, and set permissions: contents: read at the top of every workflow so a compromised step can't push code.

Put an agent on watch

Everything so far watches your lockfiles. But look at October again: Node.js, PHP and self-hosted GitLab aren't in package.json. Neither is the Postgres image in your compose file, the WordPress install running your marketing site, or the LiteLLM proxy from that side project. Dependabot won't tell you about any of them.

This is a good job for a personal agent. It's boring, it's daily, and it's mostly reading. Give it three things:

1. A list of what you run. A plain stack.md works: runtimes and versions, self-hosted services, base images, plus your lockfiles. For more detail, generate an SBOM with Syft or cdxgen.
2. Free feeds to check. The OSV API for packages (it includes MAL- entries for known malicious releases, not just CVEs), the GitHub Advisory Database, CISA's KEV feed for what's being exploited, and the security pages of your runtimes and services.
3. A way to reach you. Telegram, Slack, email or a push notification. Not a dashboard you have to remember to open.

Then schedule it. A Claude Code or Codex scheduled task, an n8n workflow, a cron job running claude -p, or a scheduled GitHub Action all work. The prompt can be this simple:

Every morning at 8:00:
1. Read stack.md and the lockfiles in ~/code/*.
2. Check OSV, GitHub Advisories and the CISA KEV feed for anything published in
   the last 24 hours that matches a package, runtime, image or service I use.
3. For each match: is my version affected? Is it on KEV or high EPSS? Is there a
   fix, and what's the exact upgrade command?
4. If nothing matches, send nothing. If something is exploited or critical,
   message me now. Everything else goes in a Friday digest.

The "send nothing" line matters most. An agent that messages you every day gets muted by Wednesday.

You don't even need a model for the simplest version. This one-liner prints anything CISA added to KEV in the last day that mentions your stack:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r --arg since "$(date -d '1 day ago' +%F)" \
    '.vulnerabilities[] | select(.dateAdded >= $since)
     | "\(.cveID) \(.vendorProject) \(.product): \(.vulnerabilityName)"' \
  | grep -i -E 'node|php|gitlab|postgres|nginx|redis'

The agent's value on top of that is judgement: matching versions, reading the advisory, and telling you whether a bug in a Brotli decoder actually touches code you run.

Two rules for the agent itself:

• It reports, you act. Give it read access and a notification channel, not npm publish tokens, deploy keys or permission to merge. Advisory text is text from strangers on the internet, and an agent that acts on it can be steered by it.
• It's software too, so it's on the list. LiteLLM is an AI gateway; its compromised release targeted exactly the kind of machine that runs agents. Your agent's dependencies go in stack.md like everything else.

The setup, in order

If you do nothing else, do this, in about an hour:

1. Turn on Dependabot alerts and security updates on every repo.
2. Add a dependabot.yml with grouping, a cooldown, and a github-actions entry.
3. Pin your GitHub Actions to commit SHAs and set read-only default permissions.
4. Add Gitleaks as a pre-commit hook.
5. Add OSV-Scanner (or your package manager's audit) and Semgrep CE to CI.
6. Install Socket's free GitHub app, or another supply-chain check.
7. If the repo is public, enable secret scanning, CodeQL and private vulnerability reporting.
8. Write a stack.md and point an agent, or at least a cron job, at it and the free feeds.

The weekly routine

Tools only help if you read what they say. Block fifteen minutes a week:

• Merge the grouped Dependabot PR if CI is green.
• Triage new alerts by exploitability, not severity. A "critical" in a dev-only dependency matters less than a "medium" in your auth path. Check whether the CVE is on CISA's Known Exploited Vulnerabilities list or has a high EPSS score; if it is, fix it today.
• Dismiss with a reason when something doesn't apply, so it doesn't come back next week.
• Read your agent's Friday digest, and add anything new you started running to stack.md.

That's the whole system. A solo founder can't match a security team, but most small products don't get breached through clever zero-days. They get breached through a two-year-old dependency, a key in a commit, or a CI action nobody pinned. All three are free to fix.

The timeline at the top will have new rows by next month. Always keep your eye, or your agent's eye, on CVEs.