# Vulnerability checklist (/security/vulnerability-checklist)



This is the working checklist behind Zumik's [security posture](/security/overview). Each class is verified continuously, not signed off once. Use it as the scope for security reviews, penetration testing, and automated scanning targets.

## Access control and tenancy [#access-control-and-tenancy]

<AccordionGroup>
  <Accordion title="Broken access control">
    Authorization is enforced on every API endpoint; no endpoint is reachable by a caller lacking the required project or tenant permission. BOLA and IDOR patterns are tested explicitly: one tenant must not be able to reach another tenant's artifacts, sessions, branches, API keys, billing records, or purge receipts by manipulating IDs.
  </Accordion>

  <Accordion title="Multi-tenant data leakage">
    Every object is namespaced by tenant ID at the database layer, never relying solely on application-layer filtering. Destructive cross-tenant isolation tests run in CI and attempt to access one tenant's data with another tenant's credentials. Shared cache paths are tested for cross-tenant KV bleed. See [tenant isolation](/security/tenant-isolation).
  </Accordion>

  <Accordion title="Authentication failures">
    Credential-strength requirements are enforced; account lockout follows repeated failures; credential verification uses constant-time comparison; all sessions are invalidated on password change; and error messages do not reveal whether an email is registered.
  </Accordion>
</AccordionGroup>

## Cryptography and secrets [#cryptography-and-secrets]

<AccordionGroup>
  <Accordion title="Cryptographic failures">
    TLS 1.2 minimum (TLS 1.3 preferred) everywhere; no deprecated algorithms (MD5, SHA-1, RC4, DES); data at rest encrypted with AES-256-GCM or equivalent; HMAC-SHA256 for internal fingerprinting; documented key-rotation schedule; API keys stored only as a hash with a prefix, never plaintext.
  </Accordion>

  <Accordion title="Secrets exposure">
    Commits are scanned for secrets with automated detection; any exposed secret is rotated immediately; API keys, tokens, and passwords are never logged; all secrets live in a centralized secret manager with access auditing; secrets never appear in environment dumps or error responses.
  </Accordion>
</AccordionGroup>

## Application and input [#application-and-input]

<AccordionGroup>
  <Accordion title="Injection">
    All database queries are parameterized, never built by string concatenation; external input is validated and sanitized at every service boundary; CI scans for injection; the same standard applies to internal service-to-service calls.
  </Accordion>

  <Accordion title="Server-side request forgery (SSRF)">
    Outbound URL targets are validated and allowlisted before any request made on behalf of user-supplied input; requests to RFC 1918, link-local, and cloud-metadata endpoints from user-controlled URLs are blocked; SSRF protections apply especially in BYOC webhook and callback flows.
  </Accordion>

  <Accordion title="Mishandling of exceptional conditions">
    Unhandled exceptions are caught at service boundaries; client error responses never include stack traces, internal service names, database query text, or secrets; full detail is logged internally while generic messages go out externally.
  </Accordion>

  <Accordion title="Race conditions">
    Branch append operations use database-level optimistic locking (compare-and-swap); billing mutations and inference requests use idempotency keys; concurrent mutations are tested explicitly in integration tests. See [branches](/concepts/branches) and [idempotency and retries](/guides/idempotency-and-retries).
  </Accordion>
</AccordionGroup>

## Configuration and supply chain [#configuration-and-supply-chain]

<AccordionGroup>
  <Accordion title="Security misconfiguration">
    No default credentials on any deployed service; verbose errors and stack traces never reach clients; unnecessary ports, services, and admin interfaces are disabled or firewalled; Cloudflare, Kubernetes, and database configuration are reviewed against hardening baselines.
  </Accordion>

  <Accordion title="Software supply chain failures">
    All dependency versions are pinned with a lock file per ecosystem; SBOMs are generated and verified for container images; builds are signed with provenance attestation; dependencies are scanned for CVEs with enforced remediation SLAs.
  </Accordion>

  <Accordion title="Software or data integrity failures">
    All deployable artifacts are signed and signatures are verified before deployment; third-party downloads are checksum-verified; unsigned BYOC operator packages are not trusted; Kubernetes admission controllers enforce signed-image policies.
  </Accordion>

  <Accordion title="Insecure design">
    Threat models are maintained for every surface (auth, inference, billing, purge, BYOC operator); security requirements are documented before a feature is built and validated in design review before implementation.
  </Accordion>
</AccordionGroup>

## Availability and observability [#availability-and-observability]

<AccordionGroup>
  <Accordion title="Denial of service and resource exhaustion">
    Request body size limits and maximum token counts are enforced before dispatch; rate limits apply at Cloudflare, the gateway, and the API core; timeouts are enforced on all outbound provider and runtime calls; circuit breakers guard provider adapters. See [rate limits](/guides/rate-limits).
  </Accordion>

  <Accordion title="Security logging and alerting failures">
    Authentication events, authorization decisions, API-key usage, billing state changes, and purge operations are logged; security logs go to an immutable, tamper-evident store; alerts fire on anomalous patterns (failed-auth spikes, unusual purge volume, unexpected BYOC admin actions) and are tested in staging.
  </Accordion>
</AccordionGroup>

## AI-specific [#ai-specific]

<AccordionGroup>
  <Accordion title="Supply-chain trust of AI providers">
    A documented response plan exists for a provider compromise; model output is checked for unexpected control sequences before forwarding; provider responses are not cached beyond their stated TTL; [capability manifests](/concepts/capability-manifests) are audited on each provider API update.
  </Accordion>

  <Accordion title="Prompt injection">
    User input is treated as untrusted data, never as instructions. The system-prompt boundary is enforced in the prompt-construction layer, not in the model; the rendered prompt always places system context before user content with a clear delimiter; known jailbreak patterns are tested in CI; sessions that repeatedly trigger policy violations are rate-limited or terminated.
  </Accordion>

  <Accordion title="Excessive agency and tool abuse">
    Any customer-facing chat widget has no side-effecting tools (no key creation, billing mutation, data deletion, or session writes); tools are restricted to read-only documentation lookups; every tool call is validated against an allowlist before execution and logged with its arguments; tool calls are rate-limited per session.
  </Accordion>
</AccordionGroup>

<Card title="Back to the security overview" icon="shield-halved" href="/security/overview">
  How these controls combine into the default posture.
</Card>