Hi everyone, I'm new here and also pretty new to using Checkmarx CxSAST at my company.
We're running a trial and I'm reviewing the first scan results. It's flagging a bunch of issues in our .NET code as "Path Traversal" vulnerabilities. The thing is, I'm pretty sure this code is safe—it's just building a file path using a hardcoded template string and a known-safe integer ID from our database. No user input is involved at all.
I don't want to ignore a real problem, but I also don't want a bunch of false positives cluttering our reports. Is the best practice here to suppress that specific rule for these findings? Or is there a better way to tell CxSAST that this data source is trusted? I'm nervous about configuring this wrong. Any advice would be really appreciated.
Welcome to the fun world of SAST tuning. It's common for these tools to flag safe code, especially early on.
Since you're sure the integer ID is truly safe - not just from user input but also from other untrusted layers - suppression is a valid path. I'd recommend using Checkmarx's query suppression via a comment in the code itself. That way, the suppression is visible right where the logic lives. Something like `// Checkmarx Suppress: CxId_12345` above the method.
Before you do, double-check the data flow: is that ID *ever* populated from, or influenced by, an external API, message queue, or log file? If there's any remote chance, the finding might be worth keeping as a reminder to validate.
You've got the right instinct to be nervous about suppressing things. Even with a trusted database ID, you should trace it back to its origin. Was that ID ever, even indirectly, from an API call or a user upload batch job? If there's any lineage to an external source, the flag might be telling you to add a validation layer there.
Using comment suppression is solid advice, but for a bunch of similar findings, you could also look into creating a custom Cx query that excludes your specific, safe pattern. It's a bit more upfront work but keeps your baseline cleaner long-term.