Security Defense-in-Depth / Layered Security See in Code Tour

Security Defense-in-Depth

Multiple independent security layers — AST analysis, SSRF guard, secret scanning, permissions, and sandboxing.

Security Defense-in-Depth — Architecture Diagram

flowchart TD
    A[Bash Command] --> B[AST Parser]
    B --> C{Dangerous pattern?}
    C -->|Yes| D[Block + Warn]
    C -->|No| E[ML Classifier]
    E --> F[Permission Check]
    F --> G{Allowed?}
    G -->|No| H[Deny]
    G -->|Yes| I[Sandbox Execution]
    I --> J[Result]
    K[Memory Upload] --> L[Secret Scanner]
    L --> M{Credentials found?}
    M -->|Yes| N[Block Upload]
    M -->|No| O[Allow Upload]

Mermaid diagram definition

Deep Dive

No single security check is trusted to catch everything. The bashSecurity.ts AST parser is powerful but can't catch every dangerous pattern. The ML classifier is accurate but not perfect. The sandbox isolates but can be escaped. Each layer compensates for the others.

🔑Key Insight

The key property of defense-in-depth: independent layers. If the AST parser has a bug, the classifier still runs. If the classifier miscategorizes, the permission system still prompts. Each layer is a separate team's responsibility.

⚠️Warning

`secretScanner.ts` runs on memory file content before it's sent to any server. AWS access keys, GitHub PATs, JWT tokens — if any match gitleaks patterns, the upload is blocked entirely with a user-visible error.

KEY TAKEAWAYS

→No single layer is trusted — layers compensate for each other's gaps
→AST analysis catches structural patterns; ML catches semantic ones
→Secret scanning protects data at rest before it leaves the machine
→Sandbox isolation limits blast radius even if all other layers fail

Source Code

SSRF guard — one layer of the security stack, blocking metadata endpoint access from hook URLs.

import type { AddressFamily, LookupAddress as AxiosLookupAddress } from 'axios'
import { lookup as dnsLookup } from 'dns'
import { isIP } from 'net'

/**
 * SSRF guard for HTTP hooks.
 *
 * Blocks private, link-local, and other non-routable address ranges to prevent
 * project-configured HTTP hooks from reaching cloud metadata endpoints
 * (169.254.169.254) or internal infrastructure.
 *
 * Loopback (127.0.0.0/8, ::1) is intentionally ALLOWED — local dev policy
 * servers are a primary HTTP hook use case.
 *
 * When a global proxy or the sandbox network proxy is in use, the guard is
 * effectively bypassed for the target host because the proxy performs DNS
 * resolution. The sandbox proxy enforces its own domain allowlist.
 */

/**
 * Returns true if the address is in a range that HTTP hooks should not reach.
 *
 * Blocked IPv4:
 *   0.0.0.0/8        "this" network
 *   10.0.0.0/8       private
 *   100.64.0.0/10    shared address space / CGNAT (some cloud metadata, e.g. Alibaba 100.100.100.200)
 *   169.254.0.0/16   link-local (cloud metadata)
 *   172.16.0.0/12    private
 *   192.168.0.0/16   private
 *
 * Blocked IPv6:
 *   ::               unspecified
 *   fc00::/7         unique local
 *   fe80::/10        link-local
 *   ::ffff:<v4>      mapped IPv4 in a blocked range
 *
 * Allowed (returns false):
 *   127.0.0.0/8      loopback (local dev hooks)
 *   ::1              loopback
 *   everything else
 */
export function isBlockedAddress(address: string): boolean {
  const v = isIP(address)
  if (v === 4) {
    return isBlockedV4(address)
  }
  if (v === 6) {
    return isBlockedV6(address)
  }
  // Not a valid IP literal — let the real DNS path handle it (this function

AI Assistant

Ask anything about Security Defense-in-Depth