The nine-layer security scanner: a deep dive

Every artifact on ai-supply.store passes through nine distinct analysis layers before anyone can install it. This post goes layer by layer, explaining what each check actually does and what a provider can do to sail through cleanly.

All of this runs automatically, on every upload, and is completely free — it's baked into the platform.

---

Layer 1: Malware detection

The scanner compares binary and script content against known malicious payload signatures. This catches:

• Shellcode embedded in binary blobs
• Base64-encoded payloads that decode to malicious scripts
• Known rootkit patterns in model configuration files

Provider tip: If your MCP server bundles a pre-compiled binary, include build scripts so buyers can verify reproducibility.

---

Layer 2: Secrets detection

API keys, private keys, OAuth tokens, and database connection strings have recognisable entropy patterns. The scanner runs a Gitleaks-style pass across every file in the artifact tree — including comments, test files, and .env.example.

# Common findings that WILL fail this layer:
CLIENT_SECRET=sk-prod-abc123xyz     # in any file
token = "ghp_XXXXXXXXXXXX"          # GitHub token
CONNECTION_STRING="postgres://..."  # hardcoded DB

Provider tip: Use process.env.MY_KEY references throughout, and document required env vars in your README. A properly structured .env.example with placeholder values (MY_KEY=your_key_here) does not trigger the scanner.

---

Layer 3: Dangerous code patterns

This layer looks for code constructs that are almost never legitimate in a published capability:

• eval() or exec() called with user-controlled or network-sourced data
• child_process.exec() / subprocess.Popen() with dynamic arguments
• Shell metacharacters in string concatenation paths
• Dynamic require() or import() from user-supplied paths

A code-generation MCP server that calls eval() on its own output is a common false-positive trigger here. If your use case is genuinely legitimate, the REVIEW level allows you to acknowledge the finding.

---

Layer 4: PII detection

This layer is especially important for DATASET and PROMPT listings. The scanner looks for:

• Email addresses, phone numbers, SSNs, passport numbers
• Real names paired with identifiable attributes
• Credit card number patterns

This is not about whether PII could flow through the capability at runtime — it's about PII embedded in the artifact itself (e.g., a training dataset that wasn't properly anonymised).

---

Layer 5: License analysis

The scanner reads dependency manifests and SPDX headers to detect license incompatibilities:

• A listing marked MIT that depends on a GPL library → flagged
• A COMMERCIAL listing that bundles AGPL code → flagged
• Missing license declarations → informational warning

Provider tip: Run license-checker or pip-licenses before uploading and fix incompatibilities upstream.

---

Layer 6: Dependency CVE scanning (osv-scanner)

The scanner reads package.json, requirements.txt, pyproject.toml, and lockfiles, then queries the Open Source Vulnerability (OSV) database for known CVEs in each dependency version.

• CRITICAL severity CVE → contributes to QUARANTINE risk
• HIGH severity → REVIEW
• MEDIUM/LOW → score deduction

Provider tip: Run npm audit --audit-level=moderate or pip-audit before every upload. Pin exact versions so buyers get reproducible dependency trees.

---

Layer 7: Model format integrity (picklescan)

Pickle-based model formats (*.pkl, *.pt, *.pth) can execute arbitrary Python code on load. picklescan inspects the opcodes of every pickle file in the artifact. Findings:

• Any REDUCE/GLOBAL opcode that calls a non-standard Python builtin → QUARANTINE
• Stack manipulation indicating code injection → QUARANTINE

Provider tip: Use safetensors format instead of pickle for all model weights. It's format-safe by design and broadly supported.

---

Layer 8: Prompt injection detection

For PROMPT and TEMPLATE listings (and MCP servers that construct prompts), the scanner looks for patterns designed to override system instructions downstream:

• Ignore previous instructions-style phrases
• Nested XML/JSON that tries to escape prompt contexts
• Separator injection (e.g., ---END SYSTEM PROMPT---)

This layer protects buyers who install a prompt into a production agent — they need confidence the prompt does what it says.

---

Layer 9: Egress analysis

The scanner statically analyses the artifact for unexpected outbound network call patterns:

• Calls to domains not declared in the listing manifest
• DNS lookups constructed from user input (DNS-rebind vector)
• Hardcoded IP addresses (common in C2 beaconing)

---

After the layers: OWASP-AI checklist

Once all nine layers complete, the results are mapped to the OWASP AI Security Top 10 (LLM01–LLM10) and OWASP ML Top 10 (ML01–ML10). This produces the expandable checklist on every listing's Security tab.

For a guide to reading that report, see reading a listing's OWASP-AI security report.

The result

Every artifact gets a score (0–100), a grade (A–D), and a safety level (SAFE / REVIEW / QUARANTINE). See the top-scoring listings on the security leaderboard.

And yes — all of this scans again on every new version you upload.