Your static analysis tools scanned clean. Your code review passed. Your deployment went live. And somewhere in a shopper's browser, a payment skimmer just activated from metadata hidden inside a favicon file.
This isn't a hypothetical gap. A Magecart skimmer used a three-stage loader chain to hide its payload inside a favicon's EXIF metadata, executing in the shopper's browser. Your repository-based security tools never saw it coming because the threat never touched your codebase.
The Shift in Attack Surfaces
The web supply chain attack surface has moved beyond the code you control. Modern skimmers exploit third-party resources, content delivery networks, and browser execution contexts that exist entirely outside your repository. Tools like Claude Code Security analyze what's in the repo or explicitly fed to them, creating a fundamental blind spot for threats that assemble and execute at runtime.
This isn't a tool limitation you can patch. It's a threat model mismatch. Your static analysis operates in one domain (your codebase), while the attack operates in another (the browser runtime environment). No amount of repository scanning will detect a payload that arrives through legitimate third-party resources and executes client-side.
Key Findings
Repository-scoped tools can't see runtime assembly. When an attacker chains together legitimate-looking requests to external resources that assemble into malicious code in the browser, your static analysis has no visibility. The individual pieces look benign. The assembly happens after deployment, in an environment your repository tools don't monitor.
Third-party resources bypass your security perimeter. Your application loads scripts, fonts, analytics trackers, and payment widgets from domains you don't control. Each one is a potential injection point. Static analysis can flag the inclusion of third-party resources, but it can't inspect what those resources serve at runtime or detect when they've been compromised.
Compliance frameworks require runtime protection. PCI DSS v4.0.1 Requirement 6.4.3 mandates maintaining an inventory of bespoke and custom software and third-party software components, and Requirement 11.6.1 requires detecting changes to HTTP headers and script contents. You can't satisfy these requirements with repository scanning alone. You need runtime verification that what's executing in the browser matches what you authorized.
Browser-based attacks leave no repository trace. The favicon EXIF metadata attack demonstrates the problem. The image file itself might be legitimate. The metadata might be valid EXIF data. The malicious payload only materializes when specific JavaScript interprets that metadata in a specific way. Your static analysis sees a favicon. Your customers see a payment skimmer.
Defense-in-depth isn't optional anymore. Relying on a single security control creates a single point of failure. When your static analysis can't detect runtime threats, you need runtime monitoring to close the gap. When your runtime monitoring can't predict future vulnerabilities, you need static analysis to catch them early. Neither tool is sufficient alone.
Implications for Your Team
If you're relying solely on static analysis for web application security, you're meeting compliance checkboxes without actually protecting customer data. Your SOC 2 Type II auditor will ask how you detect unauthorized changes to scripts loaded in production. "We scan our repository" isn't an adequate answer when the threat never enters your repository.
Your compliance posture has a runtime gap. PCI DSS v4.0.1 requires you to detect and prevent unauthorized changes to payment pages. ISO 27001 requires you to manage third-party service delivery. NIST CSF v2.0 requires continuous monitoring of your attack surface. Repository scanning addresses none of these for browser-based threats.
Your incident response plan probably assumes you'll detect intrusions through log analysis or endpoint detection. But browser-based skimmers don't trigger traditional alerts. They execute in your customers' browsers, not your infrastructure. By the time you detect fraudulent transactions, the skimmer has been running for weeks.
Action Items by Priority
Implement client-side monitoring for production environments. Deploy Content Security Policy (CSP) with reporting enabled and monitor for violations. Use Subresource Integrity (SRI) hashes for third-party resources so browsers reject modified files. These controls provide runtime verification that what's executing matches what you authorized. Start with your payment pages and authentication flows.
Inventory every third-party resource your application loads. Document which scripts, fonts, styles, and images come from external domains. For each one, identify who owns it, what it does, and what data it accesses. This inventory satisfies PCI DSS v4.0.1 Requirement 6.4.3 and gives you the foundation for runtime monitoring. If you can't explain why a resource is there, remove it.
Establish baseline behavior for legitimate third-party resources. Your runtime monitoring needs to distinguish between authorized changes (vendor updates) and unauthorized changes (compromised CDN). Document expected file hashes, expected domains, expected behavior. When something deviates, you need to know whether it's a routine update or an active compromise.
Create detection rules for common skimmer patterns. Monitor for scripts that access form fields containing payment data, scripts that exfiltrate data to unexpected domains, and scripts that execute from unusual sources. These behavioral signatures catch skimmers even when the specific payload is novel.
Test your detection capabilities with realistic scenarios. Don't assume your monitoring works until you've verified it catches actual attack patterns. Consider a team that loads a legitimate analytics script that later gets compromised. Does your monitoring detect the change? Does it alert before customer data is exfiltrated? If not, your controls aren't working.
Integrate runtime findings into your security review process. When runtime monitoring flags a suspicious script, your security team needs a workflow to investigate, contain, and remediate. This workflow should be as mature as your process for handling static analysis findings. Runtime threats require runtime response capabilities.
