Integrating Xygeni into your Workflow
Integration scenarios
Xygeni provides two main facilities for monitoring your build & deployment systems: a Scanner that runs on demand or when a certain event occurs, and connects to target system for analysis, and a Sensor that is installed in the target system and notifies to the Xygeni platform when events of interest occur.
The following are the most common scenarios:
Using the scanner command line
You may run a scan from the command line to analyze any local software project, a software repository, or a container image. The scanner discovers the assets and performs static analysis on the source code, package metadata and configurations.
The scanner runs scan steps aiming at each potential security issue class, and generates reports that could be uploaded to the platform.
In a snap, the Xygeni scanner, once installed, could be invoked from the command line like this:
The exit code from the scanner could be used for stop the build if the issues found are critical enough, acting as a "security guardrail".
The command line interface is the most direct way for running the scanner. Besides the alternative integration mechanisms listed below, the scanner’s command line could be used directly in places like CI/CD pipelines, build scripts, git hook scripts, etc.
See the Xygeni Scanner for further details on how to install and run the scans.
Integrate the scanner into a CI/CD pipeline
The build pipeline is a good point for running the Xygeni scanner, as it can check early in the build cycle if there are issues that should be resolved before advancing to the next step.
Under Continuous Integration / Continuous Delivery, an event on the source code repository often triggers a pipeline or workflow that builds, tests and perform different checks on the sources and the artifacts built. A Xygeni scan could be one of these checks. This ensures a continuos monitoring on security issues that may compromise the software supply chain.
For streamlined integration, Xygeni provides facilities for integration into build pipelines for the major CI/CD systems.
See the Integrate into CI/CD Systems section for full details.
Xygeni can automatically add a pipeline to run the scanner. please visit Managed Scans for further information.
Running scanner as a gate in a git hook
The Xygeni scanner could be run at client-side, before a commit is applied, by adding a pre-commit git hook.
If you have control on git hooks at the git server, you may add a pre-receive hook at server side, so a push may be rejected if the scanner finds critical security issues.
Two examples of common use cases for such hooks are (1) avoiding secret leaks committed to sources, and (2) critical file modifications not following a required change protocol.
For full details, read Git Hooks with Xygeni.
Using Sensors for activity monitoring
Unusual activity may indicate either a running attack or a sloppy change in the security configuration that opens the door to bad actors. To capture the activity as it happens in the software build & deploy systems, Xygeni provides a collection of plugins ("Sensors") that, once installed in the target systems, notifies to the platform the events of interest for correlation and identification of anomalies.
Live notifications for high severity alerts are provided to the user, allowing to take immediate action to mitigate the risk and prevent further damage.
To know how the sensors work and how to install them in the target systems, read Integrate Xygeni Sensors.
Uploading findings from external security tools
Xygeni prioritization and response can be also used with security findings reported by third-party security tools (namely external scanners), both open-source and commercial. The scanner provides a report-upload command for uploading the structured reports generated by third-party security tools, in areas like Static Application Security Testing (SAST), Software Composition Analysis (SCA), or Secret Leaks / IaC Flaws Detection.
Imagine that your organization selected tool X for SAST. In your CI/CD pipelines you may have a step where the SAST tool is launched to uncover vulnerabilities in your source code or configurations. The output of the tool could be ingested by Xygeni to normalize the findings, and then use the findings for prioritization and remediation. The workflow can operate both on findings reported by Xygeni scans or by your third-party tool of choice, at least when its output format is supported.
To know the list of external scanners and formats supported, please go to the external scanners supported. For full details on how to upload the results from a third-party scanner using the xygeni report-upload, read the report-upload reference.
Last updated