I recently ran a pre-deployment security scan on our Next.js application and got flagged for a critical vulnerability in lodash. The vulnerability has a high severity score, and my leadership immediately wanted to know when it would be patched. After digging deeper, I found out that we use lodash only in a build script that runs during compilation, meaning this vulnerable code never makes it to our production bundle. Next.js completely tree-shakes it out, so the code won't even exist in our deployed application.
I tried explaining this to our security team, but they insisted that 'the scanner detected it in the repository, so it needs to be fixed for compliance.' I spent three days updating lodash across our entire monorepo just to appease a scanner that doesn't recognize what actually ships to production. Meanwhile, we have real security issues with an exposed API endpoint that has weak authentication that no one is addressing because it isn't picked up by the scanner.
This whole situation feels backward. We're prioritizing theoretical vulnerabilities in build tooling over tangible security risks in our running code. I'm starting to think that static scanners aren't suited for modern JavaScript applications where many dependencies get compiled away. Has anyone else faced this issue or found tools that actually understand what's running versus what's just in node_modules?
3 Answers
As a security team member, I see both sides. While the code might be tree-shaken from your production bundle, it doesn’t mean risks vanish entirely. You still want to address any potential vulnerabilities, but I agree that prioritization should lean towards actual risks over theoretical ones. I recommend discussing better tools with your security team that can help with identifying what’s really running in production. There are newer tools around that provide reachability analyses, which could directly address the issue you're facing.
I've not worked directly with JavaScript, but in my experience with Go, we generate Software Bill of Materials (SBOMs) from production container images. By keeping the final container minimal, it results in an SBOM with less noise, which can help in identifying and focusing on the actual threats. It might be worth looking into similar practices for your JS ecosystem.
I get where you’re coming from, but I think the scanner is doing its job by flagging vulnerabilities, even if they’re in code that won’t run. It sounds annoying, but it’s better to address these issues proactively rather than risking them lingering around unaddressed. What if the code somehow gets triggered later on? It’s about managing risks, and while it might seem tedious, it's better to be cautious. Plus, your security team's perspective on compliance is completely valid.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically