Introduction To Checkmarx One
As more and more companies adopt modern application development methodologies and aim to “shift-left,” they are also adopting modern application security testing (AST) tools and best practices like integrating and automating AST tools into their development pipelines. But are these companies ensuring that they’re checking for the appropriate risks and working with high-fidelity results?
Checkmarx, a leader in Gartner’s AppSec Magic Quadrant for five consecutive years, understands the needs of modern development. In an effort to streamline scanning and help development teams secure code without slowing time to market, we released Checkmarx One™, the most comprehensive application AST platform on the market. Checkmarx One brings our industry-leading SAST engine (and many others such as SCA, KICS, etc.) to your AppSec and development team via the cloud.
However, flexibility and speed-to-scan delivery are only part of the modern AppSec equation. Equally, if not more important, is providing solutions to the question above—this is where key Checkmarx One differentiators, presets and queries, make all the difference.
Presets And Queries In Checkmarx One
Before we dig into how exactly Checkmarx One’s presets and queries can help us address the challenge of checking for appropriate risks and working with high-fidelity results, it is important to understand the basics of both, including how they are used in the SAST engine scan process:
Preset = collection of vulnerability queries that define the scope of the SAST scan
Query = vulnerability rule written in CxQL
Any SAST engine scan initiated through Checkmarx One must have a preset defined at the organization, project, or scan level —see below for an example of a SAST preset being set on project creation via a presetName rule:
Note: The full list of predefined presets that are available in Checkmarx One can be found in our documentation here.
Selecting a preset from the drop-down menu, such as OWASP Top 10 – 2021, will limit that project’s scans to only check for vulnerability queries specific to the top 10 web application security risks according to the OWASP (Open Web Application Security Project) compliance guidelines for 2021.
After selecting a preset, each SAST scan generally follows this high-level process:
- Parse source code
- Build AST and DOM
- Build data-flow graphs (DFG) from code’s source and sinks
- Execute the scan preset’s queries against the DFGs
- Return vulnerabilities
As we saw in the definition provided for presets, they are integral to a successful, actionable SAST scan. Incorrectly setting a scan’s scope can cause scans to run long and inefficiently, but, even more detrimental, have results that provide a lot of noise and unnecessary work and confusion for your triaging teams.
Note: When evaluating AppSec platforms, it is important to verify that the SAST engine includes some sort of preset functionality as many solutions do not provide one which makes it impossible to limit result “noise.”
Speaking of triaging, while presets can ensure the correct scan scope, if your SAST results are not of high-quality and contain too many false positives (FP) or false negatives (FN) then your SAST solution runs the risk of becoming ‘shelfware’. This is another area in which Checkmarx One excels compared to competing solutions, as only Checkmarx One’s SAST vulnerability queries use a proprietary syntax, CxQL (C# derivative), that allows AppSec teams to easily customize vulnerability queries as needed to remove false positives and false negatives.
A common use case that neatly highlights the benefits of customizing queries can be found in cross-site scripting (XSS) vulnerability findings where a false positive may be occurring due to the use of an in-house sanitizer method that is not included in the Checkmarx One default out-of-the-box query. We can simply add this method to the appropriate CxQL query and rescan the project to remove the FP.
See this screenshot showing the ‘Find_full_XSS_Sanitize’ query via Checkmarx One’s CxAudit console:
Now that we understand the basics and benefits of presets and queries and Checkmarx One, let’s take an in-depth look at how we make the best use of both.
Preset Selection: Recommendations And Best Practices
There are several preset selection strategies that have proved to be successful amongst our customers of all sizes, from SMBs to the largest Fortune 500 enterprises:
- Only scan for what can be ‘reasonably remediated’
- Design custom presets based on application type and threat modeling
- Start small and expand—maturity model approach
Only Scan For What Can Be Reasonably Remedlated
One of the common mistakes that we see for those both early in their SAST scanning journey and those with mature programs is a misguided but intentional approach to scanning for everything. A desire to get their money’s worth or prevent all possible risks results in their initial preset selections (or lack of options to choose a preset with competitors) returning an unworkable volume of risks that weighs on all teams involved. Unfortunately, this tends to result in major efforts to review and triage these extreme volumes of findings, only for development teams to end up prioritizing and remediating a handful of vulnerabilities.
A better approach is to consider what is most critical for each project/team to remediate and select a preset with a scope that allows your teams to reasonably address and fix these issues before the next scan. This can help prevent frustration at unresolved issues and create momentum as teams close out issues.
Select Presets Based On App Type And Threat Modeling
It is also extremely important to use your knowledge and understanding of a project to choose presets which make sense based on the application’s architecture and application type.
Application type can influence the kind of weaknesses an application may be susceptible to. For example, if there is no front-end web code in the application, XSS vulnerabilities, by definition, will not be present—so it does not make sense to use a preset that will try to find XSS weaknesses. Or, if an application doesn’t communicate with a database, SQL injection vulnerabilities will not be present and don’t need to be sought either.
This is where the use of predefined presets such as Android, Apple Secure Coding Guide, JSSEC, OWASP Mobile Top 10 – 2016, OWASP Top 10 API, WordPress, etc. are beneficial.
Start Small And Expand: Maturity Model Approach
Starting small is a good strategy for any customer, no matter the size, resource capacity, or AppSec maturity. But, it’s particularly appropriate for development teams that are new to application security testing. Starting small when selecting a preset will ensure teams aren’t overwhelmed or scared away by thousands of results. Once a team has sufficiently triaged results found with a small, targeted preset, the scope of the preset can be widened to look for additional kinds of results.
This approach is most often implemented by taking a severity-based approach.
An example maturity model, utilizing the predefined presets, may look like the following, with each preset used until all scan findings for that preset are remediated, after which, the project advances to use the next preset:
- OWASP Top 10 – 2021
- High and Medium
- High, Medium, and Low
- ASA Premium
Project Onboarding: Putting It All Together
As noted previously, choosing the right preset is only half of the battle in providing suitable and high-fidelity SAST scan results. Each preset includes a selection of vulnerability queries, and it is these queries that ultimately identify the risks within a scan. The accuracy and robustness of each query is the driving factor in whether FPs or FNs are present in your SAST scan results and Checkmarx One’s SAST engine is the only AppSec platform with a truly flexible query language open to its users.
We recommend that our customers, either themselves or utilizing our services, perform a process that we call project onboarding first for their ‘main business applications’ followed by lower priority applications. Project onboarding is an optimization process that includes the following:
- Use selection strategies to select appropriate starting preset
- Perform initial scan
- Triage results to identify TP, FP, and FN
- Modify vulnerability queries to remove any quality issues found in step #3
- Adjust/select new preset if scope adjustment required
- Rescan and repeat process as necessary
This type of complete and dynamic approach is required as the industry changes to modern application development and its push for integrated SAST and other engine scans become more and more prevalent. Checkmarx One and its SAST engine are one-of-a-kind, and our unique use of presets and queries set us apart.
Request A Demo
Reach out to us today to request a demo, or sign up for a Free Trial to see for yourself!