This approach has changed in today’s AppSec world as there is a need for platform that offers a wide range of scanning engines that fit the multiple domains of modern application development, such as SAST, SCA, Infrastructure as Code, API security, etc. Also, due to the speed and complexity of modern application development, it has become imperative that any scanning engine fits seamlessly into the developer’s pipeline to not interrupt workflows or delay delivery.  

And, admittedly, it is this trend of modern application development that has resulted in some AppSec experts moving away from DAST and other runtime solutions to focus on pre-deployment scanners, such as SAST and SCA. 

However, this trend is about to change again. Not only does Checkmarx One offer all the scanning engines that one would expect (and then some, such as supply chain security, IaC security, and API security), but our approach to DAST is set to bring it back into the mainstream. 

Getting Started with DAST 

Creating Environments and Running a Scan 

Since DAST executes against a running application, we need to create an Environment to define the application to be tested. This is where the environment’s name, URL, and type (web or API) are defined along with optional fields for tags and groups: 

Checkmarx One supports both web and API environment types. API environments have additional fields to upload API documentation files and link the environment to a project. See the API Security Integration section for more details.  

You can initiate a DAST scan either manually via the Checkmarx One portal (which we will cover in this section) or using the DAST CLI, which can be run independently or as a part of a build pipeline. 

After creating the environment, it will be visible in the environments list and is ready to scan: 

Hovering over the environment will reveal an action menu where we can start a scan, review results, and copy the environment ID (needed for pipeline integration). 

Selecting the scan option will open the new scan wizard where a configuration file is provided to define scan settings, user accounts, authentication method, etc.  

After providing the configuration file, we are ready to begin the scan: 

We can then use the View action to dive into the scan results: 

API Security Integration 

As we mentioned above, one of the key synergies in Checkmarx One is the correlation between API Security and DAST, where DAST can leverage the APIs that were discovered by API Security to drive the coverage of the DAST API scan. 

It is easy for users to link a DAST API environment with a Checkmarx One project to automatically consume any API Security results. We simply need to select a project in the project drop-down: 

Viewing Checkmarx One DAST Results 

And finally, let’s look at how to review and triage our DAST results which we can dive into using the environment’s view option: 

Individual findings can be investigated in detail by clicking on the issue itself. Here, on the risk detail page, we can find the more information for this vulnerability, such as its risk score, method, parameters, attack string, etc. as well as a detailed description on the vulnerability type and resolution and remediation advice: 

And most importantly, each DAST vulnerability also includes Evidence that has a quick link to copy the request and attack string to your local clipboard – this allows for easy validation of results: 

Learn more 

To learn more about Checkmarx DAST, you can see it in action here or contact your Checkmarx account team. 

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:

1. Parse source code
2. Build AST and DOM
3. Build data-flow graphs (DFG) from code’s source and sinks
4. Execute the scan preset’s queries against the DFGs
5. 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:

1. Only scan for what can be ‘reasonably remediated’
2. Design custom presets based on application type and threat modeling
3. 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:

1. OWASP Top 10 – 2021
2. High and Medium
3. High, Medium, and Low
4. 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:

1. Use selection strategies to select appropriate starting preset
2. Perform initial scan
3. Triage results to identify TP, FP, and FN
4. Modify vulnerability queries to remove any quality issues found in step #3
5. Adjust/select new preset if scope adjustment required
6. 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!