Understanding what static analysis can and cannot detect, and how to build robust security with these limitations in mind

Understanding Static Analysis Limitations

The Gist: Static analysis is like a security guard who checks IDs at the door—great at catching known fakes, but can't follow people around once they're inside.

Quick Summary
Catches	Known patterns (eval, innerHTML, SQL concat), API misuse
Misses	Runtime values, dynamic code, business logic, dependencies
Coverage	~80% of common vulnerabilities (OWASP Top 10)
Combine With	DAST, dependency scanning, penetration testing

Why this matters: Knowing what static analysis can and cannot do helps you build a more robust security strategy that combines automated tools with proper security practices.

What is Static Analysis?

Static analysis examines your code without executing it. ESLint reads your source files, parses them into an Abstract Syntax Tree (AST), and applies rules to detect potential issues.

Where Static Analysis Excels

✅ Pattern Detection

Identifying known vulnerable patterns like eval(), innerHTML, and SQL string concatenation.

✅ API Misuse

Detecting incorrect usage of security-sensitive APIs like JWT verification or crypto functions.

✅ Configuration Issues

Finding hardcoded secrets, weak crypto algorithms, and insecure configurations.

✅ Consistent Enforcement

Applying the same security standards across your entire codebase automatically.

Where Static Analysis Cannot Help

Static analysis has fundamental limitations due to the halting problem - it's mathematically impossible to determine all behaviors of a program without running it.

❌ Runtime Values

Cannot determine what values variables will hold at runtime, especially from external sources.

❌ Dynamic Code

Code generated at runtime, eval'd strings, and dynamic imports are invisible to static analysis.

❌ Business Logic

Authorization flaws, race conditions, and business logic vulnerabilities require runtime context.

❌ External Dependencies

Vulnerabilities in third-party libraries require dependency scanning tools (npm audit, Snyk).

The Data Flow Challenge

One of the biggest limitations is tracing data flow through complex applications.

What We Can Detect

// ✅ Direct pattern - DETECTED
const query = `SELECT * FROM users WHERE id = ${req.params.id}`;

// ✅ Simple variable tracking - DETECTED
const userId = req.params.id;
const query = `SELECT * FROM users WHERE id = ${userId}`;

What We Cannot Reliably Detect

// ❌ Sanitized input - FALSE POSITIVE possible
const userId = sanitize(req.params.id);
const query = `SELECT * FROM users WHERE id = ${userId}`;

// ❌ Complex data flow - MISSED
function getQuery(options) {
  return buildDynamicQuery(options);
}
const query = getQuery({ filter: req.body.filter });

// ❌ Async data - MISSED
const data = await fetchFromDatabase(req.params.id);
processUnsafely(data);

Known False Negatives: Every Interlace rule documents its limitations in a "Known False Negatives" section. We believe in transparency about what we can and cannot detect.

What To Do	Why
Enable Interlace in CI	Catch ~80% of common vulns automatically
Add dependency scanning	npm audit/Snyk catches supply chain attacks
Read "Known False Negatives"	Know exactly what each rule misses
Layer with DAST	Runtime testing finds business logic flaws

🔗 Next Steps

⚡ Fixable Rules→

Why some issues need human or AI judgment

📊 Benchmarks→

Performance comparison with alternatives

🚀 Getting Started→

Set up Interlace in 2 minutes

📚 Further Reading

OWASP Testing Guide - Comprehensive security testing methodology
ESLint Architecture - How ESLint rule traversal works
SAST vs DAST - When to use which approach

Static Analysis Limitations