Versioning and automatic re-scans: keeping security posture current

Publishing a capability isn't a one-time event. Dependencies release CVE patches. Bugs get fixed. New features get added. Every change is an opportunity to improve — or inadvertently introduce — a security issue.

ai-supply.store handles this with automatic re-scanning on every new version upload. Here's how it works and why it matters.

Every version gets its own scan

When you upload a new version of a listing, the full nine-layer scanner runs again from scratch:

• The existing version's score, grade, and level are preserved.
• The new version gets its own score, grade, and level.
• The listing's displayed score updates to the latest version's result.
• Scan history is visible on the Security tab — buyers can see the trend.

This means a listing that was grade B in v1.0.0 might be grade A in v1.1.0 (after a CVE fix) — or grade C in v1.2.0 (after a dependency update introduced a new CVE). The score is honest and current.

Why re-scanning on upload matters

The OSV vulnerability database (queried by osv-scanner) is updated constantly. A dependency that was clean at upload time may have a CVE filed against it six months later. That's outside your control — but re-scanning your listing when you next upload a version catches it.

This is the core reason to maintain your listings actively:

• Upload a new version every time a dependency releases a security patch.
• Treat npm audit / pip-audit output as a trigger for a new upload, not just a local fix.
• Buyers see the version timestamp — a listing last updated 18 months ago signals stale dependencies.

If a new version scans worse than the old one

If your v2.0.0 upload results in QUARANTINE (while v1.0.0 was SAFE), the previous version remains live and installable. Buyers are not disrupted. Your v2.0.0 is blocked until you fix the finding and re-upload.

This means you can iterate safely:

1. Identify the regression (check the Security tab on the blocked version).
2. Fix the root cause locally.
3. Upload v2.0.1 — it scans independently.
4. If v2.0.1 is SAFE, it becomes the new latest and v1.0.0 can be deprecated.

Deprecating old versions

Old versions remain installable via pinned install (npx ai-supply add <slug>@1.0.0) even after you deprecate them. Deprecation:

• Shows a deprecation warning to anyone installing the old version
• Excludes the version from the latest pointer
• Does NOT revoke existing installs

This protects downstream agents that pin versions while steering new installs to the current, better-scanned version.

Viewing scan history

On any listing's Security tab, expand the Version history section:

v1.2.0 (current)  Score: 94  Grade: A  Level: SAFE   2026-06-10
v1.1.0            Score: 87  Grade: B  Level: SAFE   2026-05-15
v1.0.0            Score: 71  Grade: C  Level: REVIEW  2026-04-01

This trend is visible to buyers and factors into the benchmark ranking — a consistently improving score signals an actively maintained provider.

Best practices for version hygiene

1. Pin dependency versions in your lockfile — floating ranges cause scan variance between uploads.
2. Run the deep scan engines locally before uploading (see deep scan engines guide).
3. Upload a new version after any dependency security patch, even if your code didn't change.
4. Keep a changelog — buyers read it before upgrading.
5. Deprecate, don't delete — old pinned installs by agents need the version to remain accessible.

For the full versioning guide, see versioning your capability the right way. Everything described here is free and available to all providers.