Interstitial risk: when two secure systems make one vulnerable one
15 hours ago
- Interstitial vulnerabilities exist in the spaces between software components, which traditional scanning methods (SAST/DAST) and even LLMs often miss.
- These vulnerabilities arise when assumptions between components become misaligned, such as during rewrites or system splits, without any changes to the API on paper.
- Examples include type mismatches after a language rewrite (e.g., Python to Rust) and auth checks that vanish when a monolith is split, both leading to security gaps.
- Common patterns include timeout/retry drift, serialization mismatches, error-code remapping, and message-ordering assumptions, all locally correct but insecure in combination.
- Root causes include product evolution, lost tribal knowledge, team changes, and polyglot type system mismatches, exacerbated by organizational inertia and past approvals.
- Existing solutions like contract testing, threat modeling, CSPM, and pentests are insufficient as they don't continuously fuzz live contracts at seams.
- Mitigation involves explicit interface specs, adversarial contract testing for rewrites, boundary fuzzing, and clear ownership of contracts via RACI.
- AI-assisted rewrites worsen interstitial risks by increasing the speed and frequency of context-lost changes, making contract vigilance more critical.
- The author is developing a tool to detect these issues, highlighting the need for systematic, continuous monitoring of interstitial spaces.