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 the target system for analysis. As well as a Sensor that is installed in the target system and notifies 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 can be uploaded to the platform.
To quickly access the Xygeni scanner after installation, execute the following command in the terminal:
# Scan a directory with software
xygeni scan --dir PATH/TO/PROJECT
# Scan a software repository
xygeni scan --repository URL
# Scan a container image
xygeni scan --image IMAGEThe exit code from the scanner can be used to stop the build if the issues found are deemed critical enough, acting as a "security guardrail".
Integrate the Scanner into a CI/CD Pipeline
Integrating the scanner within a CI/CD pipeline offers a proactive approach, enabling the early detection of potential issues during the build and development process. This ensures problems are addressed promptly.
Under Continuous Integration / Continuous Delivery, an event on the source code repository often triggers a pipeline or workflow that builds, tests and performs different checks on the sources and the artifacts built. A Xygeni scan is an essential check, ensuring continuous monitoring of security issues that may compromise the software supply chain.
For streamlined integration, Xygeni provides facilities for integration into build pipelines for the primary CI/CD systems.
Running the 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 over git hooks at your 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 common use cases for such hooks are: avoiding secret leaks committed to sources and critical file modifications not following a required change protocol.
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 them to take immediate action to mitigate the risk and prevent further damage.
Uploading Findings from External Security Tools
Xygeni prioritization and response can also be used with security findings reported by other (open-source and commercial) third-party security tools.
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.
In your CI/CD pipelines you may have a step where another 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 accommodates findings from Xygeni scans and your preferred third-party tool, as long as its output format is supported.
Last updated