| I've gone down this road years ago. While there's no install and initial results are quick to appear, the false positives that grep or any string search tool generates will make the cynics shoot down this simple attempt to find problems in the source code. Problems that arose: - what about use of those questionable APIs/constants in strings (perhaps for logging) or in comments? - some of the APIs listed in the article were only questionable when certain values were used - sometimes you can get grep/search tool of choice to play along, but if the API call spans multiple lines or the constant has been assigned to a variable that is used instead, then a plain string search won't help. - it's hard to ignore previously flagged but accepted uses of the API/constants. - so there's a possible bug reported, but devs usually want to see the context of the problem (the code that contains the problem) quickly/easily. Some text editors can grok the grep output and place the cursor at the particular line/character with the problem, some can't. If you go down that road to try and reduce false positives, you'll end up with a parser for your development language of choice. |
My SAST generates tons of false positives and is unforgivably slow. If this is orders of magnitude faster, it might be worth the extra false positives.
As a side note, my dream is a SAST that comments directly in the PR like a human reviewer would. Maybe that exists?