Hi everyone! 👋 New to the forum and to Checkmarx, coming from a project management background.
We've just started running scans and are getting overwhelmed with findings from third-party libraries (like npm packages). It's really skewing our vulnerability metrics and making it hard to focus on our own code.
I've heard you can filter these out, but I want to do it properly—once and for all, not a manual process each time. What's the best practice here? Is it about setting up the right CxQL queries, or is there a project-level configuration we should use?
Would love to hear how your teams handle this. Thanks in advance!
Filtering out third-party libs is a config step, not a CxQL band-aid. You need to set up the CxSAST project properly.
Use the "Exclude Folders" scan setting to skip paths like `node_modules/`, `packages/`, or `vendor/`. Do this once at the project level. Then every scan ignores that code.
Your vulnerability metrics are useless if they include libraries you can't fix. This is basic hygiene.
You're on the right track with the project-level configuration idea. While CxQL exclusions are possible, they become a maintenance headache for libraries that update frequently.
The "Exclude Folders" setting user485 mentioned is correct, but I'd add that you should define this in your automated scan configuration, not just the GUI. For a Node.js project, your config would permanently skip `node_modules/` and maybe `bower_components/`. That way it's baked into your CI/CD pipeline and you never think about it again.
This approach assumes you have a separate Software Composition Analysis (SCA) tool for those third-party dependencies, which is the proper way to manage library vulnerabilities.
sub-100ms or bust
Exactly, the project-level config is the only way to make it stick. The key is getting that setting baked into your automation script or pipeline config file - not just clicking it in the web UI once. That way it survives team handoffs and new project clones.
One caveat from hard experience: you need to coordinate with your SCA tool's scope. If Checkmarx is ignoring `node_modules` but your SCA tool only scans the manifest files, you might have a coverage gap for actual library code in use. Make sure your exclusions align with your overall toolchain responsibility.
Welcome! Everyone's giving you the right main answer, but let me add the dad joke version: scanning third-party libs is like getting a home inspection that criticizes your neighbor's ugly shed. You can't fix it, and it's not your property.
The project config is the way to go, but I'll add a tiny warning. When you set `node_modules` as excluded, double-check that none of your own team's code has somehow ended up in there by a misconfigured build or a wonky symlink. I've seen it happen, and then you miss real issues.
Once that's set in your pipeline config, you're golden. Then the findings you see are actually yours to fix.
That's a great analogy, and the warning about misconfigured builds is spot on. It's an easy oversight that can create a blind spot.
A good practice to complement the path exclusion is adding a pre-scan step in your pipeline. Something simple like a script that checks for any `.js` or `.ts` files not in a `src/` directory but located within `node_modules/`. It can flag those for review before the scan even runs.
That way you maintain the exclusion's efficiency but add a safety net for the exact scenario you mentioned.
—Anita