If you’re involved in securing the applications your organization develops, there is no question that Static Application Security Testing (SAST) solutions are an important part of a comprehensive application security strategy. SAST secures software, supports business more securely, cuts down on costs, reduces risk, and speeds time to development, delivery, and deployment of mission-critical applications.
SAST scans code early during development, so your AppSec team won’t be scrambling to fix unexpected vulnerabilities right before that big launch is planned. You’ll avoid surprises and launch delays without inadvertently releasing risky software to customers — or into production.
But if you consider SAST as a part of a larger AppSec platform, crucial for those who wish to shift security everywhere possible in the software development life cycle (SDLC), some SAST solutions outshine others.
Knowing what to focus on
With a plethora of players in the market, sometimes making competing claims, it’s confusing to know what to look for when selecting a SAST solution. It’s important to understand what’s behind each claim and see if it matches reality.
Sometimes, the solution an organization initially starts out with isn’t the right one as an organization grows or as other teams start to use the solution.
Therefore, the real question is, “What SAST solution is best for my organization?”
What to look for in a SAST solution
Fit into your AppSec program
A comprehensive application security platform enables you to simplify security — in applicative code, open-source dependencies, supply chains, IaC, APIs, containers, and more — all from a single scan. A platform provides rapid, correlated, and accurate results to speed remediation.
When looking for a SAST solution, if it is part of a unified AppSec platform, it will provide the best value to secure modern applications. A complete platform should provide centralized management for SAST, SCA, SCS, API security, DAST, IaC security, and container security.
A platform should be able to grow with you as your needs change. When comparing platform-based approaches to AppSec, make sure they can correlate scan results across different scanning engines so you can obtain an overall risk assessment across projects and applications, instead of trying to manually aggregate results from various standalone AST solutions.
Flexibility is crucial
No application is alike, and different stakeholders — such as CISOs, application security teams and developers — have unique needs.
Sometimes they need to get an overview of the risks in an application and “scan wide,” while at other times they need to “scan deep” into a specific part of an application or explore very specialized risks.
Having the flexibility to scan deep and scan wide covers all use cases. It provides flexibility so organizations can standardize on a single platform that covers all use cases.
Presets (also known as rulesets) are groups of out-of-the-box scan rules that can be applied to various scans. SAST solutions should come prepackaged with a range of presets to support major use cases, including getting a “big picture” overview of their code’s risks and vulnerabilities, as well as ensuring regulatory compliance.
Sometimes, no matter how extensive, pre-packaged rulesets are not enough, and an organization wants to edit or create custom rulesets. This helps improve accuracy and minimize false positives.
Accuracy matters in SAST
For a SAST solution to be useful, it must be accurate.
When talking about SAST, “false positives” — that is, flagged items that are not true risks — are often mentioned. The way around those is flexible presets and customized queries or rules.
But even more worrisome is “false negatives” — that is, risks in your code that are overlooked and not identified by your SAST scanner. With false negatives, you are unknowingly releasing vulnerabilities without even the chance to explore and rectify them. You are flying blind.
One way to reduce the chances of false negatives is to use an “application-centric” solution that understands how your application works. This solution can track the flow of data through code and execute the code with symbolic inputs, allowing it to explore all paths through the code to find any that are exploitable. While relying on regex-based tools may sound convenient — they are, after all, lighter and faster — that is not going to be the case once your company is in the headlines due to vulnerable code that was released in the wild.
Another solution is to use the right profile for your codebase and to create custom queries when needed. For example, if an organization has developed its own custom sanitizer, telling the SAST about this sanitizer by adjusting the queries can eliminate false positives. Having a customizable query language is key to reducing false positives without enabling false negatives.
Find a SAST solution works for developers
As mentioned above, getting to problems at their source, and not simply fixing syntax errors, is quicker and saves money in the long run. Fast scans that miss vulnerabilities because they do not understand how the code relates to the applications are not the goal. But neither is forcing already rushed developers to go through each error with a fine-tooth comb.
It’s critical to fix problems fast. The way to do that is by providing a “best fix location.” This points developers to the exact location to fix a vulnerability, saving them time and energy. And often, by modifying code at the best fix location, that single fix can eliminate multiple vulnerabilities and reduce the number of code corrections needed.
Most developers are not security experts — but a good SAST solution can turn them into security heroes.
Look for a solution that shows developers how to fix vulnerabilities, explains the meaning and impact of the vulnerability, and helps them write more secure code in the future. Some solutions deliver or integrate with code training that teaches developers how to identify and write secure, quality code.
Bite-sized, gamified code security training allows for easy and quick learning that increases developer adoption, and this approach may even enhance employee retention.
With the right SAST solution, your developers won’t need to go to Stack Overflow or Reddit seeking advice on how to fix an issue.
SAST that supports your existing software development life cycle
Languages and frameworks change. Your SAST solution should not. Therefore, it’s important to have a SAST solution that keeps up with the latest language updates and supports the newest languages. This allows you to support your developers, wherever they choose to go.
Wide language support is also critical to enable an organization to standardize on one solution across teams and across the organization.
For example, if you are in finance, the organization may need to support legacy languages such as COBOL, which still powers many banking transactions, as well as emerging mobile application development languages such as Flutter. Even though different developers may work on both components, organizations can maximize efficiencies by standardizing on a single application security platform, rather than resort to a mishmash of vendors.
Discovering APIs in source code
Driven by recent high-profile data breaches, there is growing awareness of APIs as potential entry points into your applications. OWASP even has an “API Security Top 10”, where they cover the top ways that APIs can be breached, including Injection, Security Misconfiguration, and Broken Object Level Authorization.
One of the challenges of most API security solutions today is they’re all shift-right. For example, WAFs protect the runtime environment while DAST tests compiled applications. While it can be said that “good security starts with good code”, APIs test that adage to an extent, since each API is different and comes with its own unique security challenges. Existing solutions also require developers to document their APIs so that the WAF and DAST solutions know what to protect and test. However, developers are often inconsistent with API documentation, leading to shadow APIs.
The good news is that every API in an application is written in code. At a minimum, your SAST solution should be able to discover API endpoints defined in the code and inventory them. But ideally, it should also be able to show you what vulnerabilities are present in each API, so now you can prioritize vulnerabilities to fix based on the business value of the API.
Having SAST + DAST together on a single platform
Anyone who has spent time developing software or has been tasked with securing millions of lines of code that make up a modern application, understands that there are many industry-accepted methods to scanning and testing applications. The point of scanning code with SAST is to detect coding errors that could potentially lead to exploitable vulnerabilities – and everyone knows that vulnerable code is the leading cause of every known breach today. But the value in using both SAST and DAST tools is that they both find different vulnerabilities.
However, if you have disparate tools, that means you are managing them separately through different interfaces, you have to go to separate places to see the vulnerabilities detected, you must analyze and triage the vulnerabilities differently, and you track fixed vulnerabilities separately.
Having SAST and DAST on the same platform means you can see your vulnerabilities in one place, manage and triage them through a single workflow / process, and send them to your developers to fix through the same workflow. You can also integrate them at different points of your SDLC using a common set of integrations.
And as a bonus, if your SAST can discover and inventory APIs in source code and find undocumented APIs, then you can also test those undocumented APIs using DAST. This helps you get more value out of your SAST solution by taking its findings and improving security outcomes in other areas in a 1+1=3 way.
Find a SAST solution that enables you to make shift happen
As you research SAST solutions, you will undoubtedly hear many promises to shift your AppSec left. But that is no longer enough. As modern application development practices increase use of APIs, open source code, and other innovations, new risks emerge. Today, everything is an application. You now need your application security to shift everywhere.
Note: This insightful article has been expertly written and thoughtfully contributed by Avi Hein, Product Marketing Manager at Checkmarx.
Source: thehackernews.com
