The current threat model covers code-level sinks (injection, XSS, deserialization, SSRF, etc) which is the most actionable surface for a code scanner. Three categories came up in the audit that would expand it into adjacent territory.
Supply chain — build tools (webpack, vite, esbuild), package managers (npm, pip, cargo), CI (GitHub Actions, CircleCI) all have attack surface but it's fundamentally different: malicious dependencies running code at install time, typosquatting, compromised build plugins, CI secret exfiltration. The threat isn't "what dangerous function can user input reach" but "can untrusted code execute during build/install". Could be a separate set of threat IDs (supply_chain_install_scripts, supply_chain_build_plugins, supply_chain_ci_secrets) with mappings from role:build-tool, role:package-manager, function:ci-cd. The sinks would be different too — postinstall scripts in package.json, Webpack loader/plugin config, GitHub Actions with pull_request_target.
Infrastructure misconfig — Docker (privileged containers, exposed ports, secrets in ENV), Kubernetes (RBAC too broad, hostPath mounts, default service accounts), Terraform (hardcoded credentials, public S3 buckets, security groups). These exist as config-file problems not code-level sinks. Could work as a parallel to sinks: "known dangerous configuration patterns" per tool, like Docker's --privileged or K8s hostPath. Hadolint and kube-score already check these; brief could list what to check rather than checking it.
Log injection (CWE-117) — forged log entries that break SIEM parsing, trigger alert fatigue, or inject ANSI escape sequences into terminals. The threat registry doesn't have this ID. Most logging frameworks have it (log4j was the extreme case but even basic string logging is vulnerable). Lower severity than the injection/deser surface but real, especially when logs feed automated systems. Would need a new threat ID and sinks on logging libraries/stdlib logging functions.
These are fundamentally different shapes of work from the current sink model and each could be its own design conversation. Filing to capture the thinking, not proposing immediate implementation.
The current threat model covers code-level sinks (injection, XSS, deserialization, SSRF, etc) which is the most actionable surface for a code scanner. Three categories came up in the audit that would expand it into adjacent territory.
Supply chain — build tools (webpack, vite, esbuild), package managers (npm, pip, cargo), CI (GitHub Actions, CircleCI) all have attack surface but it's fundamentally different: malicious dependencies running code at install time, typosquatting, compromised build plugins, CI secret exfiltration. The threat isn't "what dangerous function can user input reach" but "can untrusted code execute during build/install". Could be a separate set of threat IDs (supply_chain_install_scripts, supply_chain_build_plugins, supply_chain_ci_secrets) with mappings from role:build-tool, role:package-manager, function:ci-cd. The sinks would be different too — postinstall scripts in package.json, Webpack loader/plugin config, GitHub Actions with pull_request_target.
Infrastructure misconfig — Docker (privileged containers, exposed ports, secrets in ENV), Kubernetes (RBAC too broad, hostPath mounts, default service accounts), Terraform (hardcoded credentials, public S3 buckets, security groups). These exist as config-file problems not code-level sinks. Could work as a parallel to sinks: "known dangerous configuration patterns" per tool, like Docker's --privileged or K8s hostPath. Hadolint and kube-score already check these; brief could list what to check rather than checking it.
Log injection (CWE-117) — forged log entries that break SIEM parsing, trigger alert fatigue, or inject ANSI escape sequences into terminals. The threat registry doesn't have this ID. Most logging frameworks have it (log4j was the extreme case but even basic string logging is vulnerable). Lower severity than the injection/deser surface but real, especially when logs feed automated systems. Would need a new threat ID and sinks on logging libraries/stdlib logging functions.
These are fundamentally different shapes of work from the current sink model and each could be its own design conversation. Filing to capture the thinking, not proposing immediate implementation.