Guide: Getting accurate results for JavaScript SPAs (React/Vue)

You're giving excellent tactical advice, but I've got to push back on the premise that this is a solved problem with just some config tweaks. The real issue is that Checkmarx, and frankly most SAST tools, are fundamentally architected for a world of server-rendered applications where your source code is what actually executes. With modern SPAs, your "source" is React, but the actual attack surface is the bundled, minified, framework-injected blob that ships to the browser. No amount of ignoring `node_modules` or `dist` folders changes that you're scanning the wrong artifact.

The false positives aren't just a nuisance, they're a symptom of a model mismatch. You can get a "clean" scan of your `src/` directory while a vulnerable version of `webpack-bundle-analyzer` or a misconfigured Content Security Policy in your meta tags slips through because it's not in the scan scope. You're optimizing for a quiet report, not a secure application. We spent six months perfecting our `.cxignore` only to get popped by a client-side dependency in a CDN that the scanner never even saw.

So yeah, do all this to make your reports readable, but don't confuse a tidy scan with a secure SPA. You need to be running dynamic checks on the actual built artifact too, which is a whole other can of worms and probably a different budget line item.

This is really helpful. I'm just starting with SCA tools for our Vue apps, and the false positives are overwhelming. I hadn't considered the Project Type field at all, I think ours is still on the default. Does setting it to "JavaScript/TypeScript" also help with frameworks like Vue, or is it mostly for React/Node?

Yes, and those parser errors aren't just clutter. They can mask actual, legitimate scanning errors and cause the engine to bail early on some files, leading to silent false negatives. We had a case where a mangled cache file error swallowed a real parsing failure on a source component.

Always check the scan logs for `ERROR` not just `WARNING`.

It's not just file extensions, it changes which CxQL queries run. I've seen the exact same code flagged with completely different vulnerabilities depending on that setting.

Splitting the scan is messy but it works. We set up separate projects in Checkmarx for our React frontends and Node.js services in the same monorepo. Used the `--project-name` and `--preset` flags in the CLI to point at the right folders.

You'll definitely see a difference in the results, especially around framework-specific issues.

Absolutely! The separate projects approach is a game-changer once your codebase gets complex. I'd just add that while `--preset` is fantastic for Node services, you sometimes need a lighter touch for the frontend.

For our React SPA, the "Default" preset still ran too many backend-focused queries. We ended up creating a custom query preset that basically just stripped out all the SQLi and server-side template injection checks, focusing purely on client-side JS and framework security. It cut down scan time by 40% and eliminated a whole class of irrelevant findings.

The only caveat is you need to be really confident you're not missing something the framework-specific checks would catch. It's a balancing act between clean results and coverage.

Oh, this is such a good point and exactly the pain we went through last year. Setting the Project Type to "JavaScript/TypeScript" for our frontend projects was like flipping a switch. Suddenly, those weird client-side XSS findings in our React code that were buried as 'Medium' started showing up as 'High' where they belonged.

But I'll add one more layer to your monorepo advice. When you split the scans, you also need to carefully manage the shared library paths. If you have a `packages/shared-utils` folder used by both your React frontend and your Express backend, you might need to scan it twice - once under each project context - or you risk missing issues specific to each runtime. We ended up creating a third "Shared" project with a more generic setting just for those cross-cutting packages, because the findings were so different depending on the consumer.

Great starting point! I'd just add that even with a perfect .cxignore, you need to check your actual scan logs. I've seen cases where the scanner still processes excluded files during its initial indexing phase, causing weird slowdowns before the filters kick in.

Also, that bit about suppressing test files is crucial. Our team wasted days chasing "vulnerabilities" in Jest mocks before we added that pattern.

You're right that ignoring node_modules and build artifacts is step one, but I've found the cost of not doing this step properly is measurable. Those false positives aren't just noise, they're billable engineering hours wasted on triage. Teams chasing vulnerabilities in minified vendor code could have been rightsizing instances instead.

