Stayin’ Put

GitLab’s users, whether they are Software Developers, DevOps, or AppSec engineers, want to consume as much of the application security scanner’s results as possible within GitLab. GitLab is already a complete DevOps platform from managing -> to planning -> to creating -> to releasing, so it is just common sense GitLab users would want to have security directly within GitLab. GitLab users can consume Checkmarx security-related vulnerability results at three different integration points:

• Merge Request Overviews
• GitLab Issues
• Security Dashboard (for GitLab Gold/Ultimate tier or public projects)

Every organization, even teams within the organization, will want to run security scanners at different points of the SDLC, but by best practice from Checkmarx, it is suggested to scan at the Merge Request stage. With security scanning completed at the Merge Request stage, an assessment can be performed with the scan results and the merge can be blocked, or GitLab Issues can be created. But, what kind of result data should be consumed?
Checkmarx provides:

• High level summary of CxSAST & CxSCA findings
• Data flow from source to sink within the source code
• Short summary of the specific vulnerability that was identified
• Links to just-in-time training (CxCodebashing) and online resources for remediation
• Links into Checkmarx platform for even more comprehensive results

CxFlow – Under the Hood

Checkmarx maintains a spring boot application called CxFlow, which acts as a scan and results orchestration tool to automate security scans and integrate the results into CI/CD tools such as GitLab. Some key features and capabilities include:

• Scan Initiation – CLI or Webhook Events
  • CxFlow can be configured in two different ways: using CxFlow from a command line interface or have CxFlow work as a server and listen for Webhook events. Once an event is triggered or received, the initiation of a Checkmarx scan will occur automatically.
  • Merge requests, or even commits of the source, will trigger an existing pipeline within GitLab’s CI/CD and initiate a scan via CxFlow; the existing pipeline just needs an edit to include a stage that will invoke CxFlow.
  • The scan initiation will either create a new project if it does not exist or update a current one.
• Results Management
  • As far as consuming results, the scan results are file based (csv, json, or xml) making it easy to import into defect tracking systems or dashboards.
  • CxFlow also drives a result feedback loop eliminating having to do manual intervention (opening and even closing defects).
  • You can always filter the results created based on any filtering criteria.
  • The results are easy to consume, in a way developers want to consume and most importantly, actionable.
• Defect Tracking
  • Consolidates issues of the same vulnerability type in the same file – instead of multiple issues, it is just one.
  • Once all references to the vulnerability type of that issue are fixed, the ticket will automatically close.
  • You can base it on policy – severity / CWE / vulnerability type or state (urgent / confirmed).
  • Defect tracking is also supported for both CxSAST and CxSCA results.
• Feedback Channels
  • Not only does it support GitLab Security Dashboard and GitLab Issues, but also Jira, Email, Service Now and Rally.
• Ease of Consuming the AST Service
  • Effortless option for the development teams to quickly scan projects.
  • There is no overhead when configuring and managing builds.
• Mass Effortless Scan Configuration
  • You can quickly automate the scan of multiple repositories.
  • Again, there is no overhead when configuring and managing builds of many repos.
• Automation with Developers’ Common Toolsets
  • In this case, GitLab.
  • You want to get the details of issues to those who must address them – the developers.
  • Drive security testing based on GitLab activity.
  • Publish issues to existing backlogs.
  • Keep developers within GitLab.
• Eliminate Unnecessary Manual Tasks with Checkmarx Automation Capabilities
  • Free up time to focus on things that matter.
  • Shift as far left as possible.
  • Constantly scanning the latest code.
  • Replaces need to scan in the IDE.

GitLab / Checkmarx Workflow

Below is a visual picture of the Checkmarx workflow with GitLab’s CI/CD.

Now let’s describe this flow in more detail: 

1. Setting Variables

Variables are needed to perform Checkmarx authentication and to define Checkmarx scan settings read by CxFlow. This can be set up per project or by “groups”. GitLab has an awesome feature where you can have a file as a Variable. We leverage this feature and have CxFlow’s yaml configuration file as a Variable.

2. Defining a Stage

Per GitLab best practice, application security testing should be done during the “test” stage of the pipeline. During the test stage of the pipeline, GitLab will pull the Checkmarx docker container where CxFlow CLI is stored. CxFlow CLI should then be invoked to initiate the scan based on the settings defined in the config file Variable.

3. CxFlow CLI Initiates the Scan

CxFlow receives the request with the Checkmarx project settings and the GitLab repository details. CxFlow performs the authentication into the Checkmarx server and then initiates a scan. It will wait for the scan to finish. 

4. Checkmarx Performs SAST & SCA Scans
   
5. CxFlow Parses Results and Updates GitLab

