Source code analysis or static application security testing (SAST) is a methodology that analyzes code to find security vulnerabilities that make your applications susceptible to attacks and data breaches.
SAST is a key first step in application security and the journey from DevOps to DevSecOps. SAST allows you to detect vulnerabilities early on in the development phase, analyzing your source code before testing, deployment and release. Any vulnerability detected and fixed during development saves money during the proceeding iterations and greatly reduces the risk of a security breach.
SAST Blizzards Slow Development
Ever tried driving fast in a blizzard? It’s nearly impossible because your vision is severely limited. Standalone SAST creates a similar disability for Salesforce developers because of the sheer volume of false positives created, which wastes their valuable time and increases the time it takes to fix the real security vulnerabilities.
SAST Misses the Mark for Security
SAST tools are notorious for generating high rates of false positives, because source code analysis must err on the side of caution to catch all potential vulnerabilities. To be fair, most standalone SAST tools were not purpose-built to detect Salesforce application security vulnerabilities. Generally, you either get a code quality scanner for Salesforce that has some security rules added as an afterthought, or you end up with a multi-purpose SAST tool created for two dozen other languages, in addition to Apex. Regardless of that, SAST is just code analysis and false positives are a natural outcome.
Developers using SAST tools are typically forced to wade through endless lists of false positive warnings. They evaluate and rank the findings one by one until eventually at some point, the warnings start getting ignored as the developers become fatigued.
To limit this blizzard of false alarms, SAST must be paired with a runtime testing engine to perform interactive application security testing (IAST). IAST can be used to verify the exploitability of most SAST findings, tracing each vulnerability during execution, automatically proving that it is not a false positive. IAST can also detect critical injection flaws, like cross-site scripting (XSS) or SOQL vulnerabilities, which can often be missed by SAST alone.
Additionally, looking at your source code alone doesn’t help if you have third-party open-source software libraries that have become insecure due to a publicly reported security flaw or Common Vulnerabilities & Exposures (CVE). To mitigate this increasingly common software supply chain security risk, SAST must be integrated with software composition analysis (SCA) to find unpatched third-party software vulnerabilities.
Salesforce DevSecOps: Test Early, Test Often, Test Continuously
At the end of the day, security is a process, not an end goal. The best solution for comprehensive application security is thoroughly integrating your security testing tools into your Salesforce DevOps process to achieve efficient and effective DevSecOps. If Salesforce DevSecOps is implemented properly, it significantly drives down the cost of fixing bugs, not to mention it also drastically lowers risk.
A mature software development lifecycle (SDLC) leverages security testing at multiple points in the CI/CD pipeline, starting with your IDE then in each commit and beyond into deployment phases. If you “shift left” and test for security issues early, often, and regularly, your SAST can be quickly and tightly integrated with other security testing methodologies to keep your Salesforce safe and your data secure.
Summary
What are your thoughts on SAST? Have you experienced development delays from SAST related issues such as high rates of false positives? Let us know by leaving your comments below in the reply field.