HookAudit: Building a Supply-Chain Security Scanner Without a Supply Chain What happens when you force a security tool to inspect untrusted code using only standard-library primitives? An engineering
By Coderz Club · 2026-09-05 · Tags: ai, developer, node, git, rust
HookAudit: Building a Supply-Chain Security Scanner Without a Supply Chain
What happens when you force a security tool to inspect untrusted code using only standard-library primitives? An engineering postmortem on systems complexity and zero dependencies. Opening Hook We were building a security scanner designed to inspect untrusted repositories before developers open them in their editors. Our first instinct was standard Node.js muscle memory: npm install commander chalk fast-glob simple-git js-yaml cytoscape Then we stopped. We were building a tool whose express purpose was to audit project configuration files for supply-chain compromises. And our very first architectural gesture was to pull in a tree of third-party packages-the same class of supply-chain risk we intended to audit. A compromised dependency could become part of the scanner's own attack surface. More critically, an unsafe inspection workflow that installs or executes the target project's dependency tree could trigger lifecycle behavior before analysis begins. HookAudit deliberately avoids that workflow. So we banned third-party dependencies entirely. No npm install. No runtime libraries. No devDependencies in production. Just the Node.js standard library and native browser primitives. What followed was not a triumphant victory lap about how easy the standard library makes everything. It was a descent into the raw systems complexity that libraries normally hide: operating system path boundary traps across drive letters, binary Git object serialization on disk, subtle false-negative bugs in directed graph traversals, and the unforgiving mechanics of hand-written configuration parsers. This is the technical postmortem of what we built, what broke, what the standard library gave us, and what we learned when we removed the packages that normally protect us from the underlying machine. 1. We Were Building a Security Scanner HookAudit is a repository execution-topology security auditor. Its core question is straightforward: "What can this repository cause to execute, through which trigger, with which reachable capabilities, and what changed since I trusted it?" A modern code repository is no longer just source code and a dependency manifest. It contains configuration files that govern automatic execution across editors, AI coding agents, package managers, and CI pipelines: AI Agent Lifecycle Hooks: .claude/settings.json configuring commands on SessionStart or PreToolUse. IDE Task Definitions: .vscode/tasks.json configured with "runOn": "folderOpen". Package Lifecycle Scripts: package.json scripts like preinstall, install, or prepare. Git Hooks: .husky/* or .git/hooks/* firing on commit, checkout, or push. Workflow Automations: .github/workflows/*.yml executing actions on repository events. Dependency and SBOM-focused workflows primarily reason about package inventories, versions, and known vulnerabilities; they are not intended to reconstruct repository-local execution paths configured in editor and agent settings files. From a user's perspective, HookAudit provides a five-stage workflow: 01 DISCOVER: Identify all configured execution surfaces in the workspace. 02 DETECT: Extract commands, flags, and direct execution parameters. 03 TRACE: Traverse multi-hop references from configuration files to secondary scripts. 04 ANALYZE: Infer reachable capabilities (network access, process execution, credential signals) along the full execution path. 05 WATCH: Establish an integrity baseline and detect semantic drift across subsequent pulls. Behind that user experience lies our internal technical pipeline: DISCOVER → NORMALIZE → RESOLVE → GRAPH → INFER → EXPLAIN → BASELINE → DIFF flowchart LR D[DISCOVER - 12 surfaces] --> N[NORMALIZE] N --> R[RESOLVE - depth 32] R --> G[GRAPH] G --> I[INFER - 11 rules] I --> E[EXPLAIN - risk + evidence] E --> B[BASELINE - SHA-256] B --> F[DIFF - semantic drift] The execution graph is the central artifact of the system. We do not evaluate files in isolation; we evaluate paths. Figure 1: Terminal output of HookAudit CLI executing against demo/sample-repository. Highlights an automatic SessionStart trigger traversing two script hops and escalating to a CRITICAL verdict due to reachable remote download capabilities. 2. Then We Removed the Dependency Tree Choosing zero third-party dependencies immediately introduced what we came to call the Security Tool Dependency Paradox. In general software development, adding libraries is standard practice. But for a security auditor inspecting untrusted software, each third-party package introduces three distinct structural risks: The Scanner Inherits the Attack Surface: A security scanner must operate on hostile input. If the scanner incorporates a deep dependency tree, any vulnerability or compromised package inside that tree allows an attacker to target the auditor itself. Nondeterministic Evaluation: Dependency trees with floating semver ranges (^, ~) resolve dynamically over time. Two
What happens when you force a security tool to inspect untrusted code using only standard-library primitives? An engineering postmortem on systems complexity and zero dependencies. Opening Hook We were building a security scanner designed to inspect untrusted repositories before developers open them in their editors. Our first instinct was standard Node.js muscle memory: npm install commander chalk fast-glob simple-git js-yaml cytoscape Then we stopped. We were building a tool whose express purpose was to audit project configuration files for supply-chain compromises. And our very first architectural gesture was to pull in a tree of third-party packages-the same class of supply-chain risk we intended to audit. A compromised dependency could become part of the scanner's own attack surface. More critically, an unsafe inspection workflow that installs or executes the target project's dependency tree could trigger lifecycle behavior before analysis begins. HookAudit deliberately avoids that workflow. So we banned third-party dependencies entirely. No npm install. No runtime libraries. No devDependencies in production. Just the Node.js standard library and native browser primitives. What followed was not a triumphant victory lap about how easy the standard library makes everything. It was a descent into the raw systems complexity that libraries normally hide: operating system path boundary traps across drive letters, binary Git object serialization on disk, subtle false-negative bugs in directed graph traversals, and the unforgiving mechanics of hand-written configuration parsers. This is the technical postmortem of what we built, what broke, what the standard library gave us, and what we learned when we removed the packages that normally protect us from the underlying machine. 1. We Were Building a Security Scanner HookAudit is a repository execution-topology security auditor. Its core question is straightforward: "What can this repository cause to execute, through which trigger, with which reachable capabilities, and what changed since I trusted it?" A modern code repository is no longer just source code and a dependency manifest. It contains configuration files that govern automatic execution across editors, AI coding agents, package managers, and CI pipelines: AI Agent Lifecycle Hooks: .claude/settings.json configuring commands on SessionStart or PreToolUse. IDE Task Definitions: .vscode/tasks.json configured with "runOn": "folderOpen". Package Lifecycle Scripts: package.json scripts like preinstall, install, or prepare. Git Hooks: .husky/* or .git/hooks/* firing on commit, checkout, or push. Workflow Automations: .github/workflows/*.yml executing actions on repository events. Dependency and SBOM-focused workflows primarily reason about package inventories, versions, and known vulnerabilities; they are not intended to reconstruct repository-local execution paths configured in editor and agent settings files. From a user's perspective, HookAudit provides a five-stage workflow: 01 DISCOVER: Identify all configured execution surfaces in the workspace. 02 DETECT: Extract commands, flags, and direct execution parameters. 03 TRACE: Traverse multi-hop references from configuration files to secondary scripts. 04 ANALYZE: Infer reachable capabilities (network access, process execution, credential signals) along the full execution path. 05 WATCH: Establish an integrity baseline and detect semantic drift across subsequent pulls. Behind that user experience lies our internal technical pipeline: DISCOVER → NORMALIZE → RESOLVE → GRAPH → INFER → EXPLAIN → BASELINE → DIFF flowchart LR D[DISCOVER - 12 surfaces] --> N[NORMALIZE] N --> R[RESOLVE - depth 32] R --> G[GRAPH] G --> I[INFER - 11 rules] I --> E[EXPLAIN - risk + evidence] E --> B[BASELINE - SHA-256] B --> F[DIFF - semantic drift] The execution graph is the central artifact of the system. We do not evaluate files in isolation; we evaluate paths. Figure 1: Terminal output of HookAudit CLI executing against demo/sample-repository. Highlights an automatic SessionStart trigger traversing two script hops and escalating to a CRITICAL verdict due to reachable remote download capabilities. 2. Then We Removed the Dependency Tree Choosing zero third-party dependencies immediately introduced what we came to call the Security Tool Dependency Paradox. In general software development, adding libraries is standard practice. But for a security auditor inspecting untrusted software, each third-party package introduces three distinct structural risks: The Scanner Inherits the Attack Surface: A security scanner must operate on hostile input. If the scanner incorporates a deep dependency tree, any vulnerability or compromised package inside that tree allows an attacker to target the auditor itself. Nondeterministic Evaluation: Dependency trees with floating semver ranges (^, ~) resolve dynamically over time. Two