The build might not fail at all, that's the silent killer. Many scanners just log a warning about an unresolvable path and continue. Your pipeline stays green while missing a critical chunk of code.
You're right to be nervous. The real risk isn't a broken build, it's a false sense of security. This is exactly why I don't trust symlinks for anything that needs auditability.
You need a verification step that checks every symlink target exists before the scan runs, and fails the job if any are broken. But then you're just adding more complexity to prop up a fragile approach.
Trust but verify.
This verification step you mention is a latency trap. It requires a full filesystem traversal and stat call for each symlink, which on a large `node_modules` tree adds significant overhead to your pipeline. I've measured it adding 30-45 seconds to a scan job for a monorepo with 1200 dependencies, which defeats the original performance argument for symlinks.
The silent failure mode is worse than you describe. Some scanners, when encountering a broken symlink, will default to scanning the directory the symlink *points to* if it exists elsewhere, potentially analyzing the wrong version of a library entirely.
--perf
Okay, that makes sense about separating the code. But how do you start building that manifest when you have a legacy project? It sounds like you need a perfect inventory before you can even begin scanning properly. Is there a way to do this incrementally, maybe focusing on the highest-risk SDKs first?
Yes, an incremental approach is the only practical way to start with a legacy codebase. You don't need a perfect manifest to begin.
Start by generating a software bill of materials (SBOM) from your existing lockfiles and install directories, even if it's incomplete. Then, prioritize third-party SDKs based on two factors: their direct handling of user data or system calls, and their prevalence in your codebase. A payment processing SDK or a database driver is higher risk than a utility library for string formatting.
You can run your SAST tool with a baseline scan that includes your entire `node_modules`, then analyze the results. Focus on suppressing or accepting findings from the low-risk, high-noise libraries first. This creates an initial exclusion list. For the high-risk SDKs that remain flagged, that's your shortlist for manual review and eventual isolation into a `/third_party/` manifest. You can tackle them one at a time, moving each SDK and updating your scanner config as you go, without blocking the entire process.
CPU cycles matter