Time-constrained developers want to fix software bugs quickly to meet tight schedules. The three main options for integrated, speedy vulnerability remediation are open-source point solutions, vendor point solutions, or a managed service. There are compelling reasons to evaluate using a SAST platform like WhiteHat Sentinel Source, instead of using a point solution to run SAST scans.
It has been my experience that some developers are unqualified to validate the results such open source or unverified vendor point solutions provide, or to evaluate the real risk of the findings. Often, they will “curve fit” their solutions through trial and error changes, producing “fixes” that will fool the scanner but not solve the underlying issue. Developers should only commit fixes that they know will resolve the issue, not guess and hope the scanner no longer finds the issue.
There are several reasons why we at WhiteHat recommend using a SAST platform (e.g., Sentinel Source) instead of just a SAST point solution. Here are some of the drawbacks to a do-it-yourself model:
- Some SAST tools running on a developer’s local machine consume all of the CPU processing power and memory bandwidth; trying to use the system for anything else during the scan extends the scan time.
- Other more lightweight IDE-driven SAST tools (e.g., FindSecBugs or SecureAssist) only perform semantic analysis to match patterns, and cannot fully model the application and its data flows. In addition, these semantic tools will typically produce high false positive rates that erode trust, not only in the tool, but in integrating security into the development process in general.
- For most general purpose SAST scanners, the results will need manual verification to filter out false positives. This takes many hours. The illusion is that developers need scan results “right away” to meet tight deadlines. The reality is that when factoring the goal of fixing verified security vulnerabilities quickly while optimizing developer productivity, the accuracy of vulnerability results trumps raw speed.
At WhiteHat, our model for a successful SAST vulnerability rubric is:
- The security toolchain should be transparent to the developers, not an addition to their workflow.
- Scans should run automatically and not require daily interaction from developers.
- Developers should receive notification of issues via their normal bug tracking.
- When a vulnerability is successfully remediated, the bug ticket should be automatically closed.
- When tasked with a fix, developers should be able to commit their code just as when they are implementing a feature, move on to another task or go home for the evening – not be waiting anxiously for local scans to complete.
We’ve heard from customers for years about the hundreds of false positives that they get from running other developer SAST point solutions themselves, and of the many hours spent trying to resolve false positives. Having your own security or operations teams validate the results of a tool is much more expensive and will likely be significantly slower than WhiteHat’s Threat Research Center team of 150 experts. This is time developers could spend implementing new features, or improving code functionality or quality.
It is possible for our customers to get raw vulnerability data from Sentinel Source SAST scans via the Sentinel API before vulnerability verification has been completed and do their own analysis. Sure, it is faster; but it isn’t optimal. The true value of Sentinel Source lies in the accurate and actionable vulnerability descriptions and custom remediation advice provided with the scan results, after they are verified by WhiteHat’s Threat Research Center security experts.
I have also found that most development organizations are not capable of consuming the volume of security intelligence produced by running an in-house tool multiple times per day across multiple codebases. More time will be spent comparing one scan report to another than remediating vulnerabilities.
Our technology, combined with the vulnerability verification process, provides a persistent vulnerability model that reflects the real security posture of the application. This means that WhiteHat Sentinel Source technology plus the Threat Research Center’s knowledge, experience, and tools create the fastest time to accurate results at the lowest possible cost.