Doing testing early and doing it often is essential in modern software development because it emphasizes the need to integrate software security testing throughout the SDLC. With the evolution of DevSecOps, where speed is vital to software deployment and delivery, it’s important to achieve continuous software assurance to give developers and organizations the confidence that no known vulnerabilities exist in software before it’s released.
Doing it early means pushing SAST into developers’ workflows to find and fix security issues that can lead to vulnerabilities when it’s the cheapest to remediate and mitigate. Doing it often addresses the need to run SAST in CI/CD workflows to find security issues as software is being committed and integrated into source code repositories like GitLab, GitHub, and Bitbucket.
Using SAST can’t introduce major delays into the deployment and delivery process or become an impediment that lowers the adoption of static analysis in developers’ workflows. This is where the traditional approaches with SAST tools have failed and performed miserably in modern software development environments.
With the emergence of DevSecOps, SAST tools became one-dimensional, focusing primarily on trying to scale the demands of continuous integration testing and totally neglected the need to do it early in developers’ workflows. With the shift to continuous integration, SAST tools were heavily focused on trying to automate static analysis to keep pace with the frequency in which SAST tools would be invoked on code commits. We found out that SAST tools didn’t perform well and clogged up CI/CD workflows, which forced many organizations to discontinue using them or use them sparingly to meet the pace of the business.
Shift With Developers in Mind
I have been a firm believer that a shift-left approach to SAST must shift past CI/CD and push into developers’ workflows because you can’t test security in. Rather, you must build it in from the start with an awareness of what could go wrong with poor coding practices. SAST tools provide a way to give developers the immediate feedback to avoid egregious coding violations that often lead to security vulnerabilities. This is one of the areas Parasoft SAST tools excels at, allowing development teams to codify secure coding practices in development workflows from the start.
A developer-centric SAST increases developers’ productivity. That means it doesn’t slow them down and gives them continuous feedback that’s explainable and understandable directly in their existing tools and workflows. This bodes well for development environments looking to deploy and deliver software iteratively to meet the growing demands and needs of the business.
Developers are essential to creating and delivering value to customers. Anything that takes away from their innovation can impact the business in a negative way. This is one of the realizations that have shifted how SAST tools are consumed by developers, which means SAST tools should be made and tailored specifically for developers.
SAST Missed the Mark
I funded research and development in static analysis from 2012 to 2016 and have seen the shift from an AppSec focus to a developer-centric focus. In that time span, I co-sponsored the OWASP Benchmark Project and funded the following:
- Tool studies similar to the NIST SAMATE program
- A testbed for improving static analysis
- A project to modernize static analysis tools
I realized SAST tools in general were lackluster, underperforming in many technical areas, and didn’t fit well into developers’ workflows.
Also, during this period, many in the industry considered SAST dead and began pushing other application security testing capabilities such as IAST and DAST. There’s no question SAST tools struggled to meet the growing demands of modern software development where speed to testing, deployment, and delivery is what everyone wanted to be when they grew up. SAST tools are in the crossfire of a movement that has accelerated so rapidly that you must automate SAST to scale to keep pace and improve the fidelity in analysis results to quell the negative sentiments driven by false positives.
The 4 Core Elements
There are four core elements — essential ingredients if you will — that developers should consider when buying SAST tools. While there are other ingredients that are appealing and attractive to developers, I narrowed them down to four based on my experience funding research and development in static analysis, as well as my time working with organizations in formalizing and transforming their DevSecOps practices around security testing.
I also take into consideration how developers should use SAST tools in the context of a SDLC, where they should implement static analysis as a preventive measure to build security in from the onset. This perspective helps shape the following ingredients for a developer-centric SAST.
Seamless Integration
Developers work primarily in their IDEs. Doing testing early requires seamlessly integrating into developer tools and workflows to prevent security issues from the onset.
Static analysis is a preventative measure that developers can use to eliminate egregious bugs and coding violation that often expose security vulnerabilities. As developers code, SAST tools should provide immediate feedback regarding what went wrong, and what could go wrong. This immediate feedback allows developers to find and fix issues right in their workflows.
SAST tools must seamlessly integrate with popular development tools and platforms to help remove barriers for developers to incorporate security into their development activities. Incorporating security into development activities is essential and shouldn’t wait until continuous integration to run SAST tools. Addressing the low hanging fruit with coding issues is ideal for organizations looking to accelerate software development. This is done by enforcing security compliance with SAST tools.
Many studies associated with software maintenance costs all point to the fact that remediation and mitigation techniques are cheaper earlier in the SDLC. Doing it early is one of the essentials to getting the most value out of SAST tools and plays an important role in reducing costs and accelerating software deployment and delivery.
Simplify Remediation and Triage
Most developers are not security experts. We shouldn’t expect them to be. Navigating through SAST results and understanding what to fix and suppress can often be time consuming and discouraging for developers.
SAST tools are known to generate a lot of noise, which includes warnings and false positives, combing through the noise to focus on what matter the most is essential for simplifying remediation and triage. Understanding what to fix and how to remediate security issues is important in reducing risk associated with software. Developer-centric SAST tools must provide rich context that’s explainable and provide developers feedback regarding the consequences of coding practices in creating potential vulnerabilities.
Simplifying remediation requires an understanding of what matter the most to the developer for a given project, and what type of attacks pose the most risk to their organization. This will assist SAST tools in prioritizing warnings and issues based on context and help soundproof your SAST from noise that is often associated using static analysis. This allows developers to focus on those issues that matter, reducing triage time to expedite remediation and fixes.
Fast and Accurate
For years, static analysis had a reputation of being complex and complicated with sophisticated analysis techniques that take forever to run and complete. Modern software development dictates otherwise and emphasizes the need for SAST tools to be lightweight, simple, and fast. In addition, SAST tools need to be reliable, accurate and provide immediate feedback to developers to increase developers’ confidence in using SAST in their workflows.
Developer-centric SAST often employs rules and checkers that focus on pattern matching to detect common coding issues that lead to security vulnerabilities. Here are a few examples:
- Poor use of language constructs
- Use of insecure functions
- Poor coding practices
- Vulnerable third-party components
Eliminating these classes of weaknesses from the onset helps improve security and quality and reduces risks in software. Codifying secure coding practices in developer workflow help eliminate these common mistakes and make developers more aware of what could go wrong. This also helps reduce remediation efforts and enables developers to work on features rather than spending their time fixing bugs.
The use of AI/ML can speed up analysis and make SAST tools perform better. Employing techniques like code coverage and differential scanning is ideal for automating SAST in CI/CD workflows where bottlenecks are often introduced if SAST tools have to keep scanning the entire codebase.
Most commercial SAST tools leverage AI/ML to increase the fidelity of results, but what separates vendors in this space is how their SAST tool allow developers to drive how models are applied across their software projects and code base. Parasoft AI/ML is advanced in this area and allows developers to drive training to the models with contextual information relevant to their software projects.
Automate Security and Compliance
AppSec team should be advocates for developers and help codify security practices in their daily activities. Developer coding practices should be governed by policy, guidelines, and standards that make it easier to integrate security and compliance into their daily tasks. SAST tools that can do that become a developer’s best friend because it doesn’t slow them down, provides feedback for improvements, and allows them to better understand potential risks in their coding practices.
Automating security and compliance with static analysis helps integrate security and validate compliance in developers’ workflows. This removes the need for manual checks that enable development organizations to scale security testing with SAST across the enterprise to better understand risk in software.
A developer-centric approach incorporates security and compliance standards like CWE, OWASP Top 10, MISRA, and CERT secure coding standards, so as developers code, they can get immediate feedback about security and compliance. This allows AppSec teams to work with development teams to codify security and compliance into development activities to detect security and compliance early and often.
Treating security and compliance as code establishes a common language for developers that can be enforced with SAST tools so they know what to do and can do it for themselves. It also allows development organizations to reuse common security and compliance standards in development workflows and track risk in software development projects. SAST tools should provide organizations with analytics and reporting capabilities to increase awareness of potential threats and vulnerabilities that can also be used to facilitate continuous learning for developers.
The Secret Sauce
While these four ingredients make it easier for developers to use SAST tools in their daily activities, the secret sauce that enhances the ingredients is developer advocacy.
Many would argue that traditional SAST tools don’t focus on developers and create barriers for adoption. A huge part of developer advocacy is listening and collecting feedback from developers and using it to advance the state of practice.
Throwing SAST results over the proverbial fence isn’t advocating for developers. Implementing overly complex and hard to use SAST tools isn’t advocating for developers.
Pushing SAST tools into development workflows for fast, accurate, and automated security and compliance is developer advocacy.
Do it early. Do it often.
Content provided by Parasoft
The post Four core elements of developer-centric SAST appeared first on SD Times.
from SD Times https://ift.tt/3dU4CUN
Comments
Post a Comment