Blog

Reducing Friction in AppSec Program Adoption: How Checkmarx One Can Help 

Organizations looking to adopt or improve an AppSec program often encounter challenges when trying to harmonize among various security scans and tools. And collecting, collating, and filtering security scan data is only half the battle—we also need to empower development and DevOps teams to take action to mitigate found vulnerabilities and risks in order to develop an effective security strategy. 

Often, information security and development teams have differing objectives; InfoSec teams aim to implement security controls to minimize risk as much as possible, whereas dev teams try to address security requirements with the lowest impact and effort without jeopardizing application stability or new features. And unless vulnerabilities are identified early in the development process, implementing necessary security controls can result in significant delays, frustrating both teams in the process. 

With Checkmarx One™, organizations can reduce friction among AppSec and development teams by simplifying, optimizing, and expediting the identification and remediation of security vulnerabilities, all within a single tool earlier in the software development process. 

Checkmarx One includes multiple scan engines, including (Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Infrastructure-as-Code (IaC) security, all on a single platform with easy-to-read, correlated scan reports. 

SCA Knowledge Center 

Checkmarx One SCA engine indexes and analyzes software components bound to the scanned application through imported packages and/or dependencies. Third-party software can introduce additional unexpected vulnerabilities in an application and our SCA scan engine can help developers and information security teams understand and remediate those vulnerabilities. 

When an application is scanned, Checkmarx One SCA identifies packages involved in the dependency tree of the application, together with Supply Chain Security (SCS) risks, licensing information, known vulnerabilities, and packages linked to software containers. 

The main result for a given package, found during a Checkmarx One SCA engine’s scan, allows the user to collect all the relevant data to triage the finding and transform this information into a remediation action: 

Checkmarx SCA suggests the newest version of the component, based on all the information collected during the scan and the history of releases of a given package, in terms of security fixes and updates. 

Upgrading to the latest version of a component would need a proper evaluation of impacts not only on application security, but also the functional capabilities within the application; thus, the process of decision may cause friction among Development and InfoSec teams. 

As in this example, upgrading a component three major versions ahead may disrupt features, result in incompatibilities, or require additional development effort. 

Usually, an application security program is adapted to the risk of the application that needs mitigation, and there are some opportunities for negotiation to balance the needs of InfoSec with those of Developers: mitigate risks as much as possible, without breaking any existing application functionality. 

Checkmarx’s AppSec Knowledge Center assists in this goal by identifying and illustrating the history of releases of a given package, to help in that negotiation: 

By browsing the change list, the user can identify the most suitable upgrade, allowing organizations to lower risk while minimizing impact. 

In the example above, there is a version of the mysql-connector-java package (5.1.49) which is suitable for lowering the risk from High to Medium while not changing the major version of the package: 

As a side note, the version slider can also help identify less effective upgrades; for example, a higher major version is not always the most suitable choice (version 8.0.12 still has high vulnerabilities): 

With the support of Checkmarx One’s SCA technology, InfoSec teams and Developers can implement a prioritized remediation program addressing even the most complicate dependency structure, with the opportunity of drilling down each specific dependency and version upgrade recommendation. 

Managing multiple vulnerabilities 

Checkmarx One offers multiple engines, including Software Component Analysis, API Security, IaC Security, and the well-known SAST engine. 

Checkmarx One SAST has the task of executing the source code analysis for an application, supporting a large number of programming languages and frameworks. 

Generally, security vulnerabilities are detected using specific patterns and the evidence of each result is shown through an attack vector or a data flow. 

For example, injection vulnerabilities (such as XSS, SQL Injection) are demonstrated if a dataflow is detected from an untrusted source of data (e.g., user-controllable input), known as a source, and a sink, which is a location in the code where the untrusted data “flows” to a destination point of impact (e.g., a Database operation, an HTML response), without a sanitizer (e.g., parametric queries, proper encoding). 

Due to the nature of applications and their modularity, often several attack vectors have data flows in common: the same user-controllable source could influence several sinks, or a single sink is the destination of multiple user-controllable sources. 

Checkmarx One is often able to identify the Best Fix Location (BFL) and can highlight the specific line number within the specific file where the vulnerability can be addressed, saving both InfoSec teams and developers time and effort. 

To help prioritize findings for both InfoSec and development teams, multiple filtering techniques can be leveraged for Checkmarx One SAST results, allowing teams to apply primary and secondary groupings. 

Filters can be applied by: 

  • Grouping all the languages involved 
  • Grouping results by severity 
  • Grouping results by Sink File (destination of attack vectors) 

Leveraging filtering, InfoSec and development teams can identify pertinent security scan results and properly prioritize mitigation actions. 

For example, in the figure below, we can see the files that are the most impacted by security vulnerabilities, since the files represent multiple attack vectors colliding in the same sink: analyzing these files will help developers resolve a larger number of results in one single analysis: 

In contrast, we can identify which files are most exposed to user-controllable input by grouping per source file: 

In the case of a relevant number of results, it is a major priority for InfoSec teams to lower the effort needed to analyze results. On the other hand, it is a major priority for development teams to address the most punctual (and eventually less numerous) locations in the code to apply the proper mitigations. 

This is the key to a successful AppSec Program. 

Evaluating the security posture 

In general, applications are made up of a number of modules, which may be tied in a single repository or widespread in multiple repositories. Furthermore, application modules may be owned by different development teams. 

An organization can be very diversified and one of the objectives of InfoSec teams is to evaluate the security posture of their assets from perspectives that can differ much from the technical organization of modules and repositories, as seen by developers. 

Checkmarx One offers the opportunity to group different modules of applications (or different applications) under the same entity, to aggregate results, and to have a perception of the general security posture of a given group of assets. 

Every AppSec program has an associated risk level for each asset involved; therefore, it is extremely important to reflect the same logic on the unified security tool. 

Within Checkmarx One, the user can create an application group, which aggregates scans from different projects, optionally giving grouping criteria through tags, and giving a “Criticality Level” to the group itself, as illustrated in the figure below: 

By filtering projects by tag, projects can be assigned to an application group, automatically. 

From a list of projects to application-wise security posture in just a few clicks! 

Scanned projects correspond to specific repositories, modules, languages, microservices, or monolithic applications: 

Grouping them by a given criteria will show the larger picture of the logical entity “Front End Apps:” 

InfoSec team can then see the real security posture of a group of assets: 

Being able to aggregate results across different sets of findings will help InfoSec teams evaluate the overall security posture of a multipart application, drive decisions toward more focused mitigating actions, and assist developers with more accurate employment of their efforts. 

Conclusion

Checkmarx One is a powerful platform, designed to execute a large number of scan operations on applications in a very short time frame. The results can be managed and integrated with multiple issue-tracking environments.  And because we aggregate results from multiple scan engines within a single platform, we improve developer productivity, foster better collaboration among InfoSec and development teams, and help organizations improve their overall security posture through targeted guidance and prioritization. 

Harmonizing the visibility of all the actors involved will help transform results from a security platform into a prioritized, feasible, accurate, and effective mitigation program. 

To see for yourself, sign up for a free trial or reach out to a sales team today

About the Author

About the Author

Never miss an update. Subscribe today!

By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to
the processing of my personal data as described therein. By clicking submit below, you consent to allow Checkmarx
to store and process the personal information submitted above to provide you the content requested.
Skip to content