feat: Backdoor & Malicious Pattern Detection Provider

[SergUdo]

Backdoor & Malicious Pattern Detection with Deterministic Supply Chain Validation

Summary

Add a dedicated Backdoor & Malicious Pattern Detection provider to ai-slop-gate to identify both unintentional hallucinated dependencies and intentionally harmful patterns, and to verify third-party dependencies against official registries. This addresses risks from AI-native hallucination, slopsquatting, prompt injection attacks, and supply chain poisoning.

Background

As AI coding agents become part of standard CI/CD workflows, two distinct classes of supply chain risk emerge:

1. Unintentional Hallucination — the most common and highest-frequency failure mode. The AI generates imports for packages that simply don't exist. No malicious actor required; vanilla code generation does this routinely.
2. Intentional Slopsquatting & Backdoor Injection — a weaponized variant where attackers exploit the hallucination pattern deliberately, or manipulate agent sessions to insert malicious logic.

This issue tracks both categories, with different detection strategies for each: deterministic registry validation for the first, heuristics and semantic analysis for the second.

Current providers focus on unintentional "AI slop" quality. This issue extends coverage to supply chain identity verification and malicious pattern detection.

Attack Scenarios

• Scenario 0 - Unintentional Hallucination (Most Common): The AI generates an import for @stripe/react-v3 or lodash-extended — packages that sound plausible but simply don't exist in the registry. No malicious intent; the code compiles (TypeScript validates structure, not registry existence), tests pass (the import path is never exercised), and it crashes in production. Deterministic registry validation at CI time catches this category reliably without pattern matching or heuristics.

• Scenario 1 - Intentional Slopsquatting (The Raye-Deng Case): An attacker registers a package like strpie or lodassh in the official npm/PyPI registry, knowing an LLM might hallucinate these names. The package does exist — it's just not the one the developer intended. Harder to detect than Scenario 0 because existence checks alone are insufficient; metadata anomalies (age, popularity) become the primary signal.

• Scenario 2 - Subtle Version/Export Mismatch: An agent hallucinates a specific method or API signature from a different major version than what's installed. An attacker provides a malicious "compatibility" package that matches this hallucinated signature to intercept data. Detection requires verifying not just that a package exists, but that the specific version and specific exports referenced in the code actually match the published package.

• Scenario 3 - Prompt Injection via PR diff: An attacker hides instructions in a file (e.g., in a comment or data fixture). The agent reads this during a review/edit session and inserts a reverse shell or logic bomb in a subsequent generation.

Proposed Detection Signals

1. Deterministic Supply Chain Validation

Catches Scenario 0 reliably; provides complementary signals for Scenarios 1–2.

• Registry Existence Check: Cross-reference every new import/require against official registry APIs (npm, PyPI). 100% block if the package does not exist.
• Package Metadata Anomalies:
  • Age: Flag packages created/updated in the last 72 hours (typical for volatility attacks).
  • Popularity: Flag "standard-looking" packages with suspiciously low download counts (<100/week).
• Export Integrity: Verify that the specific methods or classes referenced in the code actually exist in the published package metadata for the installed version.

2. Obfuscation & Logic Bombs

Complementary heuristic layer for Scenarios 1–3 where deterministic checks are insufficient.

• Runtime Decoding: Base64 or Hex-encoded strings decoded and executed via eval(), exec(), or Function().
• Hidden Network Calls: Outbound requests to non-whitelisted domains or HTTP calls inside non-networking modules (e.g., inside a data model).
• Conditional Triggers: Logic bombs checking for specific environment variables (e.g., if os.environ.get("PROD")) or time-based triggers.

Proposed Implementation

• Module: ai_slop_gate/providers/static/supply_chain_provider.py (deterministic registry validation for Scenarios 0–2)
• Module: ai_slop_gate/providers/static/backdoor_detector.py (heuristic analysis for Scenario 3)
• Registry Client: ai_slop_gate/providers/static/registry_client.py (handles cached API calls to npm/PyPI)

Updated Provider Matrix

Provider	Focus	Verification Method
StaticSecurityProvider	Common vulnerabilities (CVEs), hardcoded secrets.	Pattern matching against known vulnerability signatures.
SupplyChainProvider	Identity & Provenance. Catches hallucinated packages (Scenario 0) and detects slopsquatting (Scenario 1) via metadata anomalies.	Deterministic Registry API Calls (npm, PyPI) to verify existence, age, popularity, and export integrity.
BackdoorDetectorProvider	Intentional Malicious Logic. Detects reverse shells and logic bombs (Scenarios 2–3).	Heuristics & Semantic Analysis of code patterns and behavior signals — complementary to deterministic checks.

