Security

External / Ask review

Supply chain, dependency audit, and consumer-misuse threat model

Hats
2
Review Agents
2
Review
External, ask
Inputs
Inception, Inception, Development

Dependencies

Inceptiondiscovery
Inceptionapi-surface
Developmentcode

Hat Sequence

1

Security Reviewer

Focus: Evaluate the library against the threat model and determine whether findings are resolved, mitigated, or accepted with documented justification.

Produces: Security review verdict with:

  • Pass/fail per threat — explicit status for each threat in the model
  • Mitigations applied — what code or doc changes resolve each finding
  • Accepted risks — findings explicitly left open with justification and consumer guidance
  • Consumer guidance — documentation consumers need to use the library safely

Reads: Threat model, code, dependency audit output.

Anti-patterns (RFC 2119):

  • The agent MUST NOT accept "low severity" as a resolution — either mitigate or justify with consumer guidance
  • The agent MUST ensure consumer guidance lands in public docs, not just internal notes
  • The agent MUST verify dependency audit findings are actually addressed, not just acknowledged
2

Threat Modeler

Focus: Model threats specific to this library: supply chain risks, misuse by consumers, injection surfaces, and the downstream impact of vulnerabilities in library code. Library threat modeling differs from app threat modeling because the library is a source of risk for downstream applications, not a direct victim.

Produces: Threat model document with:

  • Supply chain surface — direct and transitive dependencies, their CVE history, maintenance status
  • Consumer misuse surface — ways a naive consumer could use the library insecurely (unsafe defaults, injection-prone APIs)
  • Data handling surface — what sensitive data the library touches, how it could leak (logs, error messages, serialization)
  • Injection surface — inputs the library processes that could carry malicious payloads (paths, URLs, shell commands, regexes, serialized data)

Reads: API Surface, code, dependency manifest.

Anti-patterns (RFC 2119):

  • The agent MUST model the library as a potential source of vulnerability for downstream apps, not just as a target
  • The agent MUST verify that unsafe defaults are flagged — libraries inherit blame for consumer misuse when defaults are bad
  • The agent MUST NOT dismiss "consumer would never do that" — consumers will do that
  • The agent MUST surface transitive dependency risks, not just direct ones

Review Agents

Misuse Resistance

Mandate: The agent MUST verify the library's public API is resistant to unsafe use by consumers. Libraries that are easy to misuse are effectively insecure regardless of the internal code quality.

Check:

  • The agent MUST verify unsafe defaults are flagged and either fixed or documented with consumer guidance
  • The agent MUST verify injection-prone entry points have explicit documentation on safe usage
  • The agent MUST verify error messages and serialization do not leak sensitive data to downstream code
  • The agent MUST verify the library does not silently trust inputs that consumers would naturally pass from untrusted sources

Supply Chain

Mandate: The agent MUST verify the library's dependency tree is audited and free of known-vulnerable dependencies before release.

Check:

  • The agent MUST verify the dependency audit tool (npm audit, pip-audit, cargo audit, etc.) has been run and findings addressed
  • The agent MUST verify no direct dependency has a known high/critical CVE without documented mitigation
  • The agent MUST verify transitive dependency risks are assessed, not just direct ones
  • The agent MUST verify dependency licenses are compatible with the library's license
  • The agent MUST flag any dependency with no maintenance activity in 12+ months as a supply-chain risk

Security

Library security focuses on three surfaces: supply chain (transitive dependencies, known CVEs, build reproducibility), public API attack surface (what can a malicious consumer do with this library), and injection vectors relevant to the library's domain (path traversal for filesystem libs, prototype pollution for JS utilities, SSRF for HTTP clients).

Unlike application security, library security has to consider the library as a potential source of vulnerabilities in downstream applications — the threat model is "what if my consumer misuses this."

Completion Signal (RFC 2119)

Dependency tree MUST be audited for known CVEs. Public API MUST be threat-modeled for misuse by consumers. Security findings MUST be resolved or documented with justification and consumer guidance.