Shadow engineering is the use of technologies — AI tools, frameworks, libraries, infrastructure components — that haven't been evaluated, approved, or documented by security and platform teams. It's the engineering-specific variant of shadow IT.
Why Shadow Engineering Is Different
Traditional shadow IT involves business users adopting SaaS tools without IT approval. Shadow engineering is fundamentally different:
- It ships to production. A marketing team using an unapproved design tool doesn't change your attack surface. A developer using an unapproved npm package does — it executes inside your build and runtime.
- It's invisible at the procurement layer. Developers install open-source packages with
npm install, not purchase orders, so the usual procurement and vendor-review controls never see them. - It compounds. Every unsanctioned dependency brings its own transitive dependencies. A single direct package can pull in a long tail of transitive packages you never chose directly — you can see this for any Node project with
npm ls --all, which prints the full resolved dependency tree. - AI accelerates it. AI coding assistants suggest libraries and patterns that developers adopt without explicit evaluation, often without the developer recognising that a new dependency was introduced at all.
The Scale of the Problem
In most engineering organisations, the set of technologies a security or platform team has formally reviewed and documented is far smaller than the set actually present across all repositories. Direct dependencies are the visible tip; the transitive graph beneath them — plus runtimes, frameworks, vendored code, and container base layers — is where the bulk of unreviewed surface lives. AI coding assistants widen the gap further, because they introduce libraries and patterns outside the normal "I deliberately chose this dependency" decision point.
The gap between what's documented and what's actually in use is your ungoverned attack surface. The goal of detection is to measure that gap concretely for your own estate rather than assume it's small.
Detection Methods
Build Artifact Inspection
The most reliable detection method. Inspect every build artifact to identify all technologies compiled, bundled, or packaged into the output:
- Direct and transitive dependency enumeration
- Framework and runtime detection
- Vendored code identification
- Infrastructure component discovery from container layers
Build inspection catches everything that makes it into the artifact, regardless of how it got there. A practical starting point is generating a Software Bill of Materials (SBOM) from each build artifact or container image with a tool such as Syft, then scanning that SBOM for known vulnerabilities with Grype — both are open-source and run in CI without source access.
Desktop Monitoring
For AI coding tools that don't leave traces in build artifacts:
- Detect AI coding assistant activity (Copilot, Cursor, Claude Code, etc.)
- Identify which models and providers are in use
- Track adoption patterns across the organisation
- Distinguish sanctioned from unsanctioned tool usage
Desktop monitoring observes coding tool activity at the OS level — no IDE plugins required. Note that this is endpoint telemetry on developer machines and should be scoped and disclosed accordingly under your acceptable-use and privacy policies.
Repository Analysis
Complement build inspection with source-level analysis:
- Package manifest scanning (
package.json,requirements.txt,go.mod) - Import statement analysis
- Configuration file detection
- CI/CD pipeline inspection
From Detection to Governance
Detection alone is insufficient. The workflow:
- Discover — Identify all technologies in use through build inspection
- Classify — Auto-categorise by type, risk level, and licence
- Assess — Route high-risk technologies to security review
- Decide — Approve, block, or mark as pending review
- Enforce — Block builds that use blocked technologies; alert on pending
- Track — Monitor adoption trends and migration progress over time
Policy Examples
- AI tools: Only approved AI coding assistants may be used. Unapproved tools detected by desktop monitoring trigger a review workflow.
- Data residency: Block packages and tools with data processing in specific jurisdictions.
- Licence compliance: Prevent copyleft-licensed packages in proprietary builds.
- End-of-life: Alert when technologies reach end-of-life status.
Balancing Governance and Velocity
The goal is not to prevent all unapproved technology adoption. That creates friction that drives developers to work around governance entirely. Instead:
- Make approval lightweight — Hours, not weeks. Security review should be proportional to risk.
- Auto-approve low-risk changes — New patch versions of approved packages don't need human review.
- Block only clear violations — Reserve hard blocks for known-malicious packages and policy violations.
- Provide visibility, not just enforcement — Teams should see their own technology footprint and make informed decisions.
The most effective governance systems are the ones developers barely notice for routine changes but catch the important exceptions.
Connecting to Code Ownership
Shadow engineering detection is most effective when combined with code ownership data:
- Who introduced this technology? — Git history identifies the developer and team
- Which team should evaluate it? — Route to the team with the most context
- Is there an existing standard? — Check if an approved alternative exists
- What's the migration path? — If blocked, ownership data identifies who needs to migrate
This combination of visibility (what's in use) and accountability (who's responsible) is the foundation of effective engineering governance.