Why This Matters for EU Compliance

• NIS2 Directive: Directly addresses the requirement for rigorous supply chain security.
• Cyber Resilience Act (CRA): Ensures development tooling doesn't introduce unverified or malicious dependencies.
• DORA: Enhances resilience of software delivery pipelines for the financial sector.

Acceptance Criteria

• Implement SupplyChainProvider with deterministic registry existence checks (npm, PyPI) — catches Scenario 0 with no heuristics required.
• Implement RegistryClient for cached API calls supporting existence, age, and popularity signals.
• Add detection for "zero-day" packages (low age/low popularity signals) to catch Scenario 1.
• Implement verification of specific exported methods/APIs referenced in AI-generated code to catch Scenario 2.
• Implement BackdoorDetectorProvider with obfuscation detection (e.g., base64/hex eval) for Scenario 3.
• Add comprehensive unit tests covering both malicious and clean code samples.

Labels

enhancement security provider supply-chain commercial-potential eu-compliance future

[raye-deng]

Interesting direction. The supply chain angle you describe (Scenario 2 — AI agent imports a typosquatted package that looks plausible) is one of the most common AI-native failure modes we track, and it's worth noting that it doesn't require a compromised agent to happen — vanilla AI code generation does this routinely just through hallucination.

We've been categorizing these into two buckets:

Unintentional hallucination (most common): The AI generates an import for @stripe/react-v3 or lodash-extended — packages that sound right but simply don't exist on the registry. No malicious intent, but the code compiles (TypeScript validates structure, not registry existence), tests pass (the import path isn't exercised), and it crashes in production. This is actually more dangerous in practice because it happens at much higher frequency than intentional attacks.

Intentional slopsquatting (your Scenario 2): An attacker registers strpie or lodassh knowing AI agents will hallucinate these names. This is the weaponized version, and it's harder to detect because the package does exist — it's just not the one the developer intended.

For the first category, deterministic registry validation at CI time catches these reliably without needing pattern matching or heuristics. For the second category, your proposed obfuscation/behavior signals make sense as a complementary layer.

One thing we've found useful: checking not just whether a package exists, but whether the specific version and specific exports referenced in the code actually match the published package. AI agents frequently reference methods or API signatures from a different major version than what's installed — which is a subtler form of hallucination that passes import resolution but breaks at call sites.

[SergUdo]

Thank you for this breakdown - the distinction between unintentional hallucination and intentional typosquatting is exactly the nuance I was trying to capture, and you've articulated it much more precisely.
The version/exports mismatch point is genuinely new to me. An agent referencing methods from a different major version that passes import resolution but breaks at call sites - that's a subtle failure mode worth adding as a separate signal in this issue.
Which category do you find more dangerous in practice - the hallucinated packages or the version drift?

[SergUdo]

Thanks for the valuable input, @raye-deng! The distinction between unintentional hallucinations and intentional slopsquatting is spot on. I've just updated the proposal to prioritize deterministic registry lookups (existence, age, and popularity) as the primary defense layer. Verifying specific exports is a great catch as well - I've added it to the acceptance criteria. Appreciate you following the project.

[SergUdo]

Testing Strategy Note

Mocks and fixtures alone are insufficient for validating backdoor and
supply chain detection — they test what we imagined, not what actually
exists in the wild.

Registry validation (SupplyChainProvider)
Use VCR cassettes recorded against real npm/PyPI API responses:

• Record once against real registry endpoints
• Replay in CI — tests verify against actual registry behavior, not assumptions
• Cassettes stored in tests/cassettes/

Backdoor pattern detection (BackdoorDetectorProvider)
Use curated datasets of real removed malicious packages:

• Datadog malicious-software-packages-dataset
• OpenSSF malicious-packages

These contain real attack code already removed from npm/PyPI —
legally safe to use for testing, and far more reliable than
hand-crafted fixtures.

Why not mocks?
Mocks that pass regardless of implementation changes create false
confidence. Record real → replay in CI is the only way to verify
the detector works against actual attack patterns.