The concept of On-boarding

Maverix implements mechanisms to automate and, therefore, greatly simplify and accelerate the process of integrating the system into a single software development cycle, and thus facilitate the overall security control of the software being developed. This process adds information to Maverix about code bases, artifacts, etc., generates corresponding security pipelines, launches scans and if necessary initiates data exchange, such as scan results, with other tools and all these operations are performed automatically. We use the term on-boarding to define this process.

In other words, on-boarding is a fast and efficient way for the DevOps team to quickly and cost-effectively redefine existing workflows in favor of further software development in the DevSecOps paradigm. Developers already using DevSecOps practices get a powerful tool that can drastically reduce the amount of manual routine operations and improve the efficiency of production processes.

In practice, on-boarding in Maverix is implemented using scripts launched with a set of specific parameters in the Command Line Interface (CLI). This approach implements a simplified way of interacting with the system's REST API.

Two scripts are used to scan code bases and artifacts, respectively: scan_codebase.py and scan_artifact.py, please see the table below. The scripts are written in Python 3.7 and interact with the Maverix back-end via the http protocol. A description of the script parameters and examples of their use for scanning code bases and various types of artifacts are given in Appendix 1 and Appendix 2, respectively.

 

Script Description
scan_codebase.py Scanning of code bases
scan_artifact.py Scanning of artifacts

 

As an example, let's take a step-by-step look at a typical code base scanning process.

py scan_codebase.py \
--url http://hub.dev.maverix.co/ \
‎--token ***** ‎\
--appcode 09022021_cli ‎\
--branch master \
‎--codebase-url http://gitlab.service.yourcompany.com/test/java-web-project.git
  1. Maverix finds the application whose code was passed using the ‎––appcode parameter, otherwise it creates a new one.
  2. Maverix finds the code base specified by the --codebase-url and ‎--branch parameters, otherwise it creates a new one.
  3. Maverix finds security pipeline for codebase analysis. If the security pipeline is found, Maverix starts it, otherwise a new security pipeline is created based on a suitable template (see the "Security pipeline settings" section) and a scan is started. If a suitable template isn't found, an error message is generated, see the "Appendix 3. Scan results". In this case, you should create a corresponding security pipeline template using the Maverix user interface, see the Security pipeline settings section.
  4. Once the scan is completed, the results are returned taking into account the Quality Gate (see the section "Adding Quality Gate to Security Pipelines") and a link to the scan results is displayed in the CLI. After clicking the link (authorization in Maverix is required), you can view the list of security issues detected during the scan. This functionality allows you to quickly evaluate security issues detected during the scan, without the need to use filtering tools. In addition, scan results can be saved to a text file that contains information on the scan status and the reason for its assignment, the practices used, etc.

In addition, there is an interaction mechanism that allows you to import scan results from various AST tools (Checkmarx, Nexus IQ) via REST API. This approach is convenient when a company has already built a development process using particular tools, and the main task is to transfer all data to Maverix. In such a situation there is no need to run a scan like in the example above. As a result, all the necessary objects and links are created on the Maverix side: applications, codebases, security pipelines. Moreover, the import of vulnerabilities is launched, and QG criteria is checked.

The import_results.py script is used to import the results. A description of the script launch parameters is given in the "Appendix 1. Parameters of on-boarding scripts".