We now have static application security testing (SAST) deployed. All should be good. No, all is NOT Good!
The most challenging parts of any SAST tool deployment are the initial shock of potential vulnerabilities, coding errors, and risk. When I come into an organization for an audit, it is common to find their SAST tool running, the SAST tool kicking out a massive list of issues, and no one doing anything.
Does the organization have SAST? Check for compliance.
Does the organization do anything with the SAST reporting? No, compliance reports don’t ask that question.
Most of these engagements turn into conversations about how to take the first baby steps with SAST. There is no way the organization can stop and go back to fix all the issues a SAST will find. But something needs to happen.
In one company, we took the new Common Weakness Enumeration (CWE) tools, pulled together a team, and instigated the CWE Top 25. We then went to our SAST vendor and asked them to include the CWE top 25 in their reporting. We then took that CWE list and made a policy change:
“Code will not ship unless all these issues in the Top 3 CWE Top 25 are fixed.”
That list was much smaller. It set up a tempo of action that started working on the list. It established a principle in the organization that we would have a “production line stop” until the problem was resolved.
Was this perfect? No. The top 3 on the CWE list are not the “top 3 worse things that can happen to your product.” The key was to break the log jam, establish quality principles, and get moving. The following steps were more manageable once issues were crossed off the SAST list. As Miyamoto Musashi said, “It may seem difficult at first, but everything is difficult at first.”
After a few months, the CWE list expanded to the “top 5.” Six months later, it was the CWE top 10.” By that time, an audit team was reviewing the processes. They observed the progress and noted that most other “audits” had SAST but did nothing with the results.
More importantly, in this example, the SAST team was given the authority to “stop the line.” This empowerment will resonate with those who have read The Toyota Way. Many times, the product team and executives pushed for the code release. That “push to release” anxiety ran into the quality processes where the SAST team would say, “NO, this needs to be fixed first, or we will be liable.”
That single “empowerment step” in the Software Development Life Cycle (SDLC) clears the path for all the other Application security posture management (ASPM), Dynamic AST (DAST), Fuzz Testing, Infrastructure-as-code (IaC) testing, Interactive AST (IAST), Mobile AST (MAST), Open Source Testing, and other “normal” QA testing (functional, regression, performance, usability, etc.).
It all starts with action. Small steps, consistently stepping forward, is the tempo for the thousand-mile journey.