I'd add that after you set up the .cxignore, check the scan logs for the actual file count. If it's still processing tens of thousands of files, your exclude patterns aren't working and you're paying for compute cycles on garbage data. The CLI flag `--file-exclude` is a belt-and-suspenders approach that can force the issue.

One more thing on suppressing test files: make sure your suppression rules are project-specific. A blanket org-level rule to suppress *.test.js might accidentally hide a real issue in a shared utilities library that's used in production.

Spot on about checking the actual file count in the logs. That log line has saved us hours more than once.

I'd add a practical step we take: we run a quick dry-run with the `--verbose` flag first, redirecting the output to grep for "Processing file" counts. It's a fast way to verify the .cxignore is being applied before we kick off a full, long-running scan.

Your point on project-specific suppression rules is critical too. We learned the hard way after a blanket `*.spec.js` rule let a vulnerable test helper slip into a bundled production library. It took a manual audit to catch it. Now our CI pipeline validates that suppression files only reference paths within the current project root.

Good starting point. The framework tuning bit is the real fix most miss. For Vue users, "JavaScript/TypeScript" works, but you also need to explicitly enable the Vue.js scanner engine. It's buried in the advanced configs. Miss that and you're not parsing single-file components right.

Your point on disabling the obfuscation scanner is correct. It's a checkbox in the GUI but also a CLI flag: `--disable-obfuscation`. Makes the scan noticeably faster for clean source.

Watch out for the Project Type setting. It resets if you regenerate your CxGo project from scratch. We burned an hour once because a pipeline rebuild wiped the setting and the results were junk again. Make it part of your IaC for the scanner project.

The engine enablement is indeed a silent killer for accuracy. I'd extend that to the importance of version pinning for those framework-specific engines. We had a case where a Checkmarx platform update silently upgraded the Vue.js engine from v2 to v3, and our scan started throwing parse failures on legacy single-file components that used a certain mixin pattern. The results weren't just junk, they were missing entirely for half the application.

Your IaC point is non-negotiable. We treat scanner config as part of the build pipeline's environment definition, stored alongside the Dockerfile for the scanner runner. If the project can be regenerated from a `.cxx` file or API call, that config must be reapplied programmatically. Relying on the UI's saved state is a recipe for inconsistent results across pipeline stages.

>hardcode it in your CI pipeline

That's exactly where we landed. We keep a `.cxignore` in the repo for developer reference, but the pipeline's `checkmarx-scan` job always explicitly passes `--file-exclude=.cxignore`. It removes any ambiguity about which file is being used.

And on the obfuscation scanner, you're dead on. We saw it completely skip over some arrow functions and template literals, marking chunks of our source as "obfuscated" and giving us a false clean bill of health. Toggling it off was like getting a new pair of glasses for the scan results.

Yep, the indexing phase eating excluded files is real. Seen it chew through 20k minified vendor files before the filter activated, blowing up the scan time.

Your point on test files is why we never suppress at the pattern level like `*.spec.js`. We only suppress by the exact, full file path after a finding is confirmed false. Keeps the audit trail clean.

The logs are the only source of truth. If the file count in the logs doesn't drop, your filters are broken.

Right, "the logs are the only source of truth" is the line everyone should remember. We made that a mantra for our team. But I'd add a caveat to the full file path suppression approach - it can become a maintenance burden in a large, active codebase. We've had cases where refactoring moved a suppressed file and the vulnerability quietly re-entered the results because the suppression path was now invalid.

A dry-run script that compares the suppression file entries against the current repo structure is now part of our pre-scan check.

Oof, that's a great point about refactoring breaking suppressions. We just started with the tool, and that's exactly the kind of long-term headache I wouldn't have thought about.

Our team moves stuff around constantly. So you're saying the dry-run script checks if all the paths in the suppression file still exist before scanning? That sounds super smart.

What would you recommend for setting that up? Is it a simple script you run in CI, or something built into the scanner?