CxFlow waits until the scan is done, parses the results and will update the Security Dashboard, GitLab Issues, the Merge Request Discussion, or all three. If the issue has been fixed, it will automatically close it.

Pertaining to development tools, DevOps is also about automation of the different tooling in use that improves the speed of software delivery. Designed primarily for those embarking on DevSecOps initiatives, Checkmarx CxFlow integrates security into the existing tools so that secure software development can be achieved without requiring any extra tools. Using the existing tools already in place, CxFlow seamlessly operates in the background.

Checkmarx CxFlow is all about the automation of AST solutions into the tooling within today’s organizations. It was developed to address AST automation head-on, but there is more to CxFlow than meets the eye. Below is a list of the top three benefits organizations will experience when using CxFlow with their CxSAST and CxSCA deployments. Let’s delve a little deeper into what CxFlow is all about.

#1 The Most Shift-left Where Automation Can Occur

Traditionally, application security testing (AST) solutions on the market operate within the CI tooling in use and scans are normally performed after a merge/build has taken place – further to the right of the SDLC, so to speak. CxFlow on the other hand, allows organizations to shift that functionality to the left since CxFlow is an orchestration layer that simplifies the implementation and automation of AST in today’s modern development environments.
Using CI plugins to launch AST scans are still supported and even recommended, for example, launching scans from Jenkins, CircleCI, Travis CI, Bamboo, TeamCity, etc.

However, AST scans can now be integrated and launched directly from code management tools as well. CxFlow effortlessly integrates with application release orchestration and agile planning tools such as GitHub, GitLab, BitBucket, Azure DevOps, etc., enabling fully automated scanning of applications and the delivery of consumable results to the developers themselves.

Plus, CxFlow integrates directly with bug/defect tracking tools like Jira, Rally Software, ServiceNow, SonarQube, etc. This eliminates the need for time-consuming manual scan configurations and allows developers to publish and update findings based on policy to a defect/backlog management system for application teams to track.

#2 End-to-End Automation, from Scanning to Ticketing

Leveraging Checkmarx’s unique ability to scan uncompiled code, CxFlow automates the steps required to scan code earlier in the SDLC. This eliminates the need for time-consuming manual configuration of scans and allows developers to publish and update scan findings based on a pre-configured policy within the code management tools themselves. After the initial configuration, AST scan activity is performed hands-off with no human intervention required whatsoever beyond a pull request initiated by a developer.
With CxFlow, upon a pull request in the code management tools in use, the developer not only receives notifications from scans as comments that are related to functionality, but also as comments that are related to security, since CxFlow easily integrates with IDEs and code management tools in use. Just like that, the developer is able to have their code reviewed once for all bugs and would be able to close the full feedback loop with ticketing systems, all while the code is still fresh in their mind.  This allows developers to:

• Catch and fix vulnerabilities during the coding phase (earliest stage of development).
• Work as usual with no disruptions, no new tools, no additional security reviews needed, etc.
• Treat security bugs and functional bugs alike and allows them to immediately address those bugs within the code branch(es) they’re currently working on.
• Reduce the overhead of manually opening, validating, and closing security tickets without spending countless hours in bug tracking/ticketing management systems.

#3 Removes Friction Between Developers and DevOps/AppSec Teams

CxFlow eliminates the manual and time-consuming configuration per project within DevOps, thereby removing the friction between developers and DevOps teams when needing to add scanning steps into the jobs of all CI pipelines, since adding jobs/steps to scan code is challenging using the older CI-scan model. Today, CxFlow:

• Simplifies the AST lifecycle through automation into the tools already in use by taking a web listener approach, listening for events from the source code repositories and triggering AST scan actions upon such an event.
• Enables developers to have little if any intimate knowledge of CxSAST or CxSCA solutions since developers receive their automated scan reviews as comments/reports right from the repositories, not the AST solutions deployed.
• Works off the concept of a protected-branching strategy whereby you can configure master, develop, and security branches, for example, that are all deemed protected. This means that pull requests, push events, etc. will trigger scans and produce results when any code changes are made that are associated with those protected branches.
• Reduces TCO and improves ROI for scanning tools by reducing the need to manage and maintain multiple CI plugins concerning installation, updates, etc., when multiple CI solutions are in use.

Conclusion

CxFlow streamlines the configuration and orchestration between the development tool set and the Checkmarx Software Security Platform to drive AST automation. With this, organizations can instantly onboard their development, security, and operations teams and simplify the governance of their security policies and DevSecOps processes.

The traditional AST solution providers are leaving developers behind, because without the ability to scan source code directly, the traditional players can’t efficiently work within code management tools similar to Checkmarx.

Clearly, integration is key to automation and CxFlow enables the most shift left approach where automation can actually occur within the SDLC—changing the way AST solutions are integrated with in all DevOps environments.