# Welcome to Xygeni ## Secure your Software Development and Delivery Enhance your **Application Security Posture Management** (ASPM) through comprehensive risk assessment, strategic prioritization, and protection against attacks and malware infection throughout your Software Supply Chain. ### Start using Xygeni {% hint style="info" %} Please, follow our [**Getting Started Guide**](/getting-started) for an easy onboarding process to the Xygeni platform. {% endhint %}
Quick start with your code repo

Connect your SCM to Xygeni and start scanning		Quick start with Xygeni CLI

Scan with Xygeni CLI locally in command line
### Introduction to Xygeni
Xygeni Products Overview

Quick view of the available Xygeni products		How Xygeni works

Understand the architecture behind Xygeni and how it works

Xygeni Web UI

Learn about how to use the Xygeni Web User Interface

Xygeni Scanners

Learn about Xygeni CLI and the various scans types

Integrating Xygeni into your Workflow

Integrate Xygeni into your own CI/CD pipelines

Security Gates with Xygeni

Secure your build process by setting Security Gates		Generate a SBOM

Generate SBOMs in the format you prefer (SPDX, CyclonDX)		Supported Integrations

Integrate Xygeni within your own SDLC processes and tools
### Xygeni Configuration and Administration
Platform Administration

Manage and configure your Xygeni platform
Xygeni REST API

Leverage Xygeni functionality with the Xygeni REST API
### Xygeni Distributions
Xygeni On-Premise

Deploy Xygeni platform within your own infrastructure
# Getting Started To explore Xygeni's features effortlessly as a new user, follow these simple steps {% embed url="" %} {% hint style="info" %} Please ensure that you have an active Xygeni account before proceeding. {% endhint %} ### **Initiate a scan using the Xygeni Web UI** To scan a repository located in your preferred SCM, the **easiest method** is to do it directly **from the Xygeni Web UI**. {% hint style="info" %} Please go to [Quick Start with your code repository](/getting-started/quick-start-with-your-code-repository) and follow the suggested steps. {% endhint %} ### Execute a scan using Xygeni CLI You can also follow an alternative approach by using the Xygeni CLI, although it is not as direct as using the Web UI. The Scanner CLI allows you to scan a local directory or a remote repo directly from a command shell or a shell script. {% hint style="info" %} Please go to [Quick Start with Xygeni CLI](/getting-started/quick-start-with-xygeni-cli) and follow the suggested steps. {% endhint %} ### View a demonstration project rather than perform a real scan If you only want to view **preloaded results** instead of scanning a real project, you can import **pre-built results** of a **demo project** that will show you examples of issues (this option will not scan any source code). {% hint style="info" %} Visit here to [Quick start with a preloaded project](/getting-started/quick-start-with-preloaded-project). {% endhint %} # Create a Free Account You must have an active **Xygeni Account** to use Xygeni's features. ### Create a Free account {% hint style="info" %} You can either create a **Free account** or sign up for a **Xygeni pricing plan**; Visit [Xygeni Pricing Plans](https://xygeni.io/pricing/) for more details. {% endhint %} A comprehensive set of features is available for evaluation at no cost and with no time limit. The registration process does not require payment information, and no subscription will be activated unless explicitly requested. * Go to * Choose your preferred **signup method**.
* Follow the prompts to create a new account. You should now have a free Xygeni account and can log in at any time at[ ](https://in.xygeni.io/auth/login)[https://in.xygeni.io](https://in.xygeni.io/) # Quick start with your code repository Use **Managed Scans** to connect a repository and run scans from Xygeni. Xygeni configures the required automation for you. You can start with GitHub or GitLab. ### Open Managed Scans Go to **Home → Managed Scans**.
Click **Add Repository**.
### Connect a GitHub repository Select **GitHub** to install the **Xygeni GitHub Application**. Choose the installation scope. You can install it for a user or an organization.
Choose whether Xygeni can access all repositories or only selected repositories.
Click **Install & Authorize**. Xygeni adds the integration and lists the repositories it can access.
Click **Scan Now** for the repository you want to scan.
Xygeni starts a GitHub workflow for that scan.
After the scan finishes, results appear in the [Dashboard](/introduction-to-xygeni/xygeni-web-ui-overview/dashboard). The project name matches the repository name. You can also enable notifications. See [Notifications](/xygeni-administration/platform-administration/notifications). ### Connect a GitLab repository #### 1. Create the integration 1. Go to **Managed Scans**. 2. Click **Add Repository**. 3. Select **GitLab**. 4. Enter a Personal Access Token with these scopes: * `api` * `read_repository` * `write_repository` 5. Select the group you want to onboard. 6. Click **Configure**. #### 2. Let Xygeni prepare the pipeline Click **Scan Now** for the repository you want to scan. Xygeni configures the repository based on the default branch settings: * If the default branch is not protected, Xygeni commits the pipeline files directly. * If the default branch is protected, Xygeni creates a setup merge request. #### 3. Review the setup merge request for protected branches If GitLab creates a setup merge request, review and merge it before the first scan runs. 1. Open the setup merge request in GitLab. 2. Review the new files: * `.xygeni-scan-ci.yml` * `.xygeni-scan-now-ci.yml` 3. Review the new `include` block in `.gitlab-ci.yml`: ```yaml include: - local: '.xygeni-scan-ci.yml' - local: '.xygeni-scan-now-ci.yml' rules: - if: $XYGENI_SCAN_NOW == 'true' ``` 4. Confirm that `XYGENI_TOKEN` exists under **Settings → CI/CD → Variables**. 5. Approve the merge request if your project requires approvals. 6. Merge the setup merge request. #### 4. Run the first scan When the repository status changes to **Ready**, click **Scan Now** again. ### Run scans Managed Scans supports three scan modes for connected repositories. #### Run a scan now 1. Open **Managed Scans**. 2. Find the repository. 3. Click **Scan Now**. Xygeni triggers a pipeline on the default branch. Results appear in the dashboard a few minutes later. #### Schedule a daily scan 1. Open **Managed Scans**. 2. Find the repository. 3. Click **Scheduled Scan**. 4. Select the daily run time. 5. Save the schedule. Xygeni runs the scan automatically at the selected time. #### Scan on merge requests or pull requests 1. Open **Managed Scans**. 2. Find the repository. 3. Click **Scan on MR/PR**. Xygeni runs a scan for new or updated merge requests or pull requests that target the default branch. {% hint style="info" %} For more details and additional options, see [Manage Scans](/xygeni-products/scan-management/managed-scans). {% endhint %} # Quick start with Xygeni GUI Xygeni GUI app is a graphical wrapper for the Xygeni CLI. It is used to run a basic initial scan and directly access the scan results. If the Xygeni CLI is not already installed on your system (if it is not configured as a command in the PATH), the Xygeni GUI will download it to your local environment (usually $HOME/.xygeni). This eliminates the need to manually download the scanner to use the Xygeni GUI. Xygeni GUI does not include all the features of the Xygeni CLI. It is used to launch a scan by simply selecting the location of the repository or local directory to analyze, the name, and the scanners you want to run. You can follow the steps below for a quick start guide to using the Xygeni GUI: 1. [Install the Xygeni GUI](#id-1.-how-to-install) 2. [Fetch your Xygeni API token](#fetch_your_xygeni_account_credentials_or_api_token) 3. [Introduce the token in the Xygeni Token textfield](#fetch_your_xygeni_account_credentials_or_api_token-1) 4. [Select a local directory and application name](#id-4.-select-a-local-directory-and-application-name) 5. [Run the scan](#id-5.-run-the-scan) 6. [Open the results](#id-6.-open-the-results) ### 1. How to install The following software is required for the Xygeni scanner to work properly {% tabs %} {% tab title="Linux" %} * Download the Xygeni Local Scanner compressed file from [here](https://get.xygeni.io/latest/scanner/xgard/XygeniLocalScanner-v1.0.0.tar.gz). * Decompress the file * Give the "execute.sh" file execution rights * Run the execut.sh file {% endtab %} {% tab title="Windows" %} * Download the Xygeni Local Scanner msi file from [here](https://get.xygeni.io/latest/scanner/xgard/XygeniLocalScanner-v1.0.0.msi). * Execute the "XygeniLocalScanner.msi" file * Customize the installation according to your preferences * Go to the Search bar and search "XygeniLocalScanner" * Open the application {% endtab %} {% endtabs %} {% hint style="info" %} For more information about the different screens go [here](/xygeni-scanner-cli/xygeni-gui-overview). {% endhint %} ### 2. Fetch your Xygeni API token {% hint style="info" %} Active Xygeni account credentials are mandatory to run the script, so make sure you’ve signed up first! Visit [Create a Free Trial account](/getting-started/create-a-free-trial-account) or [Log in to Xygeni](/getting-started/log-in-to-xygeni) {% endhint %} Go your [security pannel](https://in.xygeni.io/dashboard/settings/security) and navigate to Organization/Personal Tokens:
Create a new token. The difference betweeen Organization tokens and Personal tokens is who can see and revoke those tokens. Select either one and generate a new token.
In order to run scans, the only permission that is needed is the "Upload scan results" permission. However, if you want to use the same token with the REST API, you’ll need to grant it additional permissions. ### 3. Introduce the token in the Xygeni Token textfield Paste or write the token that was fetched on the last step on the Xygeni Token text field. You can use the Eye icon to see the value of the written text.
If the token is valid, a green glow will appear. ### 4. Select a local directory and application name
Introduce the path to a directory to be scanned. You can do this using the folder button, which will open the system's directory selector. If the introduced value is not a valid directory, the textfield will have a red glow. Optionally, you can specify a name for the project to be scanned; otherwise, the name of the entered folder will be used. ### 5. Run the scan Press the launch scan button to run the scanner.
### 6. Open the results When the scan is complete, the results button will become active. Pressing it will take you to the Dashboard results screen.
# Quick start with Xygeni CLI A **Scan** is the action performed by the **Xygeni Scanner** to find security issues in your project. If you are planning to use the local CLI for a quick scan to validate how everything works, an easier way to do a quick installation and scaner could be done with the GUI wrapper following instructions at [Quick start with Xygeni GUI](/getting-started/quick-start-with-xygeni-gui) If you still want to deploy the CLI for full control from your workstation, you can follow the steps below: 1. [Install the Scanner CLI](#id-1.-install-the-scanner-cli) 2. [Fetch your Xygeni credentials](#fetch_your_xygeni_account_credentials_or_api_token) 3. [Set the XYGENI\_TOKEN Variable](#id-3.-set-xygeni_token-environment-variable) 4. [(Recommended) Add the scanner folder to path](#id-3.-set-xygeni_token-environment-variable) 5. [Run your first scan](#id-5.-run-your-first-scan) 6. [View the scan results](#id-6.-view-scan-results) ## Xygeni CLI ### 1. Install the Scanner CLI {% hint style="info" %} Please see [Xygeni CLI Prerequisites](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-prerequisites) before installing. {% endhint %} #### Download the Scanner Run the one of the following which better matches your preferences: {% tabs %} {% tab title="mac/Linux" %} ``` curl -sLO https://get.xygeni.io/latest/scanner/xygeni-release.zip ``` {% endtab %} {% tab title="Windows" %} ``` iwr https://get.xygeni.io/latest/scanner/xygeni-release.zip ``` {% endtab %} {% endtabs %} Or go to [https://get.xygeni.io](https://get.xygeni.io/) and dowload it manually. #### Verify the integrity of the script Xygeni publishes a SHA-256 checksum of published components in the [xygeni/xygeni GitHub repository](https://github.com/xygeni/xygeni#current-checksums), so you may verify the integrity of a downloaded artifact. {% hint style="info" %} This GitHub repository website is hosted in a completely different platform from the download site. Hackers need to compromise two different sites to keep tampered components, like the scanner or the installation script, undetected by the checksum verification. {% endhint %} To ensure that the downloaded installation script checksum matches the checksum published in Xygeni repository, meaning that probably it was not tampered with: {% tabs %} {% tab title="mac/Linux" %} ```shell echo "$(curl -s https://raw.githubusercontent.com/xygeni/xygeni/main/checksum/latest/xygeni-release.zip.sha256) xygeni-release.zip" | sha256sum --check ``` If under macOS, as `sha256sum` is probably not installed in your host, you may: 1. [read this](https://unix.stackexchange.com/questions/426837/no-sha256sum-in-macos) to install it, 2. or use `shasum -a 256` instead or `sha256sum` if the `shasum` command is installed, ```shell echo "$(curl -s https://raw.githubusercontent.com/xygeni/xygeni/main/checksum/latest/xygeni-release.zip.sha256) xygeni-release.zip" | sha256 -a 256 --check ``` 3. or use `openssl` to compute the SHA-256 checksum of the installation script and compare it with the published checksum. {% endtab %} {% tab title="Windows" %} ``` (Get-FileHash '.\xygeni-release.zip' -Algorithm SHA256).Hash -eq ` (iwr https://raw.githubusercontent.com/xygeni/xygeni/main/checksum/latest/xygeni-release.zip.sha256) ``` {% endtab %} {% endtabs %} ### Unzip the scanner Unzip the Xygeni Scanner zip that you have just downloaded to a new folder. {% tabs %} {% tab title="mac/Linux" %} {% hint style="info" %} If unzip command is not available you can use: ``` sudo apt install unzip ``` {% endhint %} ``` unzip xygeni-release.zip -d /destination/path ``` {% endtab %} {% tab title="Windows" %} Open a Windows PowerShell cmd and use the following command: ``` Expand-Archive -Path "C:\path\to\xygeni-release.zip" -DestinationPath "C:\Destination\Path" ``` {% endtab %} {% endtabs %} ### 2. Fetch your Xygeni API token {% hint style="info" %} Active Xygeni account credentials are mandatory to run the script, so make sure you’ve signed up first! Visit [Create a Free Trial account](/getting-started/create-a-free-trial-account) or [Log in to Xygeni](/getting-started/log-in-to-xygeni) {% endhint %} Go your [profile pannel](https://in.xygeni.io/dashboard/configuration-panel/profile) and navigate to Organization/Personal Tokens:
Create a new token. The difference betweeen Organization tokens and Personal tokens is who can see and revoke those tokens. Select either one and generate a new token.
In order to run scans, the only permission that is needed is the "Upload scan results" permission. However, if you want to use the same token with the REST API, you’ll need to grant it additional permissions. ### 3. Set XYGENI\_TOKEN environment variable In order to run scans, a new environment variable must be set, the name of this variable must be "XYGENI\_TOKEN" and it content has to be the token that was created in the previous step. {% tabs %} {% tab title="mac/Linux" %} ``` nano ~/.bashrc ``` Add this line at the end of the file: ``` export XYGENI_TOKEN="" ``` Apply the changes: ``` source ~/.bashrc ``` {% endtab %} {% tab title="Windows" %} ``` setx XYGENI_TOKEN "" ``` {% endtab %} {% endtabs %} {% hint style="info" %} This will create the XYGENI\_TOKEN environment variable for the current user. {% endhint %} ### 4. (Recommended) Add the scanner folder to path In order to execute the Xygeni application as another command, the Xygeni Scanner folder must be added to the path. {% hint style="info" %} This step is optional but highly recommended to facilitate future scans. {% endhint %} {% tabs %} {% tab title="mac/Linux" %} ``` nano ~/.bashrc ``` Add this line at the end of the file: ``` export PATH="$PATH:/Path/To/Scanner" ``` Apply the changes: ``` source ~/.bashrc ``` {% endtab %} {% tab title="Windows" %} ``` setx PATH "%PATH%;C:\Path\to\Scanner" ``` {% endtab %} {% endtabs %} {% hint style="info" %} This will modify the Current User Path. {% endhint %} ### 5. Run your first scan To begin, ensure that you have a file system folder containing your project content. This folder may be a clone of your repository or simply a directory housing the source code for your project. Navigate to your project directory, with the command `cd /my/project`. Once there, initiate a scan by running `xygeni scan`. All vulnerabilities identified are listed, including their path and fix guidance. ```bash $ cd /my/project $ xygeni scan ``` You can also use these commands below for other cases: ```bash # Assuming that $XYGENI_HOME in path or xygeni shortcut set # Scan a directory $ xygeni scan -n --dir # Scan a repository $ xygeni scan --repository # Scan a container image $ xygeni scan --image [--image-platform ] # You may add --no-upload to the scan command if you want to view # the results before uploading to Xygeni platform. ``` {% hint style="info" %} IMPORTANT: In case you want the scanner performs checks against your **repository** and **organization** (See [CI/CD Misconfigurations Detection](/xygeni-products/software-supply-chain-security-sscs#misconfigurations_detection)), ensure that you provide your SCM and/or CI/ CD systems tokens to the scanner. Usually, the preferred option is to **pass the token in an environment variable** (like **`GITHUB_TOKEN`** or **`GITLAB_TOKEN`**). See [SCM and CI/ CD tokens](/xygeni-scanner-cli/xygeni-cli-overview/scm-ci-cd-and-container-registry-tokens) to know more about this topic. {% endhint %} {% hint style="info" %} See [Xygeni Scanner Reference](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-scanner-reference) for the full scanner command-line reference. {% endhint %} ### 6. View scan results After the scan is done, log into the [Dashboard](/introduction-to-xygeni/xygeni-web-ui-overview/dashboard) and navigate to the **Governance tab** to access the **Security Posture Summary** screen.
{% hint style="info" %} Go to [Xygeni Web UI](/introduction-to-xygeni/xygeni-web-ui-overview) for a guide to browse the dashboard. {% endhint %} # Quick start with a preloaded project After signing up, you will be presented with three options. The "**Try out a Demo Project**" option lets you explore a demo project with preloaded data, eliminating the need to scan a real repository.
Select "**Try out a Demo Project**" to initiate the background process to load the demo project.
Click on the *Close* button and you will see that a new project has been created (named "**DemoProject**") with preloaded data. You can freely browse for any page to see funnel, dashboards, risks, etc.
# Quick start with Xygeni DAST ## The short version From 6.14.0, two commands take you from nothing to a configured scan: {% tabs %} {% tab title="Linux / macOS" %} ```bash curl -fsSL https://get.xygeni.io/latest/dast/get-dast.sh | sh # install, signature-verified xy-dast interactive # answer a few questions ``` {% endtab %} {% tab title="Windows" %} ```powershell iwr -useb https://get.xygeni.io/latest/dast/get-dast.ps1 | iex xy-dast interactive ``` {% endtab %} {% endtabs %} The installer finds Docker, pulls the scanner image, verifies its signature and pins the wrapper to the digest it verified. `xy-dast interactive` then interviews you about the target and writes a scan profile, a command line, or both — asking only the questions that apply, and asking for the *name* of an environment variable rather than for any password or token. Later, `xy-dast update` pulls, verifies and re-pins to the newest image, keeping the wrapper and the image in step. The rest of this page is the manual route, which works with any released image and in environments the installer cannot reach from. ## **Requirements** * **Docker Engine 20.10+** (or Docker Desktop) with Compose v2 — i.e. the `docker compose ...` subcommand. The legacy `docker-compose` v1 binary is not supported, and Podman is not a substitute: the wrapper drives `docker compose`, which Podman does not provide. * A directory on your `PATH` to drop the wrapper into. This guide uses `~/.local/bin` (Linux/macOS) and `%USERPROFILE%\.local\bin` (Windows). * The XYGENI\_TOKEN environment variable must exist and contain a valid token. #### Step 1 — Create the install directory and ensure it is on your `PATH` This is the most common source of "command not found: xy-dast" issues. The install directory **must exist before the install command** (Docker creates it as `root` if it does not, which then fails to write), and it **must be on your `PATH`** for the short `xy-dast` command to work. {% tabs %} {% tab title="Linux" %} ```bash # 1. Create the directory (idempotent) mkdir -p ~/.local/bin # 2. Make sure it is on PATH for the current shell case ":$PATH:" in *":$HOME/.local/bin:"*) ;; *) export PATH="$HOME/.local/bin:$PATH" ;; esac # 3. Persist for future shells (only needed once per shell rc) grep -q '\.local/bin' ~/.bashrc 2>/dev/null \ || echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc # zsh users: replace ~/.bashrc with ~/.zshrc ``` Verify: ```bash echo "$PATH" | tr ':' '\n' | grep -F "$HOME/.local/bin" # should print the path ``` {% endtab %} {% tab title="macOS" %} ```bash # 1. Create the directory mkdir -p ~/.local/bin # 2. Add to PATH for the current shell export PATH="$HOME/.local/bin:$PATH" # 3. Persist for future shells (zsh is the default since macOS Catalina) grep -q '\.local/bin' ~/.zshrc 2>/dev/null \ || echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc # bash users: replace ~/.zshrc with ~/.bash_profile ``` Verify: ```bash echo "$PATH" | tr ':' '\n' | grep -F "$HOME/.local/bin" ``` {% endtab %} {% tab title="Windows (PowerShell)" %} ```powershell # 1. Create the directory New-Item -ItemType Directory -Force -Path "$HOME\.local\bin" | Out-Null # 2. Add to PATH for the current shell $env:PATH = "$HOME\.local\bin;$env:PATH" # 3. Persist for future shells (User scope, no admin needed) $userPath = [Environment]::GetEnvironmentVariable('PATH', 'User') if ($userPath -notlike "*$HOME\.local\bin*") { [Environment]::SetEnvironmentVariable('PATH', "$HOME\.local\bin;$userPath", 'User') } ``` Verify (open a **new** PowerShell window after persisting): ```powershell $env:PATH -split ';' | Select-String '\.local\\bin' ``` {% hint style="info" %} The Windows wrapper is a PowerShell script (`xy-dast.ps1`) signed with an Authenticode certificate. If your execution policy blocks running scripts, run `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` once. {% endhint %} {% endtab %} {% endtabs %} #### Step 2 — Install the wrapper from the Docker image The image's `install` subcommand drops two files into the mounted directory: the `xy-dast` wrapper script itself and a sidecar `xy-dast-compose.yml` that holds the image reference, environment forwarding, and runtime parameters. {% tabs %} {% tab title="Linux / macOS" %} ```bash docker run --rm -v ~/.local/bin:/mnt/install xygeni/xy-dast install ``` {% endtab %} {% tab title="Windows (PowerShell)" %} ```powershell docker run --rm -v "${HOME}\.local\bin:/mnt/install" xygeni/xy-dast install --powershell ``` `--powershell` produces the signed `.ps1` wrapper (and matching sidecar) instead of the bash one. {% endtab %} {% endtabs %} Verify: ```bash xy-dast --version ``` If you get `command not found` (or `not recognized as ... cmdlet`), revisit Step 1 — the directory is almost certainly not on your `PATH` yet. ### Step 3 — Launch a web application For the purposes of this guide, Juice Shop can be substituted with any web application you would like to test. ``` docker pull bkimminich/juice-shop docker run --rm -p 3000:3000 --name juice-shop bkimminich/juice-shop ``` ### Quick Start Scan a web application: ```bash xy-dast scan -n "MyApp" --branch "origin/main" -u https://example.com ``` Results are uploaded to the Xygeni platform by default. To save a local report instead, use `-o`: ```bash xy-dast scan -n "MyApp" --branch "Origin/main" -u https://example.com -o report.json ``` If you have launched juice shop as mentioned on Step 3, you can use: ```bash xy-dast scan -n "Juice-Shop" --branch "Origin/main" -u http://localhost:3000 -o report.json ``` For more information about the DAST scanner please see: [DAST Scanner](/xygeni-products/dast-security/dast-scanner). # Log in to Xygeni Go to our **Login page**: You can login either by using **your Xygeni identifier** or using your preferred **Authentication system** (go to [Xygeni Single-Sign-On (SSO) Authentication](/xygeni-administration/platform-administration/integrations/xygeni-single-sign-on-sso-authentication) to learn how to integrate authentication through SAML )
{% hint style="info" %} If you use **Xygeni authentication**, you will need to provide a password. In case you are new to Xygeni, please go to [First Login to Xygeni](#first-login-to-xygeni). If you use **SSO** to authenticate, your Xygeni account will be created automatically the first time to access Xygeni and no password will be required. The exception is the "owner" of the Xygeni account. For the owner the possibility to authenticate locally (i.e. through password) will always be present. {% endhint %} ## First Login to Xygeni * As the first user in your Xygeni organization, you are designated as the main administrator (owner), granting you full permissions to create new user accounts, edit projects, and set up policies. Upon creating the Xygeni account, you will receive a notification email to set up a new password. * As a new user in an existing Xygeni Organization, you will receive an email notification to set your password
Clicking on **Set a new password** button will redirect you to Reset Password dialog.
Upon successful password creation, the application will launch, starting you off on the **Home** page.
{% hint style="info" %} If you are the first user in your Xygeni Organization, the dashboard will be empty because no scans have been executed. To understand how to start scanning, please refer to the below options: * [Quick start with your code repository](/getting-started/quick-start-with-your-code-repository) * [Quick start with Xygeni CLI](/getting-started/quick-start-with-xygeni-cli) * [Quick start with preloaded project](/getting-started/quick-start-with-preloaded-project) {% endhint %} # Subscribe to Xygeni ## Subscribe to Xygeni To upgrade from the Free tier to a paid plan, go to the Subscription section. Please navigate to **Settings** >> **Subscription** {% hint style="info" %} You can check the complete information of Subscription Section in Settings block in the following page of the documentation: [Subscription](/xygeni-administration/platform-administration/subscription) {% endhint %} ## Access to Subsciption section Open the **Settings** menu and select **Subscription**. The subsequent screen with appear:
## Subscribe Click the **Upgrade plan** to commence the selection of plans and determine the quantity of daily scans. Visit the [pricing page](https://xygeni.io/pricing/) for detailed information on plans and pricing.
Once you've chosen your subscription preferences, you'll be directed to a secure external payment platform. Xygeni does not store or handle any payment details or personal information related to your transactions.
Your license will be updated upon successful payment confirmation, allowing you to utilize the Xygeni platform. # Introduction to Xygeni
Xygeni ProductsHow Xygeni worksXygeni Web UIScannersScanner CLI Overview
Scanner Docker ImageIntegrate Xygeni into your workflowsSecurity Gates (GuardRails)SBOM GenerationReports
Supported IntegrationsCustomizing Xygeni
# Key Concepts The following sections describe the key elements within the Xygeni Platform. 1. [Projects in Xygeni](/introduction-to-xygeni/key-concepts/projects-in-xygeni) 2. [Project baseline](/introduction-to-xygeni/key-concepts/project-baseline) 3. [Detected Issues](/introduction-to-xygeni/key-concepts/detected-issues) 4. [Remediation Actions](/introduction-to-xygeni/key-concepts/remediation-actions) 5. [Policies](/introduction-to-xygeni/key-concepts/policies) 6. [Risk Level](/introduction-to-xygeni/key-concepts/risk-level) 7. [SDLC Inventory](/introduction-to-xygeni/key-concepts/sdlc-inventory) 8. [Compliance Standards](/introduction-to-xygeni/key-concepts/standards-compliance) 9. [GuardRails](/introduction-to-xygeni/key-concepts/guardrails) # Projects in Xygeni ### Projects A **project** is the target for the scans. It can be any *unit of software* that can be analyzed independently, with any granularity. It could correspond with an application, module, service, microservice, container image, library, component…​ A project typically is under version control, and it consists of a set of source files, often grouped as a *repository* in a Source Code Management (SCM) System. {% hint style="info" %} For more information, read [Projects in Xygeni](/xygeni-administration/platform-administration/projects-management). {% endhint %} # Project Baseline ### Project's Baseline Every project in Xygeni has a **Baseline**. A Baseline is a specific analysis used as a reference point to compare with future scans and track how issues evolve over time. By default, the baseline is created from the project’s first scan, but you can also set any subsequent scan as the new baseline. ### Set a new baseline Go to [Scan History](/xygeni-products/scan-management/scan-history) for further information on how to mark a scan as the project baseline. # Detected Issues The [Xygeni Scanner](/xygeni-scanner-cli/xygeni-cli-overview) runs on your premises to analyze DevOps tools and software projects, including source code and configurations. The scan findings or **security issues** represent misconfigurations, flaws or anomalies that increase the risk of a successful software supply chain attack. Each issue could be found by a **detector**, which can be thought of as the unit of analysis. Running a set of detectors over the target software project is a **scan**. Scans for each issue type can be analyzed separately or in a single run. Below are the **types of issues** encountered in Xygeni: ### Vulnerable Dependencies A dependency is vulnerable when some programming defect or flaw can be exploited with malicious intent. Do you remember Log4J ? That dependency is not malicious, just vulnerable. Someone found a trick to exploit a flaw in the source code of the dependency that could be used to gain improper access to some resource. Publicly known vulnerabilities are published as CVEs. Xygeni is able to scan your dependencies to find CVEs from public sources ([NIST's NVD](https://nvd.nist.gov/vuln), [GitHub Advisory Database](https://github.com/advisories) and [OSV](https://osv.dev/list) among others ) {% hint style="info" %} See [Open Source Security (OSS)](/xygeni-products/open-source-security-oss), [Dependency Scanner](/xygeni-products/open-source-security-oss/dependency-scanner) and [Dependency Analyzers](/xygeni-products/open-source-security-oss/dependency-scanner/dependency-analyzers) for more details. {% endhint %} ### Suspect Dependencies A **Suspect Dependency** models a dependencies issue, a defect in project dependencies that may open the door to software supply-chain attacks. A classic example is having an indirect dependency which was compromised by an actor to inject malware in the software that depends on that component. The actor may inject malicious code and indirectly attack the organizations that use the affected version(s) of the malware component. Attacks on the Software Supply Chain often use techniques that exploit flaws in components referenced in software and dependency descriptors, package manager configurations, and other sources. Notable examples such as [**Dependency Confusion**](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) or **Typosquatting**. {% hint style="info" %} See [Open Source Security (OSS)](/xygeni-products/open-source-security-oss) and [Suspect Dependencies Scanner](/xygeni-products/open-source-security-oss/suspect-dependencies-scanner) for more details. {% endhint %} ### CI/CD Misconfigurations A CI/CD misconfiguration is any flaw in the configuration of a tool that could allow bad actors to perform unintended operations affecting the software pipeline. There are many systems in the software pipeline that could have a misconfiguration: management systems, build tools, package managers, registries, compilers, testing frameworks, IDEs, CI/CD systems, provisioning tools, container frameworks and orchestration tools…​ Examples of misconfigurations are: * Unprotected delivery code branches. * Lack of code reviews. * Poor access control practices like the lack of multi-factor authentication. * Publicly accessible storage buckets in the cloud infrastructure. * Flaws in CI pipelines, critical data not encrypted at rest. * Weak password policies and non-rotated encryption keys. And many more... {% hint style="info" %} See [Software Supply-Chain Security (SSCS)](/xygeni-products/software-supply-chain-security-sscs) and [CI/CD Scanner](/xygeni-products/software-supply-chain-security-sscs/ci-cd-scanner) for further information. {% endhint %} ### Malicious Code Evidence When a software supply chain attack occurs, the bad actors may infiltrate malicious code and unintended behaviour, open backdoors and change the software in a way that could be used as a vector for malware delivery. **Malicious Code Evidence** encompasses indicators of malicious software (malware) identified through **static analysis** of the target software. The integration of automated analysis tools for detecting potential supply chain breaches enhances traditional software security assessments. As malicious actors employ **obfuscation techniques** to conceal their modifications from manual reviews, these techniques can also provide further evidence of illicit activities. From the evidence collected, a `maliciousness score` for the software under analysis is calculated. With enough evidence accumulated, the analyzed software could be classified as potentially malicious. The **Malware Scanner** is a tool that checks the files of the software project under analysis, and reports "evidence" according to malware detectors currently active for the policy assigned to the project. Detected evidence could be uploaded to the Xygeni platform for consolidation and for enabling response actions. {% hint style="info" %} See [Code Security (CS)](/xygeni-products/code-security-cs) and [Malware Scanner](/xygeni-products/code-security-cs/malware-scanner) for further information. {% endhint %} ### Hardcoded Secrets A **secret** in this context is any piece of information that allows an actor to gain access to a sensitive resource. Typical secrets are authentication credentials like usernames and passwords, API keys / tokens, cryptographic keys (symmetric or private), pass phrases, and many more. Unauthorized access to sensitive information has led to significant disruptions in the software supply chain. Having hard-coded secrets in source code or configurations, particularly when under source control, is an invitation for bad actors to gain access to the organization’s sensitive resources. Other types of information like personal or private information, business sensitive data, industrial footprints, etc... could be included in this category. {% hint style="info" %} See [Secrets Security](/xygeni-products/secrets-security) and [Secrets Scanner](/xygeni-products/secrets-security/secrets-scanner) for further information. {% endhint %} ### IaC Flaws ***Infrastructure-as-Code*** or **IaC** is a method to provision and manage IT/Cloud infrastructure through the use of source code (IaC templates) under version control, rather than through operating procedures and manual processes. An **IaC Flaw** represents a "flaw" or "defect" (a non-compliance) for a certain policy, found in an Infrastructure-as-Code (IaC) template. {% hint style="info" %} See [IaC Security](/xygeni-products/iac-security) and [IaC Scanner](/xygeni-products/iac-security/iac-scanner) for further information. {% endhint %} ### Compliance failures A **Software Supply Chain Standard** / **Guideline** is represented by a Xygeni **Standard**, which contains a list of Checkpoints. A **Checkpoint** is a requirement that the software must match. A checkpoint may belong to a category. Categories break down a standard into a hierarchy of different areas that represent the standard’s relevant parts. Each checkpoint could be *required* or *optional*. A **required checkpoint** is **mandatory** and must **pass** for the project to be compliant with the whole standard. An **optional checkpoint**, on the other hand, is evaluated but does not affect the global compliance status. Checkpoints have further metadata, like the *severity* (which is the impact of a non-compliant checkpoint on the risk for supply chain security), what is the ***explanation*** of the checked condition, and what *needs to be done* for attaining full compliance (**remediation**). When a standard’s compliance assessment is evaluated, a **compliance report** is generated, with each checkpoint result and a global compliance status. The **checkpoint result** models the result of the evaluation of a checkpoint over the project under analysis. The result has a *status* (pass, partial, fail, n/a or unknown) with the following meaning: * `ok` - The target project is compliant for the checkpoint. * `fail` - The target project is NOT compliant. * `partial` - The target project is partially (but not completely) compliant. * `n/a` - The checkpoint does not apply for the target project. * `unknown` - Checkpoint evaluation failed, result is unknown / inconclusive / uncertain. The result indicates a **compliance level** on a scale from 0 to 10, where 0 denotes non-compliance, 10 represents full compliance, and values from 1 to 9 signify varying degrees of compliance. The global compliance status is derived from the checkpoints evaluated, with this scheme: * Optional and n/a checkpoints do not influence the standard compliance status, they are ignored. * If no checkpoint was run, `N/A` is returned. * Otherwise, if at least one mandatory checkpoint is non-compliant or unknown, `FAIL` is returned. * Otherwise, if at least one mandatory checkpoint is only partially compliant, `PARTIAL` is returned. * Otherwise, if at least one mandatory checkpoint is compliant, `PASS` is returned. * If no mandatory checkpoint has a pass / partial / fail status, `N/A` is returned. The *global compliance level* is the weighted average (with weights based on severity) of the compliance level of *all* the checkpoints evaluated (required and optional), with the same 0 to 10 scale, indicating how far the current status is from full compliance for the target software project. {% hint style="info" %} See [Software Supply-Chain Security (SSCS)](/xygeni-products/software-supply-chain-security-sscs), [Compliance Scanner](/xygeni-products/compliance/compliance-scanner) and [Software Supply Chain Standards](https://docs.xygeni.io/xydocs/compliance/standards.html) for full documentation on the supported standards and their checkpoints. {% endhint %} ### Unusual Activity Events and Anomaly Detection **Unusual activity** events represent user actions in your tools or over critical files that are out of the typical pattern of actions for the project. The platform offers two main types of activity monitoring to detect and respond to potential security incidents or breaches: **Critical file modification** and **User suspect behavior**. #### Critical File Modification (Code Tampering Prevention) Xygeni provides vital capabilities to help organizations enforce security procedures and detect **unauthorized changes** on **files** marked as **critical**. Our platform detects any change potentially leading to Code Tampering in these files when a commit does not match the conditions that must be accomplished for the changes to be accepted. In such situations, the system launches an **alert** to notify the change on a subset of the project sources deemed as critical without following the prescribed change process. {% hint style="info" %} See [Anomaly Detection](/xygeni-products/anomaly-detection) and [Code Tampering Scanner](/xygeni-products/anomaly-detection/code-tampering-scanner) for further information. {% endhint %} #### Suspect Behavior (Anomaly Detection) Xygeni’s policies and audit enforce best practices in access controls, multi-factor authentication requirements and role-based permissions applications to limit user access to critical systems and data. Unusual activity detection performs continuous monitoring by collecting state changes from tools and logs and compiling usage patterns into a user behavior model. After that learning phase, it identifies anomalies in new operations as deviations from the 'normal' user behavior modeled. Live notifications for high-severity alerts are provided to the user, as this kind of flaw usually demands immediate action to mitigate the risk and prevent further damage. {% hint style="info" %} See [Anomaly Detection](/xygeni-products/anomaly-detection) and [Xygeni Sensors](/xygeni-products/anomaly-detection/xygeni-sensors) for further information. {% endhint %} # Remediation Actions ### **Steps to address a security incident or vulnerability** The documentation for each detector provides examples for addressing specific security issues, as well as recommended procedures for assessing the impact and resolving the issue. ### Remediation Actions Examples of **remediation actions** include revoking leaked secrets, modifying infrastructure playbooks or receipts and updating existing resources, hardening authentication or authorization settings for CI/CD tools, or fixing pipeline configurations. ### Automatic Remediation Xygeni provides mechanisms to **automatically remediate** certain kind of **issues**. {% hint style="info" %} Please, go to the below sections for further information on automatic remediation: * [Open Source auto remediation](/xygeni-products/open-source-security-oss/oss-auto-remediation) * [Secrets auto remediation](/xygeni-products/secrets-security/secrets-auto-remediation) {% endhint %} ### AI Triage Xygeni can also apply **AI-driven triage** to security findings to reduce alert fatigue. For each issue, AI Triage assigns a verdict (real vulnerability, likely false positive, or needs review) and, for confirmed vulnerabilities, a remediation urgency and remediation complexity. Triage can be run from the issue slide-out, as a batch action on a risks table, on demand from the CLI, or right after a scan with `--triage`. {% hint style="info" %} See [AI Triage](/xygeni-administration/platform-administration/projects-management/ai-triage) for further information. {% endhint %} ### Handling Actions in Xygeni Dashboard The [**Dashboard** ](/introduction-to-xygeni/xygeni-web-ui-overview)offers contextual remediation actions for each security issue or unusual activity alert. The common actions are: * `Manage Issue`: A basic handling workflow, for setting a **status**. * `Create ticket`: Opens a new **ticket** in the configured ticketing tool. Full information for the issue is rendered so the ticket can be created with minimal work. * `Open Pull Request` (PR): Opens a **pull request** in the configured **Source Control Manager**, with contextual information on the issue. Commits with changes in source / configuration files can be added to the branch, for automation, so after review the pull request can be approved for merging into the target branch. * `Disable Check`: **Deactivates** the detector that reported the issue, possible for all the policies including it. This action is only available when the user’s roles allows it. This is a quick way to remove detectors that do not apply for the organization, or that are creating issues that should be ignored systematically. * `See in Inventory`: Shows the **asset** where the **issue** was **located** in the [SDLC Inventory](/xygeni-products/application-security-posture-management-aspm/inventory), . * `Search Similar`: Opens a view with issues similar to the selected one. Similarity is typically by the specific issue type across all projects. This helps to focus on fixing all of them by applying the recommended fix steps. ### Internal Issue Management The Xygeni platform provides a basic handling workflow that helps to trace each issue. {% hint style="info" %} Please note that alternative handling might start by opening a ticket for the target issue or group of issues *in your ticketing tool of choice*, and using your incident handling workflow using the tool. In that case, you may leverage the provided "Create Ticket" action to open a new ticket in the external tool with the full issue information. {% endhint %} The `Status` field may take the following values: * `Open`: The initial status: The issue has not yet handled. * `Under review`: The issue is under investigation. * `Confirmed incident`: The issue is a confirmed security problem, and should be fixed. For unusual activity, additional states are available: * `Incident closed`: The problem was **corrected**, and any potentially harmful consequences related to the unusual activity were handled. * `Normal business`: Internally the issue will be "**muted**", applying to current issue and current scan. Only for security issues (secrets, misconfigurations, bad components and IaC flaws): * `Muted: False Positive` The issue is not legitimate. To report this as a bug, check "Create false positive ticket for Xygeni" to open a support ticket. * `Muted: Accept the risk`. The issue is acknowledged, but the risk is assumed instead of trying to fix the issue. * `Muted: Other`. When the issue needs to be silenced for other reasons. The remediation actions can be invoked from the **Remediation Actions** popup in the [Dashboard](/introduction-to-xygeni/xygeni-web-ui-overview). To change it for a given security issue, just open the issue and click on "**Change Status**" (see image below)
Then, a dialog will open where you can the change the status as well as provide any further additional information about the reason of the change.
Selecetion box to choose the issue status
To change the status of **several issues** (**bulk mode**) at once: First, select the checkbox on the left on each issue you want to modify. Then, under the '**Actions**' tab select the"Change Status" option. {% hint style="info" %} Please note, the '**Actions**' tab will only be active when at least a single issue has been selected. {% endhint %}
The change status option showing under the actions tab once an issue is selected
# Policies ### Policies A **policy** encompasses a comprehensive set of rules, procedures, checks, and processes designed to strengthen software infrastructure and mitigate the risk of supply chain attacks. Each policy outlines acceptable and unacceptable behaviors, specifies required detectors, and details the impact based on risk scoring A software project currently under analysis has an assigned policy, which varies in strictness according to the organization's criteria. The policy in effect is downloaded at scan time or when raw activity data is received from Xygeni sensors. The Xygeni platform provides a default policy, tailored to cover a common assessment of the software supply chain security for most organizations. {% hint style="info" %} Read more about [Policies in Xygeni](/xygeni-administration/platform-administration/policies). {% endhint %} # Risk Level ### Risk Level The **Risk Level** (RL) is a quantitative metric that assesses the current **exposure** to software supply chain attacks. It evaluates the ***security posture*** of the DevOps system based on scans conducted by the Xygeni platform. In the [Dashboard](/introduction-to-xygeni/xygeni-web-ui-overview#xygeni-web-ui), the **Risk Level** is displayed alongside its variation in relation to the current baseline of projects. The Risk Level is quantified on a scale from 0 to 100, with 100 indicating the highest level of risk. This measure is determined by the issues identified within a project. If no issues are detected, the Risk Level is rated as 0. The RL is qualified in three categories that make more evident how good or bad is the risk for the organization. Each category is encoded with a color following the "semaphore" scheme: * **Low**: RL between 0 and 33, green color. * **Moderate**: RL between 33 and 66, yellow color. * **High**: RL between 66 and 100, blood-red color. # SDLC Inventory Modern software complexity demands an equally sophisticated build and deployment infrastructure. Software is typically built and deployed in production environments using pipeline commands. A **build/deploy pipeline** is based on a set of automated processes and tools, involving source control, build tools, continuous integration, testing automation (unit, integration and regression testing), validation, reporting, and distribution. The build/deploy pipeline assets, known as **SDLC assets**, are automatically discovered in the Xygeni platform. This creates an **inventory of SDLC assets** for the pipelines used within an organization. An SDLC Asset may present misconfigurations, leaked secrets, and other security issues which could be abused in software supply chain attacks. Common assets are code repositories, dependency graphs, package managers, build files, security tools, CI/CD workflows or IaC templates and provisioning scripts, along with the infrastructure, tools and extensions (such as plugins) used in the build / deploy pipelines. Security issues and unusual activity events are mapped to the target SDLC assets. The Inventory allows to reveal unknown, misconfigured and vulnerable SDLC systems and infrastructure, and perform *impact analysis*: dependencies between assets may be exploited by attackers to propagate the attack payloads. {% hint style="info" %} Read more about [SDLC Inventory](/xygeni-products/application-security-posture-management-aspm/inventory). {% endhint %} # Compliance Standards Xygeni ensures your software aligns with various [Security Standards and Guidelines](/xygeni-products/compliance/compliance-scanner#standards) by running **automated compliance checks** on software projects and DevOps tools for compliance assessment, under standards and guidelines like ***OpenSSF Scorecard*** or ***CIS Software Supply Chain Security*** among others. Each *standard* is composed of a set of checkpoints that are evaluated against the project under analysis. A *checkpoint* is classified within a specific category and may be designated as mandatory or optional. The outcome indicates whether the project meets the standard, providing a compliance level assessment {% hint style="info" %} See [supported standards](/xygeni-products/compliance/compliance-scanner/supported-compliance-standards) for more information. {% endhint %} # GuardRails For pipelines or security policies that need **specific rules** or **exit codes**, complex conditions can be set using **guardrail expressions**. [Guardrails Gates](/xygeni-scanner-cli/xygeni-cli-overview/guardrails) allows users to configure and define the behavior of a Xygeni command under specific conditions or criteria, enabling a customizable and adaptable approach to managing failure scenarios. {% hint style="info" %} See [GuardRails Specification](/introduction-to-xygeni/guardrails) for further details. {% endhint %} # Xygeni Products **Xygeni** is a platform for improving the **Software Supply Chain Security posture** for organizations. The platform protects the integrity and security of your software ecosystem throughout the entire SDLC by providing the following **products**:
Application Security Posture Management (ASPM)

Unifying Risk Management from Code to Cloud delivering real-time visibility, prioritization, and remediation		Code Security (CS)

Malicious code can be injected into your application code by attackers infiltrating your systems or even by internal attackers.		Open Source Security (OSS)

Minimize Open-Source Risk and Keep your Application Safe From Malicious Packages		Software Supply-Chain Security (SSCS)

Optimize Your CI/CD Ecosystem for Robust Protection


Build Security

Enable continuous integrity, artifact verification, and attestation to prevent tampering without slowing your development process

Secrets Security

Keep Safe Your SDLC Detecting any kind of secret Avoiding committing new ones

IaC Security

Scale Cloud Security Identifying All Cloud Misconfigurations


Anomaly Detection

Prevent Malicious Activity Detecting Behavior-Based Risks
# How Xygeni works The Xygeni platform is a cloud-based service, accessible via REST API, that keeps findings and metadata from different sources. The [**Xygeni Scanner**](/xygeni-scanner-cli/xygeni-cli-overview)**,** runs in your internal network and asses your infrastructure for different types of vulnerabilities (Visit [here ](/xygeni-scanner-cli/xygeni-scanners)for further info on available scanners). Once the scan is done, you decide either to upload the results to the Xygeni servers (to see the results into the SaaS [Xygeni Dashboard](/introduction-to-xygeni/xygeni-web-ui-overview)) or keep the results locally for further processing. The **Xygeni platform** is represented by the chart below:
### Scanner Xygeni provides a command-line interface (CLI) for running the [**scanner**](/xygeni-scanner-cli/xygeni-cli-overview). The scanner can either run analysis commands separately, like detecting hardcoded secrets or misconfigurations, or run all the analyses at once. The [**scanner**](/xygeni-scanner-cli/xygeni-cli-overview) is java based and can be triggered directly from the [**command line**](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-operation-modes), from any [**batch program**](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-operation-modes) (Unix shell script, Windows batch, PowerShell script, etc.), from [**git hooks**](/xygeni-administration/platform-administration/integrations/git-hooks-with-xygeni) (pre-commit, pre-receive) or embedded into [**CI/CD pipelines**](/xygeni-administration/platform-administration/integrations/integrate-scanner-cli-into-ci-cd-systems). The scanner can be scan a [**file directory**](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-operation-modes/single-scan), a [**container image**](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-operation-modes/single-scan), a [**repository**](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-operation-modes/single-scan) or group of repositories and even a whole [**SCM organization**](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-operation-modes/organization-scan). {% hint style="info" %} The Xygeni Scanner can be automatically installed into you repositories or manually embedded into your pipelines. Please visit [Quick start with your code repository](/getting-started/quick-start-with-your-code-repository) and [Quick start with Xygeni CLI](/getting-started/quick-start-with-xygeni-cli) for further information. {% endhint %} Scanner findings can be inspected in the [***Dashboard***](/introduction-to-xygeni/xygeni-web-ui-overview), downloaded via Xygeni [**REST-API**](/xygeni-administration/rest-api), [**exported**](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-output-formats) in several formats (*csv, json*, etc...) and also create [***tickets***](/xygeni-administration/platform-administration/integrations/ticketing-systems) (Jira, GitHub) or opening [***messages***](/xygeni-administration/platform-administration/integrations/collaboration-and-communication-tools) (Slack) to notify your team about an issue. {% hint style="info" %} See [Xygeni Scanner](/xygeni-scanner-cli/xygeni-cli-overview) for further detail {% endhint %} ### Dashboard The [Dashboard](/introduction-to-xygeni/xygeni-web-ui-overview/dashboard) is the web user interface for showing the results of the scans. The dashboard provides a summary security posture and the breakdown of security issues at the global, group or project levels. Trends exploration, reporting, and platform administration, among other facilities are also displayed. {% hint style="info" %} See [Dashboard](/introduction-to-xygeni/xygeni-web-ui-overview/dashboard) for further detail {% endhint %} ### Rest API The [REST API](/xygeni-administration/rest-api) is the central element in the platform. All elements in the platform use the API as a backbone for reporting findings and receiving the processed information for integration into Xygeni tools, third-party plugins and integrations or any custom integration for organizations. {% hint style="info" %} See [REST API](/xygeni-administration/rest-api) for further detail {% endhint %} ### Integrations Xygeni provides integrations for running scans or uploading security issues, performing administrative operations, or exporting findings to communication and reporting tools. {% hint style="info" %} See [Integrating Xygeni into your Workflow](/introduction-to-xygeni/integrating-xygeni-into-your-workflow) and [Integrations ](/xygeni-administration/platform-administration/integrations)for further detail {% endhint %} ### Sensor Activity on public repositories is monitored by Xygeni so potential attacks could be detected early. Publishing new packages in popular public repositories is an example of an activity that is monitored by Xygeni. In addition, security advisories are ingressed for modelling new threats and malicious activity on the wild. Xygeni customers may receive alerts when a security issue may affect them. {% hint style="info" %} See [Xygeni Sensors](/xygeni-products/anomaly-detection/xygeni-sensors) and [Anomalus Activity](/xygeni-products/anomaly-detection/anomaly-detection-user-interface-guide) for further details. {% endhint %} # Xygeni Web UI Overview The Dashboard pages are composed of three elements: 1. The [Navigation Bar](#navigation-bar). 2. The [Projects Selector](#projects-selector). 3. The actual page content. ### Navigation Bar The Navigation Bar lets you access all the Xygeni functionalities: * [ASPM (Application Security Posture Management)](/xygeni-products/application-security-posture-management-aspm/aspm-user-interface-guide) * [Xygeni Products](/introduction-to-xygeni/xygeni-products) * [Malicious Packages DB](/xygeni-products/code-security-cs/cs-user-interface-guide/risks-sast/malicious-code), [SSCS Compliance](/xygeni-products/compliance), [Manage Scans](/xygeni-products/scan-management/managed-scans) and Scan History, * [Platform Administration and Settings](/xygeni-administration/platform-administration)
### Projects Selector The **Projects Selector** is a UI feature that allows you to select a project subset among the available ones in your Xygeni organization. The data on almost every UI page is associated with the selected project(s). The subset of projects can vary from a ***unique project*** to ***All projects***, passing for any defined subset. To use the Projects Selector click on it and you can either select an specific Project or a Project group.

You can also click on the filter icon to open the filter dialog.

# Projects Screen The **Projects Screen** is the first page you see when you login to This screen enables users to: * Review your organization's **total projects** count and their associated issues. * View the list of **projects scanned** in the organizacion. The projects are ordered by last scan although the user can order them by other criteria clicking in the columns header of the table. For each project, user can see the branch configured as default in Xygeni. * View the **Security Posture** for each project and a summary of issues by severity. Projects containing any type of malware are remarked with a special symbol (skull) * Access to most usual actions related to projects with one click. In this screen the Project Selector does not apply. The screen always shows all projects. The screen is shown and described in detail below:
### Statistics
This section shows the number of projects scanned in the organization. *Projects* is a sum both of repositories and images scanned. The following box shows a summary of total issues by severity in these projects. In the slide of detail of each project the user can check the stage of the SDLC in which Xygeni located potential malware and go to that section directly. Finally, there is a quick access to the [Managed Scans](/xygeni-products/scan-management/managed-scans) section, so the customer can configure integration with their SCM and launch the first scan of a project from there. Once the project is scanned and in the platform, the configuration of the project and management of scan can be done from this screen. ### Filtering the list of projects
The user can customize the list of projects shown in the table applying filters: * **Alert**: Filter by different types of alerts associated to the project as for example, containing malware. Only projects with that alert associated will be in the table below * **Project Type**: to select projects of type ´**Repository**´ or ´**Image Container**´ * **Name pattern**: The table shows only projects with the string in the **name** * **Branch pattern**: As the previous value, table only shows projects with the **default branch** containing the string in the filter * **Risk Level**: Table consider only projects in the **risk levels** selected. Below you have more details about the Risk Score calculation and values. * **Tags**: to show only projects with **tags** containing the string provided in this filter. When any filter criteria is selected, the option ´Clear All´ over the filter boxes changes to red to indicate that a filter is active. Clicking on that option will reset all filters to the default settings. #### Risk Score and Risk Level The Risk Score (or Risk Level, RL for short) is a quantitative metric that assesses the current **exposure** to software supply chain attacks. It evaluates the ***security posture*** of the DevOps system based on scans conducted by the Xygeni platform. In the [Dashboard](/introduction-to-xygeni/xygeni-web-ui-overview#xygeni-web-ui), the **Risk Level** is displayed alongside its variation in relation to the current baseline of projects. The Risk Level is quantified on a scale from 0 to 100, with 100 indicating the highest level of risk. This measure is determined by the issues identified within a project. If no issues are detected, the Risk Level is rated as 0. The RL is qualified in three categories that make more evident how good or bad is the risk for the organization. Each category is encoded with a color following the "semaphore" scheme: * **Low**: RL between 0 and 33, green color. * **Moderate**: RL between 33 and 66, yellow color. * **High**: RL between 66 and 100, blood-red color. See [All Risks](/xygeni-products/application-security-posture-management-aspm/all-risks) for further information and details. ### Projects Table
Several details are shown in the projects table: * **Last scan** **date**: The date of the latest scan for each project. * **Number of projects** from the total items **complying** with the criteria of the **filter**. * **Bulk actions** button: Only enabled once one or more projects are selected by clicking on their checkbox. Based on the projects selected, it will enable applicable operations. You can interact with the rows in different ways: * Clicking on the ***name*** of the project, goes to the [All Risks](/xygeni-products/application-security-posture-management-aspm/all-risks) section to review the projects associated risk. * Clicking on a **white space** of the row, a slide with details about the project will open. * Clicking on the '***scan now**'* button will launch an on-demand scan of the project. {% hint style="info" %} **Note**: If the project has been scanned using the CLI and it is not integrated with the managed scans system, this option will not be available and the button will be disabled. {% endhint %} At the end of each row, there is an icon with 3 dots that deploy a contextual menú for one-click access to different options.
Below you can find a quick description of the available actions: * **Scan Now**: Launch an on-demand scan if the project is integrated in the managed scan system. * **View Details**: Opens a slide with additional information. * **View All Issues**: Goes to the [All Risk](/xygeni-products/application-security-posture-management-aspm/all-risks) section. * **View Dependency Graph**: If the user has the inventory license, the system shows the graphical representation of the project representing all assets with their security posture and the relationship among them. * **Download SBOM**: Download the SBOM file in the selected format. * **Configure Project** **Settings**: Only available for **Root** and **Project Manager** users. It opens the slide for **configuration**. * **Go to Repository**: If detected, a new window opens to the project's repository in the corresponding Source Code Managemente system. ### The Project Details (Slide) Upon selecting the project's option to view details, a panel opens displaying multiple sections: The **Actions button** on the top right area shows the same actions that the menu in each row described above. #### Summary The summary view of a project shows meta information related to the project date, size and location. The second section shows information about the team and the most active users. Some statistics from the languages contained in the project are also available. {% hint style="info" %} **Important:** If the project contains malware a red notice will be shown on top. Detailed sections containing malware are available in the Findings section. {% endhint %}
#### Findings Second section of the slide shows a **detailed view** of the issues found in each stage of the SDLC. **Clicking** on the **name of the stage**, the user will go to the specific list of issues in the corresponding product. A special symbol (skull in this case) appears before the name of the section, if the system detects malware. Visiting the specific list of issues will show the malware as well as other vulnerabilities detected. {% hint style="info" %} Malware detection requires ´Premium´ or ´Enterprise´ plan to enable malware detection capabilities. {% endhint %} In the section **below the statistics**, you can directly see the first 5 issues of the category selected in the **selector**. For each issue, selecting the **´View Details´** option displays a panel with detailed information similar to that on the specific risks screen.
# Risk Level The Risk Level (or RL) has the following properties: * Issues with ***info*** and ***muted*** severity are **ignored** by the risk level calculation. They are just informative, and have no effect on the risk. * A **single critical issue** makes the RL fall in the **high risk range** *RL ≥ Ch*; similarly, a **single high severity issue** makes the RL fall in the **moderate risk range** *RL ≥ Cl*. In accordance with the principle that "*a chain is as strong as its weakest link*," this holds true for issues within a project. * **Monotonicity**: RL should increase when (non-info) issues are added. RL should NOT INCREASE when a single issue is removed. In other terms: if A1 and A2 are sets of issues with *A1 ⊆ A2,* then *RL(A1) ≤ RL(A2)*. Also, if an issue changes to a higher severity, the RL should increase: more severe issues imply higher risk. * **No issues, No Risk**: RL(∅) = 0. When no issues were detected *but analyses were run*, the risk level is 0. *Note: When no analysis is available for a project, then RL is undefined, NOT zero.* * **Averaged risk**: For convenience, the RL for a group of projects, or for the organization could be computed using a weighted average on the RL of the projects. {% hint style="info" %} Note that the RL for a group of projects, defined as weighted average of the RL for each project in the group, means that the RL for the group is in the range \[0, 100], and it is a linear function of the RL of the individual projects. {% endhint %} ### Configuration The relative weights for each issue type and severity, and the weight of each project in the global risk for the organization or project can be modified in the `xygeni.risk-level.yml` configuration file. The cutoff values for each risk category can be configured as well: ```yaml # Configuration for risk level # Weights for each issue kind and severity level # # Each array is the weight for issues of the given kind, # with critical, high and low severity, respectively. weights: misconfiguration: [3, 2, 1] suspect_dependency: [3, 2, 1] secret: [3, 2, 1] iac_flaw: [3, 2, 1] unusual_activity: [3, 2, 1] code_tampering: [3, 2, 1] sca_vulnerability: [3, 2, 1] # Cutoff values for each risk category [c_low, c_high] # # high risk, when risk level >= c_high # moderate risk, when risk level in the [c_low, c_high) interval # low risk, when risk level < c_low # # c_low must be lower than c_high, and both in the range (0, 100) cutoff: [33.33, 66.66] # The factor for normalizing the weighted count of issues # into the risk range. Approximately the average steepness: 0.00666 # Weight for risk level aggregation across projects. # The business value project property is used for selecting the weight. project_weights: critical: 4 high: 3 medium: 2 low: 1 ``` # 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: 1. [Using the scanner command line](#using_the_scanner_command_line) 2. [Integrate the scanner into a CI/CD pipeline](#integrate-the-scanner-into-a-ci-cd-pipeline) 3. [Running scanner as a gate in a git hook](#running_scanner_as_a_gate_in_a_git_hook) 4. [Using Sensors for activity monitoring](#using_sensors_for_activity_monitoring) 5. [Uploading findings from external security tools](#uploading_findings_from_external_security_tools) ### 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: ```asciidoc # 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 IMAGE ``` The 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](/introduction-to-xygeni/guardrails)". {% hint style="info" %} 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... {% endhint %} {% hint style="info" %} See the [Xygeni Scanner](/xygeni-scanner-cli/xygeni-cli-overview) for further details on how to install and run the scans. {% endhint %} ### 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. {% hint style="info" %} See the [Integrate into CI/CD Systems](/xygeni-administration/platform-administration/integrations/integrate-scanner-cli-into-ci-cd-systems) section for full details. {% endhint %} {% hint style="info" %} **Xygeni can automatically add a pipeline to run the scanner**. Please visit [Managed Scans](/xygeni-products/scan-management/managed-scans) for further information. {% endhint %} ### 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. {% hint style="info" %} For full details, read [Git Hooks with Xygeni](/xygeni-administration/platform-administration/integrations/git-hooks-with-xygeni). {% endhint %} ### 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. {% hint style="info" %} To know how the sensors work and how to install them in the target systems, read [Integrate Xygeni Sensors](/xygeni-products/anomaly-detection/xygeni-sensors). {% endhint %} ### 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. {% hint style="info" %} Visit [external scanners supported](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools) to view the full list of external scanners and formats supported. For details on how to upload the results from a third-party scanner using the `report-upload` command, please read the [report-upload reference](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools#report_upload). {% endhint %} # Prioritization Funnels Xygeni's **Prioritization Funnels** enhance your ability to filter and identify crucial issues, enabling you to focus on resolving the most significant matters. Given a full set of security issues, Prioritization Funnels allow you to specify the “prioritization criteria” that will be automatically applied to the full set of issues, discarding the issues that don’t meet the criteria. The resulting set will contain the most important issues to remediate. Xygeni’s Prioritization Funnels are available for any kind of security risks and are available under the **All Risks** section and selecting on the **Prioritization funnel** button.
The main funnel (feed with all types of risks) is available at **All Risks** menu option (at the top-left). But you can also find risk-specific funnels under any “Risk” option in the different products available at the left-menu (SAST), SCA, CI/CD) security, Secrets, Infrastructure as code, Malware, Build Security and Anomalous Activity) . ## Out-of the-box Funnels Xygeni comes with some **out-of-the-box predefined Funnels** In the filters of any funnel, click on the “**Funnel**” filter and the available funnels are displayed: * \*\* Xygeni General Prioritization * \*\* Xygeni CI/CD Prioritization * \*\* Xygeni IaC Prioritization * \*\* Xygeni SAST Prioritization * \*\* Xygeni Secrets Prioritization {% hint style="info" %} Out-of-the-box funnels are preceded with \*\* to differentiate to [Custom Funnels](#custom-funnels) and cannot be modified. {% endhint %}
The funnel will be displayed based on “Severity” by default. By clicking on the “**Split by**” filter, you can make the funnel to be based on several categories (Malicious Code, IaC, Secrets, CI/CD, Open Source, etc) as well as severity. ### **How to see the specific issues filtered by the funnel criteria ?** At the bottom of the page, there is a **filter box** where you can select which issues you want to see. **Funnel Phase**, allows you to filter by any specific funnel criteria. If you select any of them, the issues list will contain the items filtered until the selected criteria
Once you select on a **funnel phase**, the table will show the issues contained in the selected phase. You can further refine your search by selecting additional filters. # Custom Funnels You can create your own C**ustom Prioritization Funnels.** Click on the button next to the *funnel selector* and the **Prioritization Funnel Configuration** panel will open:
Then, you can either create a New Funnel, Clone the selected funnel or Delete the selected funnel. {% hint style="info" %} Out-of-the-box funnels cannot be either modified or deleted. {% endhint %}
Click on ***New Funnel*** and give the funnel a name.
You can also use this new funnel as a “default” funnel for whatever type of risk. After naming the new funnel, you can add the criteria by selecting among the available ones in “**Select a stage to add**” .
Once you select one, click on the plus + sign to add it to the funnel.
You will see some values for the criteria (true or false in this example). You can decide which value must be met by any issue to “pass” the criteria. For example, selecting *Reachability: true,* means that any reachable issue will pass this stage of the funnel. You can add as much criteria (or stages) as you want, but remember that **order is important**. Criteria is applied from top to bottom. You can **drag-and-drop** the criteria to change their order. For **multi-valued criteria**, selecting several options works as an “**OR**”.
When done, click on Save button and your new funnel will be displayed and among the available ones. # Prioritization Criteria (Stages) ## Prioritization Criteria (Stages) Any funnel is composed of criteria that produce the different stages of the funnel. ### Out-of-the-box criteria Xygeni provides several out-of-the-box criteria, although you can add your own custom criteria. {% hint style="info" %} **Nature (Technical vs Business)** * Some criteria have a technical nature (Technical) while some others are business-oriented (Business) and their meaning has to do with custom categorization. **Calculation (Auto vs Manual)** * Other criteria are bussiness-oriented and should be supplied by the user (Manual) . * There are also criteria that, although initially calculated by Xygeni, can be further modified by user (Both). **Scope (Project vs Issue)** * Some criteria apply to all issues of a Xygeni project. The concrete value for an issue depends on some characteristic of the project to which belongs (Project). * Instead, other criteria applied individually to every issue (Issue). {% endhint %}
CriteriaDescriptionCalculationNatureScope
ReachabilityIs this vulnerability reachable? (see Reachability for further details)AutoTechnicalIssue
ExploitabilityIs this vulnerability exploitable ? (see Exploitability for further detailsAutoTechnicalIssue
FixableIs this vulnerability fixable? (see Fixable for further details)AutoTechnicalIssue
In application codeIs this vulnerability is app code (i.e. not in tests code)AutoTechnicalIssue
AI Triage ResultHas AI Triage classified this finding as a real vulnerability, a likely false positive, or as needing review? SAST only (see AI Triage Result for further details)AutoTechnicalIssue
Remediation UrgencyHow urgently should this AI-confirmed vulnerability be remediated (Immediate, Next Sprint, Planned, Backlog)? SAST only (see Remediation Urgency for further details)AutoTechnicalIssue
DeployedIs this application being deployed? Xygeni can detect if the application is being deployed to some resource, but you can also manually assign the correct valueBothTechnicalProject
Active DevelopmentIs this application actively under development? An application is considered by Xygeni as "Active Development" if the latest commit is not older than 90 days. You can manually change this valueAutoTechnicalProject
Internet ExposedIs this application exposed to the Internet?BothTechnicalProject
LegacyIs this a legacy (i.e. out of active maintenance) application?ManualTechnicalProject
Product UnitTo which Product Unit this application belongs?ManualBusinessProject
Business ValueWhat is the Business value of this application?ManualBusinessProject
ProviderWho is the provider of this application?ManualBusinessProject
ArchitectureWhich is the technical architecture of this application?ManualBusinessProject
Business AreaTo which Business Area (or dept) does the application belong to?ManualBusinessProject
Any custom criteriaAny custom-defined property defined for a project (see Custom criteria)ManualBusinessProject
{% hint style="info" %} We are continuously adding new criteria so you will likely find more criteria than explained at the time of writing this document. {% endhint %} ### Criteria's Specifics Additionally to the general meaning of the above prioritization criteria, every criteria has a special meaning depending on the issue type that applies.
CriteriaOpen SourceSupply ChainSecretsIaC
FixableA vulnerability is Fixable if there is a safe component available remediating the vulnerability. This criteria removes from previous criteria those vulnerabilities with no available fixes.Always TrueAlways TrueAlways True
In application codeThe scope of the component is for production, not in test or compile scopes. Users can configure specific scopes used in their organization.The issue is located into a file with a path that does not contain any "test" directoryThe issue is located into a file with a path that does not contain any "test" directoryThe issue is located into a file with a path that does not contain any "test" directory
ReachabilityThe vulnerability is reachable because the application code execution reaches the vulnerable code in the componentIt includes issues that represent a security issue such as PPE, confusing names, or issues related to permissions. See each detector information for more details.The secret is located in:

- a file under version control
- an image

It includes Iac security issue types (Appsec, Encryption, Gensec, IAM, Network, Secrets...)

It discards issues related to best practices (as Convention).

Check detectors documentation for more details

ExploitableThis criteria includes those CVEs with a EPSS score bigger than 0,1.Same as Reachability

Includes any secrets that have been verified or can not be verified.

All secrets that Xygeni verifies as inactive are discarded by this criteria.

Same as Reachability
Active DevelopmentThe project has commits in the last 90 days.The project has commits in the last 90 days.The project has commits in the last 90 days.The project has commits in the last 90 days.
DeployedA component's vulnerability is considered as Deployed if Xygeni detects a pipeline or workflow that deploys (checkout) the project, image or package.Always TrueA secret is considered as Deployed if it appears in a public repo or image.An IaC issue is considered as Deployed if Xygeni detects a pipeline or workflow that uses the IaC configuration to deploy the infrastructure
Internet ExposedAny component vulnerability is considered as Internet Exposed if the project Internet Exposed property value is set to true.The repository with automations is public, or the issue is associated with the infrastructure.The repository, image or package is public.Any IaC issue is considered as Internet Exposed if the project Internet Exposed property value is set to true.
{% hint style="info" %} For any criteria with Business nature, its value depends on the value of the property and CUSPs associated to the project. Adjustments are available in the properties of the project in [Project Management](/xygeni-administration/platform-administration/projects-management). {% endhint %} ### Custom criteria Besides the above out-of-the-box criteria, you can create your own custom criteria. To do it, you just need to add **custom properties** to your applications (projects in Xygeni’s terminology) and those properties will be available as funnel criteria. {% hint style="info" %} See [Project Custom Properties](/xygeni-administration/platform-administration/projects-management#choosing_project_or_group_in_dashboard-3) for further info. {% endhint %} # Reachability ## Reachability *When a dependency has a vulnerability (i.e. a CVE), is that CVE really affecting my application?* Reachability, in a SCA (or vulnerability analysis) context, is a property of a vulnerability finding that indicates whether it will (or wont) be invoked under the software’s normal operational conditions. Analyzing the reachability for a large set of vulnerability findings for a software is important. Most of the SCA scanners work by extracting the dependency graph (*direct and transitive/indirect dependencies*) from manifest files (*pom.xml, package.json etc*.), and simply enumerate the known vulnerabilities that are listed in vulnerability databases (NVD and others). This gives many more findings that the real vulnerabilities that a potential adversary could exploit in the deployed software. Most of those findings are NOT actually reachable, because although the dependency with the vulnerability is “imported” (in the component descriptors of the target software S and transitively on its dependencies), your application only uses a small portion of those components, not invoking the vulnerable code of the dependacny. By focusing on reachable vulnerabilities only, the ones that exist within the code usage path of S, we focus on the vulnerabilities that can pose an actual risk. By doing so, we disregard the ones that, while present, may never be executed. {% hint style="info" %} If your application invokes the vulnerable function, it is at risk because the issue is accessible. Conversely, if your app does not call this function, it remains unaffected and the issue is not present. This means not only tracing **direct** calls to the vulnerable function, but also **indirect** or **transitive** calls. {% endhint %}
### Values for Reachability * **Reachable**: An issue is flagged as **reachable** when the application's call graph can access the vulnerable method in the dependency, either **directly** or **indirectly**. * **Always Reachable**: If an issue is flagged as **always reachable**, it is strongly recommended that the vulnerability be fixed regardless of your application code. This often occurs when the vulnerable part is **unrelated** to a **specific** dependency **method**. * **Potentially Reachable**: An issue is flagged as **potentially reachable** when it's impossible to confirm its reachability or unreachability. Common reasons for this include unsupported call graph analysis for certain languages or package managers, insufficient information, and scenarios with dynamic or conditional invocations. * **Not reachable**: An issue is flagged as **not reachable** when the application's call graph analysis determines that no function calls directly or indirectly invoke the vulnerable method in the dependency. {% hint style="info" %} Do not confuse **reachability** with **severity**. A low-severity and reachable vulnerability probably needs to be handled with a higher priority than an unreachable and critical one. But a critical unreachable vulnerability should not be muted/disregarded as reachability may change: the vulnerable code may become reachable after changes in the software (where adding a new call changes the call graph so the vulnerable function becomes reachable). An unreachable vulnerability is a latent one, probably harmless in the current version of the software. {% endhint %} {% hint style="info" %} ***Reachability*** should be considered as a **main criteria** for **vulnerability prioritization** (see [Prioritization Funnels](/introduction-to-xygeni/prioritization-funnels)) {% endhint %}
# Exploitability ## Exploitability Given we found an issue with a CVE, we should first know if it is reachable (as seen above). But even when reachable, **what is the likelihood to be exploited?** We’re continuously drowning in CVEs — including many high-severity CVEs — but **the majority aren’t actually exploitable**. This, of course, can make it difficult to prioritize vulnerabilities as well as to estimate remediation efforts. CVEs provide a “metric” for such exploitability (based on CVSS). **CVSS** scores vulnerabilities based on their characteristics and potential impacts but **don't consider real-world threat data**. Conversely, **EPSS** forecasts rely on up-to-the-minute **risk intelligence** from the CVE repository and **empirical data** about **real-world system attacks**. While CVSS measures the inherent (theoretical) severity of vulnerabilities, EPSS predicts the likelihood of exploitation based on empirical data.
In this context, although Xygeni scores the severity of a CVE issue based on CVSS, the **Exploitability criteria adds a more reliable criteria to the funnel**, thus filtering out those issues with low exploitability likelihood. {% hint style="info" %} ***Exploitability*** should be considered as a main criteria for **vulnerability prioritization** (see [Prioritization Funnels](/introduction-to-xygeni/prioritization-funnels)) {% endhint %} You can view the EPSS Score associated with a vulnerability in the Vulnerability Details section.
# Fixable **Fixable,** (at least in OS depedencies) meant that, for a certain vulnerability in a version of a dependency, there exists a further version that fixes the vulnerability. Because there is not always a fix available, **Fixable** can take different values: * **No Fix Available** : There does not exist any version that resolves the vulnerability. * **Auto Fix Available** : There exists a newer version of the dependency that fixes the vulnerability. Besides, it also means that Xygeni can automatically fix the vulnerability (visit [Xygeni's Automatic Fix](/xygeni-products/open-source-security-oss/oss-auto-remediation) for further information) * **Manual Fix Available** : There exists a newer version of the dependency that fixes the vulnerability. In this case [Xygeni's Automatic Fix](/xygeni-products/open-source-security-oss/oss-auto-remediation) is not possible due to different reasons (the fix entails a sequence of manual tasks, the package manager fix automation is not supported yet by Xygeni, etc...). In these cases, you should follow the provided recommendations to fix the vulnerability. # AI Triage Result ## AI Triage Result *Did the AI confirm this finding as a real vulnerability, or did it flag it as a likely false positive?* **AI Triage Result** is a SAST prioritization stage based on the verdict produced by [AI Triage](/xygeni-administration/platform-administration/projects-management/ai-triage). It separates AI-confirmed findings from likely false positives and from issues the AI could not classify with confidence, so teams can focus on what matters first. ### Values for AI Triage Result * **Potential True Positive**: The AI is confident the finding is a real vulnerability based on the code context. These issues should advance through the funnel for further prioritization. * **Potential False Positive**: The AI is confident the finding is not a real vulnerability — for example, the data is sanitized, the path is unreachable, or the rule does not apply. Hidden by default in the funnel so they do not add noise. * **Needs Review**: The AI did not have enough context to reach a confident conclusion. A human reviewer should inspect the issue. * **Not Calculated**: AI Triage has not been executed for the issue, or the triage attempt failed. The issue has not yet received a verdict. ### Default behavior in the SAST funnel In the default SAST prioritization funnel, the **AI Triage Result** stage shows: * Potential True Positive * Needs Review * Not Calculated **Potential False Positive** is hidden by default so AI-confirmed false positives are filtered out of the active backlog. They remain visible if you explicitly include the value in the funnel. {% hint style="info" %} **AI Triage Result** is part of the default **SAST** funnel and is also available as a filter on the **DAST** funnel. The **SCA** funnel does not use this stage because AI Triage does not produce a verdict for SCA findings — false-positive detection for SCA is handled by [Reachability](/introduction-to-xygeni/prioritization-funnels/prioritization-funnels-1/reachability). {% endhint %} {% hint style="info" %} The verdict reflects an AI assessment, not a definitive judgment. Do not permanently mute issues based on a Potential False Positive verdict alone — the issue slide-out exposes the AI reasoning so a human reviewer can confirm before acting. {% endhint %} # Remediation Urgency ## Remediation Urgency *Of the AI-confirmed vulnerabilities, which ones must be fixed now, which can wait for the next sprint, and which can be deferred?* **Remediation Urgency** is a SAST prioritization stage that assigns a business-driven urgency level to vulnerabilities classified as **Potential True Positive** by [AI Triage](/xygeni-administration/platform-administration/projects-management/ai-triage). The urgency is derived from the AI's semantic understanding of the code — endpoint exposure, authentication requirements, compensating controls, reachability of the vulnerable path, and business impact — not from a direct mapping of the scanner's severity. ### Values for Remediation Urgency * **Immediate**: Requires attention right now — the vulnerability is actively exploitable, publicly reachable, or represents a critical business risk. * **Next Sprint**: Must be addressed in the current cycle. Real risk that cannot wait for the next planning round. * **Planned**: Should be included in the next planning cycle. A genuine vulnerability without immediate exploitability. * **Backlog**: Real but low urgency. Address when capacity allows. ### Default behavior in the SAST funnel In the default SAST prioritization funnel, the **Remediation Urgency** stage shows: * Immediate * Next Sprint **Planned** and **Backlog** are hidden by default so the active backlog stays focused on what needs to be fixed soon. They remain available if you want to widen the funnel. {% hint style="info" %} **Remediation Urgency** is part of the default **SAST** funnel and is also available as a stage / filter on the **SCA** and **DAST** funnels (where AI Triage produces an urgency value for each finding). {% endhint %} {% hint style="info" %} Do not confuse **Remediation Urgency** with the scanner's **severity**. Severity describes the technical impact of a vulnerability class; Remediation Urgency reflects how that vulnerability behaves in your specific code and deployment context, as assessed by AI Triage. {% endhint %} # Guardrails ## Guardrail Specification When specific rules or special exit codes are required by pipelines or security policies, complex conditions can be defined using guardrail expressions. Guardrails enables users to customize and specify how a Xygeni command should behave in the presence of certain conditions or criteria, thereby allowing for flexible and tailored handling of failure scenarios. Guardrail specification is a subset of ***Xygeni™ XyFlow Language***, tailored for guardrail conditions. {% hint style="info" %} Visit [Xygeni GuardRails](/xygeni-scanner-cli/xygeni-cli-overview/guardrails) for further information. {% endhint %} # Generate a SBOM Xygeni allows to generate a SBOM for a certain project. Two SBOM formats are currently supported: * **CycloneDX** (JSON schema) .See for full details. * SPDX, in JSON serialization format, standard ISO/IEC 5962:2021. See for full details. You have two options to generate an SBOM: 1. [From the Web User Interface](#sbom_options) 2. [Using the Xygeni CLI](#sbom_options-1) ### Generate a SBOM from the Web User Interface Once you have selected a project, the **Inventory** >> **Repositories** will present you the **Download SBOM** option.
You can also open a project's detail slide to download the SBOM.
### Generate a SBOM with the Xygeni CLI You can also generate a SBOM with the xygeni CLI. This is useful if you need the SBOM during a build/deploy CI/CD process. {% hint style="info" %} Please visit [Generate SBOM with the Xygeni CLI](/xygeni-scanner-cli/xygeni-cli-overview/generate-sbom-with-the-xygeni-cli) for further information. {% endhint %} # Scan History At **Home >> Scan History,** you can access all the historical information related to executed scans. {% hint style="info" %} You can either select *All,* a *Project Group*, or a specific Single Project at the [Projects Selector](/introduction-to-xygeni/xygeni-web-ui-overview#projects-selector) {% endhint %}
The Top panel shows a timeline of the frequency of the scans, splitted by: * Successful scans (SUCCESS) ![](/files/TFCf6rjThN96e2RgQ6Q3) * Scans with errors in analysis (WARNING) ![](/files/hDb1aorrgyYZYia0VEYg) * Scans with processing errors (ERROR) ![](/files/jzRfXBY8EGL09ROC3yrO) {% hint style="info" %} * A scan is tagged as SUCCESS if ALL the executed scanners (deps, misconf, etc) were successful. * A scan is tagged as WARNING if ANY of the executed scanners have failed. * A scan is tagged as ERROR if ALL the executed scanners have failed. {% endhint %} Clicking on the ![](/files/DouKZqrUhpxMfNVdqp29) details icon of a scan will open a slide with more information of the scan:
In case of error or warning, the slide will display the reason(s):
The list of scans also show (and filter) the **scope** of the scan: **complete** (**Full Scan**) or **partial** (**Partial Scan**) {% hint style="info" %} * A scan is tagged as **Full Scan** if ALL the scanners have been executed * A scan is tagged as **Partial Scan** if SOME scanner has not been executed (*skipped*) {% endhint %} Clicking on the save icon of a scan marks that scan as the **baseline** of the project.
{% hint style="info" %} See [Project Baseline](/introduction-to-xygeni/key-concepts/project-baseline) for further reference. {% endhint %} ### Scans Comparison Most of Risk pages contain a functionality to compare scans. It can be accessed by selecting **ChangeLog** option. {% hint style="info" %} See [Comparison between different scans](/xygeni-products/application-security-posture-management-aspm/all-risks/issues-comparison-between-different-scans) for further information on how to compare scans {% endhint %} # Supported Integrations ### SCM CI/CD Systems Xygeni can be integrated into most SCMs and CI/CD systems. Here are examples on how to integrate Xygeni into several SCMs and CI/CD systems: 1. [Azure Pipelines](/xygeni-administration/platform-administration/integrations/integrate-scanner-cli-into-ci-cd-systems/azure-pipelines-integration) 2. [BitBucket](/xygeni-administration/platform-administration/integrations/integrate-scanner-cli-into-ci-cd-systems/bitbucket-integration) 3. [CircleCI](/xygeni-administration/platform-administration/integrations/integrate-scanner-cli-into-ci-cd-systems/circleci-integration) 4. [GitLab](/xygeni-administration/platform-administration/integrations/integrate-scanner-cli-into-ci-cd-systems/gitlab-runner-integration) 5. [GitHub](/xygeni-administration/platform-administration/integrations/integrate-scanner-cli-into-ci-cd-systems/github-actions-integration) 6. [Jenkins](/xygeni-administration/platform-administration/integrations/integrate-scanner-cli-into-ci-cd-systems/jenkins-integration) 7. [TravisCI](/xygeni-administration/platform-administration/integrations/integrate-scanner-cli-into-ci-cd-systems/travis-ci-integration) ### Sensor Plugins Xygeni allows you to actively monitor and address vulnerabilities as they are detected in the SCM or CI/CD systems. Below are the listed sensors applicable for SCM and CI/CD systems: 1. [Azure Sensor](/xygeni-products/anomaly-detection/xygeni-sensors/xygeni-sensor-for-azure) 2. [BitBucket Sensor](/xygeni-products/anomaly-detection/xygeni-sensors/xygeni-sensor-for-bitbucket) 3. [GitHub Sensor](/xygeni-products/anomaly-detection/xygeni-sensors/xygeni-sensor-for-github) 4. [GitLab Sensor](/xygeni-products/anomaly-detection/xygeni-sensors/xygeni-sensor-for-gitlab) 5. [Jenkins Sensor](/xygeni-products/anomaly-detection/xygeni-sensors/xygeni-sensor-for-jenkins) ### Git Hooks Xygeni seamlessly integrates with Git Hooks. {% hint style="info" %} For detailed reference, see [Git Hooks with Xygeni](/xygeni-administration/platform-administration/integrations/git-hooks-with-xygeni). Xygeni supports integration with Git Hooks. {% endhint %} ### Ticketing and 3rd Party Platforms Xygeni allows to create tickets, issues and alerts in the following platforms: 1. [Jira](/xygeni-administration/platform-administration/integrations/ticketing-systems#integration-with-jira) 2. [GitHub Issues](/xygeni-administration/platform-administration/integrations/ticketing-systems#integration-with-github-issues) 3. [GitHub Alerts](/xygeni-scanner-cli/xygeni-cli-overview/exporting-xygeni-results-to-3rd-party-tools#github-alerts) 4. [GitHub Status](/xygeni-scanner-cli/xygeni-cli-overview/exporting-xygeni-results-to-3rd-party-tools#github-status) 5. [GitLab Alerts](/xygeni-scanner-cli/xygeni-cli-overview/exporting-xygeni-results-to-3rd-party-tools#gitlab-alerts) ### Collaboration & Communication Tools Xygeni allows to configure notifications in the following platforms: 1. [Slack](/xygeni-administration/platform-administration/integrations/collaboration-and-communication-tools#integration-with-slack) ### Remediation (auto-fix) Xygeni allows automatic fixing of certain types of issues in the following platforms: 1. [GitHub](/xygeni-administration/platform-administration/integrations/remediation-systems#github) 2. [GitLab](/xygeni-administration/platform-administration/integrations/remediation-systems#gitlab) ### IDE Plugins Integrated Development Environment [(IDE) plugins](https://docs.xygeni.io/introduction-to-xygeni/supported-ide) facilitate running the xygeni scanner within your preferred IDE. 1. [Visual Studio Code Extension](https://marketplace.visualstudio.com/items?itemName=xygeni-security.xygeni-scanner-vscode\&ssr=false#overview) 2. [Eclipse Extension](https://marketplace.eclipse.org/content/xygeni-security) 3. [IntelliJ Extension](https://plugins.jetbrains.com/plugin/29079-xygeni) 4. [Windsurf Extension](https://marketplace.windsurf.com/extension/xygeni-security/xygeni-scanner-vscode) 5. [Cursor Extension (Open VSX)](https://open-vsx.org/extension/xygeni-security/xygeni-scanner-vscode) 6. [Visual Studio 2022](https://marketplace.visualstudio.com/items?itemName=xygeni-security.22221043359) # Supported IDE Xygeni offers plugins for major Integrated Development Environments (IDEs) to help you secure your codebase directly within your workflow. **Secure your codebase with Secrets, SAST, SCA, IaC & Supply Chain scanning directly within your IDE environment.** The Xygeni Security Scanner is a powerful extension that brings comprehensive security scanning to your fingertips. It integrates seamlessly with your development workflow, allowing you to identify and remediate security vulnerabilities early in the process. ## Key Features The following features availbale for all supported IDEs: * **Comprehensive Scanning**: Detect a wide range of security issues: * **Secrets**: Find hardcoded credentials, API keys, and other sensitive data. * **SAST (Static Application Security Testing)**: Analyze your source code for common vulnerabilities. * **SCA (Software Composition Analysis)**: Identify vulnerabilities in your open-source dependencies. * **IaC (Infrastructure as Code)**: Scan your IaC files (e.g., Terraform, CloudFormation) for misconfigurations. * **Misconfigurations**: Detect security misconfigurations in your application and services. * **Remediation actions for SCA and SAST Issues**: Automatically detect and provide remediation guidance for vulnerabilities found in your source code and dependencies, enabling quick fixes directly within your IDE. * **Seamless Integration**: The extension adds a dedicated Xygeni view to your IDE environment for easy access. * **Guided Setup**: A simple configuration process to connect to the Xygeni service. * **In-Editor Issue Highlighting**: View security findings directly in your code, making it easy to pinpoint and fix issues. * **Detailed Vulnerability Information**: Get rich details for each identified issue, including severity, description, and remediation guidance. *** ## Visual Studio Code Visit [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=xygeni-security.xygeni-scanner-vscode) marketplace. ### Installation 1. Open the Extensions view in VS Code (`Ctrl+Shift+X`). 2. Search for **Xygeni Security Scanner**. 3. Click **Install**. ### Getting Started 1. **Open the Xygeni View**: After installation, click on the Xygeni icon in the activity bar. 2. **Configure the Extension**: * You will be prompted to configure the connection to the Xygeni service. * Obtain an API token from your Xygeni Dashboard. If you don't have an account, you can sign up for a trial. * Enter the Xygeni API URL and your token in the configuration view. 3. **Run a Scan**: * Once configured, the "Scan" view will be available. * Click the "Run Scanner" button (▶️) to initiate a scan of your workspace. 4. **View Results**: * Scan results will be displayed in the Xygeni view, categorized by type (SAST, SCA, Secrets, etc.). * Click on an issue to see detailed information and navigate to the affected file and line. ### Extension Settings This extension contributes the following settings (accessible via File > Preferences > Settings and searching for "xygeni"): * `xygeni.api.xygeniUrl`: The URL of the Xygeni API server. * `xygeni.api.xygeniToken`: Your Xygeni API token. It is recommended to store this securely. * `xygeni.proxy.*`: A full set of options to configure a proxy. ### Screenshots
### Support & License * **Support**: Contact us at . * **License**: Apache License 2.0. *** ## Visual Studio 2026 Visit [Xygeni Visual Studio Extension](https://marketplace.visualstudio.com/items?itemName=xygeni-security.22221043359) at marketplace. ### Installation 1. Open **Extensions > Manage Extensions** in Visual Studio. 2. Search for **Xygeni Security for Visual Studio**. 3. Click **Install** and restart Visual Studio to complete the installation. ### Getting Started 1. **Open your project or solution** in Visual Studio. 2. **Open the Xygeni setting** from the new Xygeni icon. 3. **Configure the extension**: * Obtain an API token from your Xygeni Dashboard. * Enter the Xygeni API URL and your token. 4. **Save & Install** to complete Xygeni CLI installation. 5. **Run a scan** to analyze your workspace. 6. **Open Xygeni Explorer** and open issues to inspect affected files and remediation guidance. ### Screenshots
### Support & License * **Support**: Contact us at . * **License**: Apache License 2.0. *** ## IntelliJ (and JetBrains IDEs) ### Installation * **Using the IDE built-in plugin system**: Settings/Preferences > Plugins > Marketplace > Search for "xygeni" > Install * **Using JetBrains Marketplace**: Go to [JetBrains Marketplace](https://plugins.jetbrains.com/) and install it by clicking the "Install to ..." button. * **Manually**: Download the latest release from JetBrains Marketplace and install it manually using Settings/Preferences > Plugins > ⚙️ > Install plugin from disk... ### Getting Started 1. **Install the plugin**: Once installed, the plugin automatically downloads and sets up the Xygeni Scanner. 2. **Open the Xygeni View**: Click the Xygeni icon in the activity bar to open the view and console. 3. **Configure the plugin**: * Obtain an API token from your Xygeni Dashboard. * Enter the Xygeni API URL and your API token when prompted or in the configuration view. 4. **Run a scan**: Click on the **Run scan** button to initiate a scan of your workspace. 5. **View results**: * Scan results are displayed in the Xygeni view. * Click twice on an issue to view detailed information in the editor. 6. **Fix issues**: On the detailed information panel, select the **FIX** tab to remediate the vulnerability. *** ## Eclipse ### Installation The plugin is available on the Eclipse Marketplace: **Using Eclipse Marketplace Client**: 1. Open Eclipse and go to **Help > Eclipse Marketplace...** 2. Search for **Xygeni Security**. 3. Click **Install** and follow the prompts. ### Getting Started 1. **Open the Xygeni Views**: * **Xygeni Explorer**: Go to Window > Show View > Other... > Xygeni > Xygeni Explorer. * **Xygeni Issue Details**: Go to Window > Show View > Other... > Xygeni > Xygeni Issue Details. 2. **Configure the Extension**: * Obtain an API token from your Xygeni Dashboard. * Open **Xygeni Settings** (Preferences > Xygeni Configuration). * Enter the **Xygeni API URL** and **Xygeni Token**. * Click **Save and Install**. 3. **Run a Scan**: * Open the Xygeni Explorer view. * Click the **Run Scan** button (or select Xygeni > Xygeni Scan from the menu). 4. **View and Fix Results**: * Expand categories in the Xygeni Explorer to see issues. * Double-click an issue to open the file and view details in the **Xygeni Issue Details** view. * Follow remediation guidance in the details view. ### Screenshots
### Support & License * **Support**: Contact us at . * **License**: Apache License 2.0 # Customizations Organizations may need to customize the Xygeni platform to meet their specific needs. Although Xygeni is designed to provide useful, actionable findings on the security posture of an organization against software supply chain attacks from the very start, Xygeni also provides a rich REST API and a set of development tools for special customizations. There is a public GitHub repository, [Xygeni Extensions](https://github.com/xygeni/xygeni-extensions), that contains documentation and sample sources for different extensions of the Xygeni platform. In this repository you will find detailed instructions and how-to guides for developing custom detectors, sample code and project build templates. ## API The [REST API](https://api.xygeni.io/swagger-ui.html) allows the retrieval of security issues, project risk summary, trends in security position, and report generation as well as administration. You may use the API to integrate the security findings into your own tools and systems, or into your pipelines. {% hint style="info" %} See [REST API](/xygeni-administration/rest-api) for further detail {% endhint %} ## Custom Detectors A **Xygeni detector** is a piece of logic that detects a security issue in a scanned target system such as source code, a source code repository or a container image, a CI/CD system or other software too. Xygeni provides a rich set of predefined, off-the-shelf detectors used in scans, although you may add your own custom detector. Such custom detectors can be easily integrated into scans using the `--custom-detectors-dir` option. {% hint style="info" %} For full information, read [Developing and Deploying Custom Detectors](https://github.com/xygeni/xygeni-extensions/tree/main/extensions/custom_detectors). {% endhint %} ## Defining Custom Converters for 3rd-Party Tool Reports If you need to [upload a report](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools) from a **third-party security tool**, and the report format is not supported by Xygeni, you may develop your own extension for loading the input report and converting it to one of the available Xygeni reports. Xygeni provides a framework for developing customized report converters and registering them so they are available in the `report-upload` scanner command. {% hint style="info" %} For further details, read [Adding Support For Additional Report Formats](https://github.com/xygeni/xygeni-extensions/blob/main/extensions/report_upload/README.md). {% endhint %} In other cases, third-party tools do not provide a standardized report to be ingested. For some popular tools an export mechanism (often using the tool api) is provided. See [Exporting Reports from Third-Party Tools](https://github.com/xygeni/xygeni-extensions/blob/main/README.md#exporting-reports) for more details. # Application Security Posture Management (ASPM)
Xygeni’s **Application Security Posture Management** (**ASPM**) tool enhances how your teams visualize, prioritize, and remediate risks. The **Xygeni platform** delivers **real-time visibility** and **contextualization** that simplifies security, ensuring your applications are protected from development through deployment. {% hint style="info" %} For a full description of ASPM in the Xygeni UI please go to [Xygeni ASPM Web UI](/xygeni-products/application-security-posture-management-aspm/aspm-user-interface-guide) {% endhint %} ### Automated Asset Discovery and Inventory Management Xygeni provides automated solutions for comprehensively identifying and cataloging assets within your software supply chain, enhancing visibility and control over your development and deployment processes. From source control management (**SCM**) systems to **build tools**, **CI/CD workflows**, and **distribution mechanisms**, Xygeni captures a detailed [**inventory** ](/xygeni-products/application-security-posture-management-aspm/inventory)of **assets**. As well as identifying code repositories, open-source and private dependencies, package managers, pipelines and jobs, scripts and build files, plugins and tools, Infrastructure as Code (IaC) templates and cloud resources. Furthermore, Xygeni automatically **identifies** and continuously **monitors** these **assets**, assessing **their interdependencies** as well as the individual and **overall security posture** of each asset, application, and customer defined group or category. {% hint style="info" %} Visit the [Inventory](/xygeni-products/application-security-posture-management-aspm/inventory) documentation page for further details {% endhint %}
### Users and Contributors Analysis Xygeni enhances its Inventory capabilities by integrating a comprehensive [Collaborator Analysis](/xygeni-products/application-security-posture-management-aspm/health-check#collaborators) feature. This analysis is essential for the effective management of administrative users, contributors, and collaborators associated with software repositories. By monitoring user activity and evaluating each user's role, we can ensure we follow best practices and resolve these issues as soon as posible. Xygeni also helps organizations implement a *least privilege* strategy by identifying risks associated with inactive or overprivileged users. Some key features are: 1. [Comprehensive Permissions Review](/xygeni-products/application-security-posture-management-aspm/health-check#collaborators): Xygeni scans for all SCM (Source Control Management) user accounts that have read, write, or manage permissions on repositories. This includes permissions assigned directly to users or inherited from groups with access to the repositories. 2. [Group and User Tracking](/xygeni-products/application-security-posture-management-aspm/inventory/collaborators): The system registers all SCM groups, including any users with significant permissions, ensuring that all potential access points are monitored and controlled. 3. [Non-SCM Contributors](/xygeni-products/application-security-posture-management-aspm/inventory/collaborators): Xygeni also identifies git users who are not linked to an SCM account but have made commits to the git history. Xygeni tracks contributions across all branches, providing a complete picture of every user that has modified the codebase. {% hint style="info" %} Visit these pages for further info: * [Inventory Collaborators](/xygeni-products/application-security-posture-management-aspm/inventory/collaborators). * [Heath Check Collaborators](/xygeni-products/application-security-posture-management-aspm/health-check#collaborators). {% endhint %}
### Advanced Dynamic Prioritization Xygeni's [dynamic funnels](/introduction-to-xygeni/prioritization-funnels) provide extensive customization and precise filtering options. Customers can define up to eight stages in their prioritization funnel. Tailored by severity, issue type and category. This flexibility ensures that each organization can focus on the vulnerabilities that pose the highest risk according to their specific security policies and operational needs. The funnel system supports the integration of customer-defined properties alongside pre-configured stages such as reachability or exploitability, among others. This allows organizations to further refine their security focus and manage vulnerabilities more effectively. {% hint style="info" %} Visit the [Prioritization Funnels](/introduction-to-xygeni/prioritization-funnels) page for further info. {% endhint %}
### Integration of 3rd-Party Security Reports Xygeni’s Application Security Posture Management (ASPM) platform can also seamlessly **integrate** reports from **third-party security tools**, including Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools. This capability enables organizations to optimize their current technology infrastructure. Offering a unified perspective on security threats across various tools and platforms ensuring that all potential vulnerabilities are identified, prioritized, and addressed efficiently. Key benefits of this integration include: * **Unified Security Dashboard**: Consolidates findings from various tools into a single dashboard for monitoring and analysis. * **Enhanced Threat Detection**: Combines data from multiple sources to provide a more complete assessment of security risks. * **Efficient Remediation**: Enables quicker and more coordinated responses to security issues by centralizing vulnerability management. Three ingestion paths are available, so you can pick whichever fits the tool and your CI/CD setup best: * **Convert + upload** — the scanner reads a report file the tool already produced and uploads it. The default path; works with any tool that can write to disk. * **Pull** — the scanner calls the tool's API, fetches the findings, and uploads them. No intermediate file; secrets stay on the CI runner. Available for tools that expose a documented findings API (SonarQube/SonarCloud, Kiuwan, Checkmarx One, Prisma Cloud, Wiz CNAPP). * **Push (webhook)** — the tool calls Xygeni's webhook on scan completion. Configured tool-side; no CLI invocation needed. Available for tools that emit outbound webhooks. {% hint style="info" %} Visit the [Importing reports from 3rd party tools](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools) page for further information and the full list of supported tools per mode. {% endhint %} ### Audit Trail of Security Events Xygeni’s Application Security Posture Management platform includes a robust security audit trail feature that provides a c**omprehensive timeline** of events associated with each asset. This feature tracks and **logs all significant activities**, such as changes, updates, and security incidents. Ensuring that users have a clear and detailed view of the security history for each asset within their software environment. Some notable capabilities of our security audit trail feature are: * **Event Log**: Every **modification**, **update**, or **security event** related to an asset is logged. Creating a chronological record that can be crucial for troubleshooting, compliance audits and security investigations. * **Comprehensive Coverage**: The audit trail captures a wide range of events, from code commits and build configurations to deployment activities and configuration modifications, ensuring that all aspects of the asset lifecycle are monitored. * **Effortless Access and Visualization**: Users are able to efficiently access and visualize audit trails, facilitating the identification of specific events or patterns. * **Enhanced Security and Compliance**: By maintaining a **detailed record** of all **actions** taken on each asset, Organizations can strengthen their security framework and ensure adherence to regulatory standards, facilitating the verification of procedural compliance and enabling the early detection of a security breach. {% hint style="info" %} Visit the [Findings and Audit Trail](/xygeni-products/application-security-posture-management-aspm/inventory/all-assets#findings-and-audit-trail) page for further information. {% endhint %}
### Quick and Efficient Remediation Process Xygeni’s ASPM platform optimizes the remediation process by providing detailed guidelines and automated actions for addressing each risk and vulnerability. Integration with ticketing and tracking systems streamlines the process of updating workflows, ensuring that vulnerabilities are promptly addressed. {% hint style="info" %} Visit these pages for more information: * [Remediation Actions](/introduction-to-xygeni/key-concepts/remediation-actions). * [Automatic Fix](/xygeni-products/open-source-security-oss/oss-auto-remediation). {% endhint %} # ASPM User Interface Guide Xygeni's ASPM section comprises of six primary tabs: * [Projects](/xygeni-products/application-security-posture-management-aspm/projects) * [Risks](/xygeni-products/application-security-posture-management-aspm/all-risks) * Code Quality (coming soon) * [Governance](/xygeni-products/application-security-posture-management-aspm/governance) * [Inventory](/xygeni-products/application-security-posture-management-aspm/inventory) * [Health Check](/xygeni-products/application-security-posture-management-aspm/health-check)
# Projects The ***Projects*** page provides a centralized view of all scanned and monitored projects across your organization. This dashboard is essential for tracking vulnerabilities and overall risk posture.
### Statistics Summary There are metrics at the top of the page that give an at-a-glance view of the current security status across all projects:
* **Total Projects**: Total number of monitored repositories. * **Total Malware and Vulnerabilities**: * ☠️ **Malware Detected** * 🔴 **High and Critical Severity Issues** * 🟠 **Medium Severity Issues** * 🔵 **Low Severity Issues** ### Repository Management Use the **Manage Repositories** button to acces the [***Manage Scans***](/xygeni-products/scan-management/managed-scans) tab directly to: * Add or remove monitored repositories. * Configure integrations (e.g., GitHub, GitLab). ### Scanning From the **Projects** tab you can also scan each project:
* **Scan Now**: Manually via the **Scan Now** button. ### Filters and Search You can narrow down results using several filters:
* **Name Pattern**: Search by repository/project name. * **Project Type**: Select types of projects (e.g., GitHub, GitLab, etc.). * **Risk Level**: Filter by severity level of issues. * **Alert**: Filter by the alert status. ### Project Management You can directly modify the project's settings by selecting the **details button** of an individual project and clicking on **Configure Project Settings.** {% hint style="info" %} To modify a project's configuration the user must have the appropiate permissions (Root, Project\_Management) {% endhint %}
This will open a compact view of the [Project Management Tab](/xygeni-administration/platform-administration/projects-management) where you can modify options such as the policy applied to the project as well as project details:
### Projects Table Columns Each row in the table represents a single project with detailed attributes: | Column | Description | | -------------------------- | -------------------------------------------------------------------------------------- | | **Project Name** | The repository name and branch (e.g., `latioTech/java-sec-code-fork - origin/master`). | | **Risk** | A summarized risk score or indicator (shield icon shown; could be color-coded). | | **Variation** | Indicates if the risk is increasing (↑), decreasing (↓), or stable. | | **Issues by Severity** | Categorized count of issues: Red (High), Orange (Medium), Yellow (Low). | | **Last Scan** | Status or date of the last scan (e.g., “Scan will be triggered on-demand”). | | **Additional Information** | Supplementary notes or scan context. | | **Actions** | Blue **Scan Now** button allows immediate rescan. | Icons may denote special statuses: * ☠️ Indicates presence of malware. * Colored arrows denote risk trend. # Risks The **Risks** tab provides a comprehensive overview of identified security risks across all projects. It visualizes issue trends, prioritizes threats and allows in-depth issue analysis by type and severity.
### Risk Categories: * [**SAST**](/xygeni-products/code-security-cs/cs-user-interface-guide) (Static Application Security Testing) * [**SCA**](/xygeni-products/open-source-security-oss/risks-sca) (Software Composition Analysis) * [**CI/CD**](/xygeni-products/software-supply-chain-security-sscs/sscs-user-interface-guide/risks-ci-cd) **(**Continuous Integration and Continuous Delivery/Deployment**)** * [**Secrets**](/xygeni-products/secrets-security/secrets-user-interface-guide) (Committed credentials) * [**IaC**](/xygeni-products/iac-security/iac-user-interface-guide) (Infrastructure as Code) # All Risks Whether you've chosen a single project or a group, the All Risks page provides **three** distinct views: 1. [Prioritization Funnel](/introduction-to-xygeni/prioritization-funnels) 2. [Statistics](/xygeni-products/application-security-posture-management-aspm/all-risks/all-risks/statistics) 3. [Issues Evolution](/xygeni-products/application-security-posture-management-aspm/all-risks/all-risks/issues-evolution)
# Issues Evolution By selecting **Issues Evolution** on the **All Risks** page, you can see the evolution of the issues by type. You can also specify different time frames (last month, last 3 months, etc...)
# Statistics The '**All Risks >>** **Statistics'** view shows relevant data such as: * The total number of issues displayed by type & severity. * A table displaying these issues.
You can see issues of a specific type by clicking on each type. You may also filter these issues by the following criteria: * Funnel Phase (see [Prioritization Funnels](/introduction-to-xygeni/prioritization-funnels) ) * Severity * Explanation * Issue Category (cicd, iac, secrets, etc...) * Issue Type * Project (pattern) * Issue Status (open, confirmed, muted, etc...) * Tag By clicking in any part of the row, a slide will open showing all the details for each issue.
# Issue Comparison Between Different Scans Most of the ***Risk*** pages contain a functionality to compare scans. Accessed by selecting ***ChangeLog*** option in these Risks pages.
To compare two scans, you must select the **source scan (FROM)**.
The **source scan (FROM)** allows to be selected among: * Baseline (the scan tagged as [Project Baseline](/introduction-to-xygeni/key-concepts/project-baseline)) * Other branch {% hint style="info" %} By default, the list will show the differences between the **Baseline** and the **Last Scan**. Any issue tagged as **NEW** means that issue appear into the Target but it does not exist into the Source scan Any issue tagged as **REMOVED** means that issue appear into the Source but it does not exist into the Target scan {% endhint %}
You can **filter** the list by **type of change** (new and/or removed)
# Governance The **Governance** tab provides a high-level overview of your project's overall **security posture** across the software supply chain. It aggregates results from various scanners — including SAST, SCA, Secrets, IaC, CI/CD configuration, and Malware — and evaluates your repository’s compliance against key security benchmarks like the **CIS SSC Security Guide**. This dashboard is essential for security teams to monitor trends, prioritize risks and ensure governance policies are met. The Governance Tab Has two main sections: * The **Security Posture** tab **r**eflects the cumulative severity of findings from all integrated scanners
* The **Trend** tab displays statistics of your projects vulnerabilities over a specified time period
# Governance User Interface Guide ### Security Posture The **Security Posture** tab **r**eflects the cumulative severity of findings from all integrated scanners. Within the Security Posture Tab you can find the following details: **Risk Score** * A simplified risk indicator (color-coded). * Reflects the cumulative severity of findings from all integrated scanners (SAST, SCA, Secrets, etc.). **Risk Sources Breakdown** A stacked bar showing the proportion of risk types found in the repository: * **SAST** (e.g., insecure code patterns) * **CI/CD** (pipeline misconfigurations) * **SCA** (vulnerable open-source packages) * **Secrets** (hardcoded keys/tokens) * **IaC** (misconfigured infrastructure-as-code) * **Malware** (malicious packages or files) * **Anomalous Activity** (behavior-based risk) Each segment reflects the volume of findings per category. Issues Panel * **Current Detected Issues**: * 🟥 Critical * 🟧 Medium * 🟨 Low * **Trend Graph**:\ Shows issue growth over time. * **SCM Insights**: * Commits analyzed from GitHub. * Code-level issues broken down by severity. * **Package Manager**: * Packages scanned — Security issues detected. * **CI/CD**: * Pipelines and plugins detected/configured — no issues. * **AppSec Policy**: * Security policies that have not been enforced or are misconfigured. * **Deployment/Provisioning**: * IaC misconfigurations such as Kubernetes resources analyzed. ### Compliance Coverage * **Standard:** **CIS SSC Security Guide** * **Failed Checks**: * Examples: No protected branches, missing secure build tasks. * **Passed Checks**: * Examples: Dependency pinning, approved build tools. This helps gauge readiness for supply chain audits or regulatory compliance.
### Trends The **Trends** tab displays statistics regarding your projects vulnerabilities over a specified time period. The details shown in the Trends tab include: * **New vs Resolved Issues** (color-coded): * New Issues Detected * Resolved Issues * **Exposure Window** & **Time to Resolve**: * Marked as “Not Applicable” — likely due to a lack of remediation events. * **Impact of Anomalous Activities**: * Visual markers for: * Critical file changes * Suspicious events
# Inventory The **SDLC Inventory** provides a comprehensive perspective on risk propagation throughout systems and highlights potential attack vectors that may impact other entities. It enables the identification of secure and vulnerable pipelines, and offers insights into the components involved in software build and deployment processes. ### The Asset Graph It is important to understand the different **types of assets** used within the **SDLC Inventory** and their relationships: * **Repositories** may contain children (modules), each with its own **dependencies graph**. Many repositories are single-module, anyway. * A **module** refers to a dependencies graph, and may produce one or more build artifacts (libraries, container images…​), that could be published in component registries. * A **repository** is often built by a CI/CD product, using one or more **build workflows.** (a build workflow may build artifacts from multiple repositories and publish the artifacts in different registries, i.e. a real graph). * Sometimes the **pipelines** are files under version control along with the repository. Some SCM systems enforce this pattern within their CI/CD systems. As well as other external CI/CD tools like CircleCI also, but others like Jenkins do not. * The CI granularity also has various levels. For most CI/CD systems, a 'build pipeline' for a project has 'workflows', each workflow has multiple jobs, and 'jobs' (which can run in a given build machine or an "array" of them) is a sequence of 'steps' or 'commands'. The graph can fully represent this hierarchy or not (keep at a given level of granularity, like the workflow), but at the end the real build commands run are those little steps at the end. * On the contrary, a CD pipeline is built from **IaC configuration files** (a set of *IaC template* files under a given framework like Terraform, Azure ARM or Bicep, AWS CloudFormation…​) which specify commands to sync the desired state represented by the IaC configuration with the existing assets in the cloud. So the CD pipeline may have multiple workflows based on jobs that run the tool’s CLI command (`terraform`, `aws`, `az`, `ansible`) to perform the sync or build the assets directly. There are "contain" dependencies (a "parent" node can break down into "children") and "uses" dependencies ("builds", "runs", "publishes", "deploys"…​) that could be represented by the directed graph. ### Asset Discovery The inventory is compiled automatically by the [Xygeni Scanner](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-scanner-reference) (during runs of the `inventory` command) and the integration sensors. The [Inventory Scan](/xygeni-products/application-security-posture-management-aspm/inventory-scanner) processes configuration and source files to gather information about your pipelines and resolving the relationships between each asset. Including common assets like CI/CD systems and other shared tools. {% hint style="info" %} For more information, see [Inventory Scanner](/xygeni-products/application-security-posture-management-aspm/inventory-scanner). {% endhint %} # All Assets The ***All Assets*** page shows the full list of assets for a given project or for a set of projects. Given the wide variety of asset types, the top side bar categorizes related assets into several groups. * Repositories * Images * Components * CI/CD Assets * Delivery Assets * Systems and Tools * Collaborators {% hint style="info" %} A project or group must be selected to access the ***All Assets*** tab {% endhint %}
The ***All Assets*** page displays the following information: * Number of Assets * Number of Assets at Risk. (i.e. with security issues) * Number of systems and tools * Charts displaying total issues by severity, category and category & severity. (With links to specific assets types) * A table with all the assets with some basic information:
The information for each asset: * Risk level * Variation of the Risk Level from the project baseline * Name * System * Category * Asset type * Issues by severity * Tags * Links to details of the asset ### Pivot Graph The Pivot Graph shows the direct relationships with other assets. Clicking on the icon will display the **Pivot Graph** for the selected asset.
{% hint style="info" %} Double-clicking on any asset in this graph will show the pivot graph for the selected asset. {% endhint %} Assets marked with a red circle and a number denote the associated security risk level, indicating potential security threats related to that asset. Clicking on them displays the **details** of the **asset** alongside its issues.
### Findings and Audit Trail You can also select the **Audit Trail tab** to see a timeline of all the security issues. Clicking on the ![](/files/tCGP0VjwczkPOv1JUSaw) icon of any asset will show the **Findings and Audit Trail tabs** as explained above.
# Repositories You can reach the **Repositories Inventory** page either by selecting Projects in the top tab of the **Inventory** page. The Inventory Projects page contents are different depending on if you have selected a group of projects or a single project. ### Group of Projects For a group of projects, the page shows: * Total number of projects in the group * Number of files and total size of the group * Number of commits and daily rate
For every project, it also display information about the number of issues by Asset Category (coloured by highest priority with issues) For each project, detailed information regarding the number of issues organized by asset category is provided. Highlighted by the highest priority in a corresponding color scheme. Clicking on the ![](/files/GRqUWaowklFHne3ba7Hq)icon of every project will show a slide with detailed information about the project.
The **Summary** tab provides general information and offers the option to [download the SBOM](#download-the-sbom) of that project. The other tabs (**SCM**, **Package Manager**, **CI/CD**, **AppSec** and **Deploy**) show the project's assets by category. Selecting a single asset will show additional info about the asset as well as assocaited security risks.
### Single Project In case you have selected a single project into the [Project Selector](/introduction-to-xygeni/xygeni-web-ui-overview#projects-selector), the information displayed will be relative to the selected project: * Number of files and size * Number of commits and daily rate * Creation date, last code change, etc * Team and Contributors of the project * Programming languages
The bottom panel shows aggregated information about the assets of the project. {% hint style="info" %} See [Inventory (panel and slides)](#inventory-panel-and-slides) for further details. {% endhint %} ### Inventory (Panel and Slides) The bottom panel of the Repository Inventory page for a single project shows data about the assets of the selected project, grouped by: * SCM (repository platform, issues by severity, # of commits) * Package Manager (pkg managers used by the project, # of packages, issues by severity) * CI/CD (CI/CD platform, number of pipelines, number of plugins, issues by severity) * AppSec (appsec tools used, etc) * Deploy and provisioning (cloud platforms, number of cloud resources defined in IaC files, issues by severity)
By clicking on a specific asset you will see the details of that asset:
### Inventory (SDLC Graph) Accessing the **SDLC Graph** will present a comprehensive visualization of all assets and their interconnections within the selected project. Utilize the available filters to refine the diagram according to your requirements.
Select an asset to view a detailed slide:
### Download the SBOM Selecting "Download SBOM" allows to generate and download the project SBOM in **Cyclon DX** or **SPDX** formats.
# Components The **Components Inventory** page displays information about all the components (3rd party dependencies) your project or group depends upon. {% hint style="info" %} You can reach the Inventory's **Components** page by selecting the Components tab at the top of any Inventory page. {% endhint %}
The **Components Inventory** page displays the following information: * Total number of components and average per project * Total number of **Direct** dependencies (i.e. those explicitly declared in your package manager's manifest files) * Number of components with security risk associated * Charts about the distribution of components by repository, ecosystem and language * A table with listing all the present components {% hint style="info" %} An important filter is **Dependency Type** (**direct** or **indirect**). This filter allows you to see those dependencies **explicitly declared** and those that are **transitive**. {% endhint %} {% hint style="info" %} Another important filter is **Alert Type**. This filter allows you to find dependencies with **License** warnings, dependencies tagged as with **Malicious** code, or **Obsolete** dependencies. See [Component's Alert Type](/xygeni-products/open-source-security-oss/risks-sca#components-alert-type) for a full description. {% endhint %} Clicking on the icon of any component will open a **Summary** slide with details of the component: * **Ecosystem** (npm, maven, etc) * **Provenance** (the parent component in case of a transitive dependency) * Data about the **publisher** of the component * **Malware Score** * **Latest** available **version** and **publication** **date** * **License** detected and type
The **Issues** tab shows information about **vulnerabilities** of the component.
# CI/CD Assets The **CI/CD Assets Inventory** displays information about CI/CD assets of your project(s), including: * Pipelines * Jobs * Build Scripts (makefiles, pom.xml, etc) * Scripts (shell scripts) {% hint style="info" %} You can reach the **CI/CD Assets Inventory** page by selecting the CI/CD Assets tab at the top of any Inventory page. {% endhint %}
The **CI/CD Assets Inventory** page displays the following information: * Total number of CI/CD assets (and number of assets with security issues) * Distribution by type * CI/CD systems detected * A table with a full list of all the CI/CD Assets {% hint style="info" %} Clicking on the icon will show the [Pivot Graph](/xygeni-products/application-security-posture-management-aspm/inventory/all-assets#pivot-graph) for the selected asset. Clicking on the![](/files/tCGP0VjwczkPOv1JUSaw) icon of any asset will show the [Findings and Audit Trail](/xygeni-products/application-security-posture-management-aspm/inventory/all-assets#findings-and-audit-trail) for the selected asset. {% endhint %} # Delivery Assets The **Delivery Assets Inventory** displays information about the cloud assets in your project(s): * Cloud configuration (dockerfiles, kubernetes deployments, etc) * Cloud resources (any kind of cloud resource) Extensive support of the main frameworks: * **Terraform**: We provide detectors for a wide range of resources across major cloud providers such as AWS, Azure and Google Cloud. * **CloudFormation**: Managed AWS service integration allows for detailed modeling and provisioning of AWS resources. * **ARM** and **Bicep**: Tools for Azure resources, ranging from traditional ARM templates to the newer, more developer-friendly Bicep syntax. * **Kubernetes**: Whether using basic Pods syntax or complex Helm charts, Xygeni ensures your Kubernetes deployments are secure. * **Docker**: Our security extends to Docker environments, including Dockerfiles and docker-compose files that define services, networks, and volumes. {% hint style="info" %} You can reach the **Delivery Assets Inventory** page by selecting the Delivery Assets tab at the top of any Inventory page. {% endhint %}
The **Delivery Assets** Inventory page displays the following information: * Total number of Delivery assets and number of assets with security issues associated * Distribution by type * Cloud Frameworks and Providers detected * A table with a full listing of all the Delivery Assets {% hint style="info" %} Clicking on the icon will show the [Pivot Graph](/xygeni-products/application-security-posture-management-aspm/inventory/all-assets#pivot-graph) for the selected asset. Clicking on the![](/files/tCGP0VjwczkPOv1JUSaw) icon of any asset will show the [Findings and Audit Trail](/xygeni-products/application-security-posture-management-aspm/inventory/all-assets#findings-and-audit-trail) for the selected asset. {% endhint %} # Systems & Tools The **Systems & Tools Inventory** displays information about systems and tools used in your project(s): * **Security tools** used in your **pipelines** (bandit, checkov, Checkmarx, Sonarqube, etc...) * **SCMs** (GitHub, Bitbucket, etc...) * **SCM plugins** * **CI/CD systems** (GitHub, Jenkins, Tekton, etc...) * **CI/CD plugins** {% hint style="info" %} You can reach the **Systems & Tools Inventory** page by selecting the Systems & Tools tab at the top of any Inventory page. {% endhint %}
The **Systems & Tools Inventory** page displays the following information: * Total number of System & Tool assets and number of assets with security issues associated. * Distribution Systems & Tools by type * Distribution of security tools by type * A table with a full listing of all the Systems & Tools {% hint style="info" %} Clicking on the icon will show the [Pivot Graph](/xygeni-products/application-security-posture-management-aspm/inventory/all-assets#pivot-graph) for the selected asset. Clicking on the![](/files/tCGP0VjwczkPOv1JUSaw) icon of any asset will show the [Findings and Audit Trail](/xygeni-products/application-security-posture-management-aspm/inventory/all-assets#findings-and-audit-trail) for the selected asset. {% endhint %} # Collaborators The **Collaborators Inventory** displays information about collaborators of your project(s), including: * **SCM Organizations** * **Users** * **User Groups** {% hint style="info" %} You can reach the **Collaborators Inventory** page by selecting the Collaborators tab at the top of any Inventory page. {% endhint %}
The **Collaborators Inventory** page displays the following information: * Total number of organizations * Total number of user groups * Total number of users * A table with a full listing of all the Collaborators {% hint style="info" %} Click on an asset to see its details. {% endhint %} In the **Findings** tab, you will find detailed information about the collaborator as well as a summary of all the *issues introduced by the selected collaborator*.
In the **Audit Trail** tab, you will find a timeline of all the security issues *introduced by the selected collaborator*.
# Health Check The **Health Check** page displays useful metrics and details about your Xygeni projects.
There are several sections within the **Health Check** page: * [Findings by Category](#findings-by-category) * [Projects](#projects) * [Components](#components) * [System and Tools](#system-and-tools) * [Collaborators](#collaborators) * [Pipelines](#pipelines) * [Coverage](#coverage) ### Findings by Category The **Findings by Category** chart shows a 5-axis spider chart where there is a relevant score for each axis.
### Projects The **Projects** section displays two types of information:
1. **Inactive Projects**, i.e. xygeni projects whose last code change is older than XXXX (TBD) If you click on the **Inactive View >>** link, you will see the inactive projects as well as the applied filters:
By clicking on the ![](/files/0f4Vd6vsupFJS1446qut) icon you will be able to open a 3rd-party ticket on the integrated ticketing system {% hint style="info" %} Visit the [Ticketing systems](/xygeni-administration/platform-administration/integrations/ticketing-systems) page for further details {% endhint %} 2. **Obsolete Branches**, i.e. repository branches whose last code change is older than XXXX (TBD) If you click on the **Obsolete Branches View >>** link, you will see the inactive branches as well as the applied filters:
### Components The **Components** section displays several types of information related to your components.
***Licensing Issues*** refers to the number of components with some kind of issues related to the component's license (mainly, use of a copyleft license). ***With different versions*** refers to the number of components that are used in 2 or more different versions. ***Out of date Versions*** refers to the number of components whose currently used version is more than one year behind the latest available release. ***Obsolete components*** refers to the number of components whose newer version is older than XXX (TBD), possibly meaning that those components are abandoned or out of maintenance and you should consider using another component. If you click on any of the **View >>** links, you will see the components as well as the applied filters:
{% hint style="info" %} A component may be repeated because it appears in several projects because the table lists all the combinations of component-project with the applied filters. {% endhint %} By clicking on the ![](/files/bXdeUPvuSwLLj5Hb40Xp) icon, you will see all the details of the selected component:
### System and Tools The **System and Tools** section displays your SCM system, build/cicd tools. ### Collaborators The **Collaborators** section displays two types of information:
1. **Inactive Collaborators**, i.e. repo users whose last activity is older than XXXX (TBD) If you click on the **Inactive View >>** link, you will see the inactive projects as well as the applied filters:
To open a ticket using the integrated ticketing system, click on the ticketing ![](/files/0f4Vd6vsupFJS1446qut) icon(see [Ticketing systems ](/xygeni-administration/platform-administration/integrations/ticketing-systems)for further details) By clicking on the ![](/files/bXdeUPvuSwLLj5Hb40Xp) icon, you will see all the details of the **inactive collaborator** (latest activity, permissions and issues)
2. **Over-privileged** **Collaborators**, i.e. users whose actions performed do not need granted permissions (TBD) If you click on the **Over privileged View >>** link, you will see the over privileged collaborators as well as the applied filters:
By clicking on the ![](/files/0f4Vd6vsupFJS1446qut) icon you can open a ticket on the integrated ticketing system (see [Ticketing systems ](/xygeni-administration/platform-administration/integrations/ticketing-systems)for further details) By clicking on the ![](/files/bXdeUPvuSwLLj5Hb40Xp) icon, you will see all the details of the over-privileged collaborator (latest activity, permissions, issues and audit trail)
### Pipelines The **Pipelines** section displays information about the total number of pipelines and how many of them are inactive (i.e. not executed in the last XXXX TBD)
If you click on the **View >>** link, you will see the inactive pipelines as well as the applied filters:
By clicking on the ![](/files/0f4Vd6vsupFJS1446qut) you will be able to open a ticket on the integrated ticketing system (see [Ticketing systems ](/xygeni-administration/platform-administration/integrations/ticketing-systems)for further details) ### Coverage The **Coverage** section shows the total number of projects lacking Inventory information, indicating that an Inventory scan was not executed on these projects.
Click the **View >>** link to see non-inventoried projects and applied filters:
### Projects by Size This section provides details on the average project size and the count of projects that exceed this average. Oversized projects often contain large binary artifacts that should not be stored in the SCM. Identifying these artifacts helps in understanding the cause of excessive project size.
Click the **View** link to see **over-sized projects** and the applied filters.
By clicking on the ![](/files/bXdeUPvuSwLLj5Hb40Xp)icon, , you'll find all details of the **oversized project** (including recent activities, file count, size, access level, and all associated assets).
# Inventory Scanner ## Table of Contents 1. [Purpose](#purpose) 2. [Quick Start](#quick_start) 3. [Usage](#usage) 4. [Configuration](/xygeni-products/application-security-posture-management-aspm/inventory-scanner/inventory-scanner-configuration) 5. [Collaborators Scan](/xygeni-products/application-security-posture-management-aspm/inventory-scanner/inventory-collaborators-scan) ### Purpose A **build/deploy pipeline** automates software delivery through a series of processes and tools. These include source control, build tools, continuous integration, automated testing (unit, integration, and regression tests), validation, reporting, and software distribution. The assets involved in build/deploy pipelines are called **SDLC assets**, and in the Xygeni platform an **inventory of SDLC assets** and their relations, for the pipelines used in an organization, are discovered automatically. Security issues and unusual activity events, as captured by the Xygeni platform, In build/deploy pipelines, the assets involved are referred to as **SDLC assets**. The Xygeni platform automatically discovers an **inventory of SDLC assets** and their relationship within an organization's pipelines. Security issues and unusual activity detected by Xygeni is subsequently mapped to the target SDLC assets. Use the `xygeni inventory` CLI command to discover SDLC assets. Discovery involves extracting information from available sources like project and dependency descriptors, build files, CI/CD workflow pipelines, and IaC templates. This process can be enhanced by utilizing the tools APIs to fetch additional data for better qualifying each asset discovered. {% hint style="info" %} For more details about the **inventory** please refer to the [Inventory](/xygeni-products/application-security-posture-management-aspm/inventory) documentation. {% endhint %} ### Quick Start The CLI command to run an inventory scan: ```bash xygeni inventory --dir DIR --upload ``` This scans for assets related to build/deployment pipelines to compile an inventory. Then upload the results to the Xygeni platform unless you use `--no-upload` instead. {% hint style="info" %} **`--dir`** specifies the directory containing the software project to analyze, which may have been cloned from a Git repository. {% endhint %} {% hint style="info" %} There are two ways to run the inventory scanner: 1.- Executing its own specific command ( `xygeni inventory [options]` ). 2.- Executing the general command ( `xygeni scan --run="inventory" [options]` ) will run all available scanners. {% endhint %} {% hint style="info" %} Issues are linked to inventory assets **ONLY** when the scans are run together with the inventory step. It is recommended to run a full [`scan` command](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-operation-modes/single-scan#xygeni-scan) for inventory processing. **Running** the `inventory` scan **alone** should be used for **configuration** and **testing**. {% endhint %} The CLI command produces the following output: ``` Assets found: 69 ┌───────────────────┬─────────────────────────────┬───────────────────────────────────┬────┐ │ Kind │Name │Belongs To │Tags│ ├───────────────────┼─────────────────────────────┼───────────────────────────────────┼────┤ │ code_repo │myorg/ProductXYZ │ │ │ ├───────────────────┼─────────────────────────────┼───────────────────────────────────┼────┤ │ cicd_pipeline │clean-packages │code_repo:github:myorg/ProductXYZ │ │ ├───────────────────┼─────────────────────────────┼───────────────────────────────────┼────┤ │ cicd_pipeline │codeql-analysis │code_repo:github:myorg/ProductXYZ │ │ ├───────────────────┼─────────────────────────────┼───────────────────────────────────┼────┤ │ cicd_pipeline │deploy-maven │code_repo:github:myorg/ProductXYZ │ │ ├───────────────────┼─────────────────────────────┼───────────────────────────────────┼────┤ │ ... ├───────────────────┼─────────────────────────────┼───────────────────────────────────┼────┤ │ dependencies │docs │code_repo:github:myorg/ProductXYZ │ │ ├───────────────────┼─────────────────────────────┼───────────────────────────────────┼────┤ │ security_tool │CodeQL │code_repo:github:myorg/ProductXYZ │ │ ├───────────────────┼─────────────────────────────┼───────────────────────────────────┼────┤ │cloud_configuration│deployment/docker/Dockerfile │code_repo:github:myorg/ProductXYZ │ │ ├───────────────────┼─────────────────────────────┼───────────────────────────────────┼────┤ │ organization │myorg │ │ │ └───────────────────┴─────────────────────────────┴───────────────────────────────────┴────┘ 2023-03-28 18:30:26 [main] WARN InventoryCommand - report uploaded with analysis code: AN-demo@myorg-184 ``` The command has the following options: ``` Usage: xygeni inventory [-huV] [-n=] [-d=] [-e=] [-i=] [-repo=] [--repo-branch=] [--image=] [--image-platform=] [--image-sources=] [--image-scope=] [-o=] [-f=] [--report-columns=] [-c=] [--[no-]conf-download] [--detectors=] [--skip-detectors=] [--never-fail] [@...] Discover SDLC assets for a project. Parameters: [@...] One or more argument files containing options. -n, --name= The software name. -u, --upload Upload report to xygeni server. -h, --help Show this help message and exit. -V, --version Print version information and exit. Input files options: -d, --dir= The directory to analyze (default: current directory). -i, --include= Include patterns, comma-separated (optional). -e, --exclude= Exclude patterns, comma-separated (optional). Example: '**/test/**' Repository options: -repo, --repository= The repository. Either a URL or scm:owner/repo, like 'github:tensorflow/tensorflow' --repo-branch= The repository branch or commit SHA to checkout for analysis. HEAD if unspecified. Container image options: --image= The container image, in registry/repository/image:tag format. Examples: debian, alpine:latest, cgr.dev/chainguard/go, gcr.io/google-containers/python@sha256:fe...4b --image-platform= The image platform in the form os/arch, if image is multi-platform. --image-sources=sources The image source(s) to use, comma-separated in order. Defaults to docker, containerd, podman, remote. --image-scope= How layers are analyzed. One of merged, mergedExceptBase, byLayer, byLayerExceptBase. Default: merged. Output options: -o, --output= Output file. Use 'stdout' or '-' for standard output, 'stderr' for standard error. -f, --format= Output format: none, text, json, csv. --report-columns= Report columns, separated by commas (default: config property report/columns) Collaborators: --include-collaborators If repository collaborators should be added to inventory. Configuration options: -c, --conf= Configuration file (default: xygeni.inventory.yml). --[no-]conf-download Download scanner config? (default: true} --detectors= Comma-separated list of IDs for detectors to run, or 'all' --skip-detectors= Comma-separated list of IDs for detectors to ignore Exit options: --never-fail Do not fail: always exit with code 0, even with flaws or errors. ``` The most important properties are: * **Name** of the project `-n` or `--name`. * Specify either a directory (`-d|--dir`), a repository (`-repo|--repository`), or a container image (`--image`). If none is provided, the current local directory is assumed. * Enable the `--upload` option to upload results. Results are not uploaded by default. * Specify the output file with the `-o` or `--output` option and the format with `-f` or `--format`. If no output file is specified, or if `stdout` or `-` is used, the standard output is the default. Use `--format=none` if you do not want to generate any output. # Inventory Scanner Configuration The Inventory Scanner is configured in the **YAML file** `conf/xygeni.inventory.yml`. The file contains properties to specify: * Files to include/exclude. Defaults are provided for common directories to ignore. * Configuration for report output, including the columns/fields to render. * Configuration for each ecosystem analyzer. * Scan configuration properties like mode = sequential or parallel. Parallel model utilizes threads to run the scan in parallel across files and detectors. {% hint style="info" %} **Command line arguments** have **priority** over **configuration properties** in this file. {% endhint %} ```yaml # Configuration for xygeni Assets Inventory scanner. # Arguments from command line have priority over properties in this file. # Includes: list of glob patterns to include in analysis. # # A pattern could use ** (to match zero or more directories), * (zero or more characters # in a directory or file name), and ? (one character). # Examples: **/*.txt matches all files with 'txt' extension. **/test/** matches all files under any test directory. # # If empty, ALL files will be matched. # The command-line argument -i or --include will be used when specified. # # A file is analyzed when matched by 'includes' AND NOT matched by 'excludes'. includes: [] # Excludes: list of glob patterns to exclude from analysis. # If empty, NO file will be excluded. # The command-line argument -e or --exclude will be used when specified. excludes: - ".git/**/*" - ".vscode/**/*" - "build/**/*" - "dev/**/*" - "**/__pycache__/**/*" - "**/.eggs/**/*" - "**/locales/**/*" - "**/spec/**/*" - "**/specs/**/*" - "**/test/**/*" - "**/tests/**/*" - "**/mock/**/*" - "**/mocks/**/*" - "**/integration/**/*" - "**/node_modules/**/*" - "**/bower_components/**/*" - "**/.xygeni.*.json" # mode=sequential runs analyzers sequentially; # mode=parallel runs analyzers in multiple threads, when analyzer is capable of parallel runs. mode: parallel # Timeout, in seconds, for the analysis to complete. 0 or negative means no timeout. timeout: 600 # Config for reporters report: - format: json prettyPrint: true - format: csv # Allowed values: "id", "kind", "scope", "name", "qualifiedName", "belongsTo", "fullyResolved", "path", "createdAt", "updatedAt", "tags", "properties" columns: [ "kind", "name", "qualifiedName", "belongsTo", "fullyResolved", "path", "createdAt", "updatedAt", "tags", "properties"] # Order specification. 'default' lists by kind first, then by name. # One of 'default' or 'id'. sort: default - format: text # Allowed values: "id", "kind", "scope", "name", "qualifiedName", "belongsTo", "fullyResolved", "path", "createdAt", "updatedAt", "tags", "properties" columns: [ "kind", "name", "belongsTo", "tags" ] # Order specification. 'default' lists by kind first, then by name. # One of 'default' or 'id'. sort: default # The style for table borders. # One of 'full', 'none', 'outside', 'inside', 'horizontal', 'vertical', 'topbottom'. # Use 'default' for border that works well for the underlying OS. borders: full # The block characters to use: 'ascii' (use '+', '|', '-' and '=') # or 'utf8' for UTF-8 block characters. # Use 'default' for the encoding that works best for the underlying OS. bordersEncoding: utf8 # The detectors to use for discovering SDLC assets # are configured in resource files under inventory/*.yml # List of detectors to run: IDs. # Leave empty for no restriction (all detectors not disabled will be chosen). # Command-line property --detectors overrides this. runDetectors: [] # Same format as runDetectors, but for skipping the selected detectors. # Leave empty for no restriction (all detectors not disabled will be chosen). # Command-line property --skip-detectors overrides this. skipDetectors: [] ``` ### Inventory Assets Detectors Configuration Assets from various ecosystems are managed by each designated detector. These detectors handle relevant files and other sources, and can invoke an API, if available, to gather more details about the asset. The following ecosystems are supported: * Source Code Management (SCM) systems: GitHub, Azure Devops, BitBucket, GitLab. * Dependencies Management systems for multiple language ecosystems, including Package managers and Component Registries like NPM, Maven, Gradle, Bower, Nuget, pip, go.mod, RubyGems, PHP Composer, Swift Package Manager, CocoaPods, Carthage, Cargo, etc. * CI/CD tools: The systems provided by the SCM systems listed above plus specialized CI/CD systems like Jenkins, CircleCI or Travis CI. * Security tools: A variety of security tools, configured in the `xygeni.security_tools.yml` file. * Cloud assets include technologies like containers, container orchestrators, and Infrastructure-as-Code (IaC) frameworks. Examples are Dockerfiles, docker-compose, Kubernetes, Terraform, Bicep, Azure Resource Manager, CloudFormation, and Ansible. * Collaborators: it is not active by default. See how [Inventory Collaborators Scan](/xygeni-products/application-security-posture-management-aspm/inventory-scanner/inventory-collaborators-scan) can be run and what organization assets are gathered. # Inventory Collaborators Scan The Inventory Scan may include an analysis of administrative users, contributors, and collaborators associated with the repository. This Collaborator analysis helps identify inactive or overprivileged users, tracing potential risks they introduce. ### Collaborators analysis The collaborators analysis will categorize groups and users based on the following criteria: * List all SCM user accounts with direct or inherited read, write, or manage permissions on the repository. * Identify all SCM groups those user belong to. * All git users not related to a SCM account but have commits on the git history. (any branch) {% hint style="info" %} By default, only user activity from the past 12 months is considered. {% endhint %} ### Navigate to Collaborators activity Collaborators analysis tab can be found in SLDC Inventory page: {% hint style="info" %} (Visit the [Collaborators Inventory](/xygeni-products/application-security-posture-management-aspm/inventory/collaborators) page) {% endhint %}
### How to run a Collaborators analysis Example: ```shell xygeni inventory --dir DIR --format json --output INVENTORY.json --include-collaborators ``` # Importing reports from 3rd party tools Xygeni ASPM consolidates findings from many third-party security tools. There are **three ingestion paths**; pick whichever fits the tool and your pipeline best. They share the same loader+converter pipeline downstream, so findings normalise into the same Xygeni format regardless of how they arrived. ## The three ingestion modes ### 1. Convert + upload (default) The scanner reads a report file the tool already produced (JSON, XML, SARIF, …), converts it to Xygeni's standard format, and uploads it. ```bash xygeni report-upload -n MyApp -f sast-checkmarx -r reports/checkmarx.SAST.xml ``` Use this when the tool can write to disk (almost all of them) and your pipeline already runs the tool and stages its output. See [Report Upload](#report_upload) below for the full command reference. ### 2. Pull — fetch from the tool's API The scanner calls the tool's API, fetches findings, and routes the result through the same loader+converter pipeline. No intermediate file on disk; credentials read from environment variables and redacted from logs. ```bash export SONARCLOUD_URL=https://sonarcloud.io export SONARCLOUD_TOKEN=squ_*** xygeni report-upload --pull -f sast-sonarcloud \ --selector project_key=acme/web --selector branch=main ``` Use this when the tool exposes a findings API and you'd rather not stage intermediate files. Available for SonarQube/SonarCloud, Kiuwan, Checkmarx One, Prisma Cloud, and Wiz CNAPP. See [Pull-mode fetch](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) for the walkthrough and one worked example per tool. ### 3. Push — inbound webhook The tool calls Xygeni's webhook on scan completion. Configured tool-side (no CLI invocation), with optional HMAC signature verification. ``` POST https://api.xygeni.io/api/v1/ingest/webhook X-Xygeni-Format: X-Xygeni-Token: ``` Use this when the tool emits outbound webhooks and you'd rather not run anything CLI-side. A dedicated setup guide per supported tool will be added to this section as each webhook adapter ships. ### Picking a mode | If… | Use | | ------------------------------------------------------------------- | ------------------ | | The tool produces a file your CI already collects | **convert+upload** | | You'd rather not stage files; the tool has an API | **pull** | | You want the tool to push on scan completion without CLI invocation | **push** | The same tool can support multiple modes — e.g. SonarCloud works in convert+upload mode (with a downloaded `issues/search` JSON) and in pull mode (with the scanner driving the API itself). *** ## Report Upload The `report-upload` command is the entry point for both convert+upload and pull modes. It validates reports, normalizes findings, and converts them to the Xygeni standard format. Findings then flow through prioritization, filtering, workflow, and remediation like any other Xygeni scan output. {% hint style="info" %} Typically, Xygeni scans upload their findings right away. The `report-upload` command exists so external scanner output (or older Xygeni scan files staged for later) can be uploaded the same way. {% endhint %} ### Syntax ```bash xygeni report-upload [--show-formats] [--directory=] [--name=] [--prop=name:value [--prop=name:value]...] [--never-fail] [--[no-]upload] # convert+upload mode (default): supply --report; repeat for multiple files --report= [--format=] [--log-file=] [--output= [--compact]] ... # pull mode: --pull replaces --report; --selector and --filter pass per-scan values --pull --format= [--selector=k=v]... [--filter=k=v]... [@...] Converts and uploads an external tool or xygeni scan reports into Xygeni platform. Parameters: [@...] One or more argument files containing options. -s, --show-formats Show the formats supported. -n, --name= The software name. Inferred from directory when not provided. -d, --basedir= Base directory for resolving relative paths. Default is the current working directory. -p, --prop=name:value Properties for the software. Name of standard properties are: business_value (or bizval), architecture (or arch), business_area (or bizarea), product_unit (or product), and provider. business_value should be one of: CRITICAL, HIGH, MEDIUM, LOW, INFO. Additional custom properties may be added. --never-fail Do not fail: always exit with code 0, even when report conversion or upload fails. --[no-]upload Upload reports to server? (default: true) Use --no-upload for testing report conversion. Reports to upload (convert+upload mode): -r, --report= the report file to upload. Use '-' or 'stdin' for standard input. -f, --format= the format / type of the report to upload. Use to get the available values, when autocomplete is active. Optional. When not given, it will be inferred from the report. -o, --output= file for writing the output in Xygeni format. Use '-' or 'stdout' for console output. Optional. No output when not given. --compact Use compact output (default: pretty-print). -l, --log-file= The xygeni scan logfile to upload (optional). Pull mode: --pull Fetch the report from the tool API instead of reading a file. Requires --format pointing to a registry entry with a pull: block. --selector=k=v Per-scan identifier passed to the fetcher (e.g. project_key=acme, branch=main, org_id=org-1234). Repeatable. --filter=k=v Tool-specific filter (e.g. severity=CRITICAL,HIGH; status=open; time_range_days=7). Repeatable. ``` {% hint style="info" %} This command replaces the deprecated `xygeni util scan-upload` command. {% endhint %} To list the supported third-party tools and formats supported, run `xygeni report-upload --show-formats`. The `-n | --name` option provides the project name the reports uploaded will be assigned to. It will be inferred if not provided. For a single xygeni report it will be extracted from the report metadata. Multiple convert+upload reports can be provided in one invocation, so the `-r|--report`, `-f|--format` and `-o|--output` flags may be repeated. Pull mode takes exactly one `--format`; combine multiple pulls by issuing multiple commands. The `-l|--log-file` only will be used for xygeni scan results and will be ignored otherwise. The formats available are listed in the [external scanners support](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/external-scanners-supported) section and broken down per category — see [DAST Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/dast-report-import), [SAST Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/sast-report-import), [SCA Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/sca-report-import), [IaC Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/iac-report-import), [Secrets Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/secrets-report-import), and [Inventory Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/inventory-report-import). {% hint style="info" %} It is recommended to specify the format of the input report source using the `--format` option. However, for the majority of inputs, the `report-upload` function can automatically determine the input format.\ \ Only in certain cases report type inference may fail due to ambiguity. For example, with the SARIF format which can convey different scan types, or with multi-scan files generated by certain tools. {% endhint %} The scan *logfile* could be optionally uploaded to Xygeni, using the `--log-file` parameter. The command returns **`0 (OK)`** exit code when the upload succeeded, or a non-zero exit code when there is an error. When the upload is successful, the scan code is printed as the output of the command. {% hint style="info" %} Please note that scan results are processed asynchronously so results may not be immediately available after the command concludes. {% endhint %} ### Examples * List the supported formats: ```bash xygeni report-upload --show-formats ``` * Upload a Checkmarx SAST report (xml format): ```bash xygeni report-upload --name=MyApp --format=sast-checkmarx --report=rep/checkmarx.SAST.xml ``` * Upload two previously generated xygeni reports: ```bash xygeni report-upload -n MyApp \ -r rep/xygeni.deps.json -l=rep/xygeni.deps.log \ -r rep/xygeni.secrets.json -l rep/xygeni.secrets.log ``` * Convert a Snyk report into xygeni, but do not upload. Useful for verifying the conversion before wiring it into a CI/CD pipeline: ```bash xygeni report-upload -n MyApp -r rep/snyk.json -f sca-snyk -o xygeni.sca.json --no-upload ``` * Upload SCA, SAST and IaC findings from a Checkmarx One report exported using `cx results show`: ```bash xygeni report-upload -n MyApp \ -r rep/cxOne_results.json -f sast-checkmarx-one-results \ -r rep/cxOne_results.json -f sca-checkmarx-one-results \ -r rep/cxOne_results.json -f iac-checkmarx-one-results ``` * Pull SonarCloud SAST findings via the API instead of staging a JSON file: ```bash export SONARCLOUD_URL=https://sonarcloud.io export SONARCLOUD_TOKEN=squ_*** xygeni report-upload --pull -f sast-sonarcloud \ --selector project_key=acme/web --selector branch=main \ --filter severity=CRITICAL,HIGH ``` See [Pull-mode fetch](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) for a full walkthrough of pull mode with one worked example per supported tool. {% hint style="info" %} When a tool report contains findings from different domains (code vulnerabilities, IaC flaws, hardcoded secrets…​), the same file with different formats could be repeated to extract and upload the findings of interest, as the Checkmarx One example above shows. {% endhint %} # Pull-mode fetch Pull mode lets the Xygeni scanner call a third-party tool's API directly, fetch the findings, and route them through the same loader+converter pipeline that processes file uploads. No intermediate report file on disk; credentials read from environment variables; resolved auth headers and tokens redacted from logs. When you'd use it over [convert+upload](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools#report_upload): * The tool exposes a documented findings API and your pipeline doesn't already collect a report file. * You'd rather not stage credentials inside a CI artifact or a checked-in JSON. * You want one CLI invocation to drive both the fetch and the conversion. When **not** to use it: * The tool only writes to disk — keep using convert+upload. * The tool actively pushes to consumers — see the [push (webhook) mode](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools#the-three-ingestion-modes); the per-adapter setup guide will be added to this section as each webhook integration ships. ## How to invoke ```bash xygeni report-upload --pull --format \ --selector key=value [--selector ...] \ --filter key=value [--filter ...] \ [--name ] [--no-upload] [--output ] ``` * `--pull` switches the command from reading `--report` files to fetching from the API. * `--format` (exactly one) selects the registry entry; the entry must declare a `pull:` block (i.e. one of the formats listed below). * `--selector` carries **per-scan identifiers** the tool needs — project key, branch, application name, organization, scan id, tenant. Always required for tools that scope findings to a project. * `--filter` carries **tool-specific findings filters** — severity, status, time window, cloud platform. Optional; each fetcher documents its own filter keys. * `--no-upload` runs the fetch + conversion but skips the upload to Xygeni. Pair with `--output ` to inspect the converted payload before wiring the command into CI. ## Credentials and environment variables Each tool reads its credentials from environment variables. The scanner refuses to start if a referenced variable is unset (fail-closed); it never embeds the resolved secret into the converted output; and it registers the resolved value with the log redactor so any subsequent log line that would print it shows `***` instead. The naming convention is `_URL`, `_TOKEN` / `_CLIENT_ID` / `_CLIENT_SECRET`, etc. — the exact set is listed per-tool below. {% hint style="info" %} You can also pass `-Dname=value` on the Java command line as a fall-through when an environment variable can't be exported (e.g. some containerised runners). The framework checks env vars first, then Java system properties. {% endhint %} ## Worked examples per tool ### SonarQube / SonarCloud Two registry entries — `sast-sonarcloud` (bearer-token auth) and `sast-sonarqube` (basic auth with the API token as the username and an empty password, per SonarQube Server's traditional auth scheme). **SonarCloud** ```bash export SONARCLOUD_URL=https://sonarcloud.io export SONARCLOUD_TOKEN=squ_xxxxxxxxxxxxxxxxxxxxxxxxxx xygeni report-upload --name MyApp --pull \ -f sast-sonarcloud \ --selector project_key=acme/web \ --selector branch=main \ --selector organization=acme # SonarCloud only; required for org-scoped projects ``` **SonarQube Server** ```bash export SONARQUBE_URL=https://sonarqube.internal.example.com export SONARQUBE_TOKEN=sq-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xygeni report-upload --name MyApp --pull \ -f sast-sonarqube \ --selector project_key=acme:web \ --selector branch=main ``` Both invocations pull security issues from `/api/issues/search` and security hotspots from `/api/hotspots/search`, merge and deduplicate, and write a single document in the same shape the existing `sast-sonarqube` / `sast-sonarcloud` loaders consume for file uploads. Pagination, retry/backoff and log redaction are handled by the framework. | Selector | Required | Notes | | -------------- | :------: | ---------------------------------- | | `project_key` | yes | SonarQube / SonarCloud project key | | `branch` | no | Branch analysis to query | | `pullRequest` | no | PR analysis id | | `organization` | no | SonarCloud only | | Filter | Notes | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `severity` | Comma-separated severities (e.g. `HIGH,CRITICAL`). Applied to issues; hotspots use a different vulnerability-probability filter that isn't currently forwarded. | | `status` | Comma-separated for issues. Hotspots accept only `TO_REVIEW` / `REVIEWED` — when multiple values are supplied, only the first is forwarded to that endpoint. | ### Kiuwan Two registry entries: * `sast-kiuwan` — **file upload** of the XML report produced by the Kiuwan Local Analyzer custom `ExportRule`. Documented in the [Report upload for Kiuwan](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/external-scanners-supported/report-upload-for-kiuwan) page; recommended only if you already have that pipeline set up. * `sast-kiuwan-api` — **pull mode**, calling Kiuwan's native REST API. **Recommended for new integrations**: no Kiuwan-side install, no Local Analyzer custom rule, no quality-model edits. Carries source/sink data-flow detail that SARIF / CSV exports drop. ```bash export KIUWAN_URL=https://api.kiuwan.com # SaaS; on-prem tenants use their own URL export KIUWAN_USER= export KIUWAN_TOKEN= xygeni report-upload --name MyApp --pull \ -f sast-kiuwan-api \ --selector application='My Application' ``` With an explicit analysis + filters: ```bash xygeni report-upload --name MyApp --pull \ -f sast-kiuwan-api \ --selector application='My Application' \ --selector analysisCode=A-1234567890123 \ --filter priority='High,Very high' ``` | Selector | Required | Notes | | -------------- | :------: | ------------------------------------------------------------------------- | | `application` | yes | Kiuwan application name | | `analysisCode` | no | Specific scan to fetch. Default: result of `/applications/last_analysis`. | | Filter | Notes | | ---------------- | ------------------------------------------------------------------------------------------------- | | `priority` | Comma-separated. `Very low,Low,Normal,High,Very high`. | | `characteristic` | Comma-separated. Defaults to `Security` (SAST scope); pass to widen, e.g. `Security,Reliability`. | | `language` | Comma-separated tool-defined language list (e.g. `java,javascript`). | | `muted` | `true` / `false`. | Auth is HTTP Basic with the Kiuwan API user code as the username and the token as the password. ### Checkmarx One — SAST + SCA + IaC Pull mode is wired on **three** registry entries — `sast-checkmarx-one`, `sca-checkmarx-one`, `iac-checkmarx-one`. They share a single fetcher; Checkmarx One's `/api/results` endpoint returns all three engines' findings in one document and each entry's converter slices its own engine out. ```bash export CHECKMARX_URL=https://ast.checkmarx.net # SaaS regions: ast / eu.ast / anz.ast / etc. export CHECKMARX_CLIENT_ID= export CHECKMARX_CLIENT_SECRET= # SAST findings: xygeni report-upload --pull -f sast-checkmarx-one \ --selector tenant=acme --selector project_name='My App' # SCA findings (same project, refetched independently): xygeni report-upload --pull -f sca-checkmarx-one \ --selector tenant=acme --selector project_name='My App' # IaC (KICS) findings: xygeni report-upload --pull -f iac-checkmarx-one \ --selector tenant=acme --selector project_name='My App' ``` With an explicit scan + filters: ```bash xygeni report-upload --pull -f sast-checkmarx-one \ --selector tenant=acme \ --selector project_id=11111111-2222-3333-4444-555555555555 \ --selector scan_id=99999999-8888-7777-6666-555555555555 \ --filter severity='HIGH,MEDIUM' ``` | Selector | Required | Notes | | -------------- | :------: | -------------------------------------------------------------------------- | | `tenant` | yes | Checkmarx One tenant name; interpolated into the OAuth2 token endpoint URL | | `project_id` | one of | UUID of the Checkmarx One project | | `project_name` | one of | Human-readable name; resolved to `project_id` via `/api/projects?name=…` | | `scan_id` | no | Specific scan to fetch. Default: latest scan for the project. | | Filter | Notes | | ---------- | ------------------------------------------------------------------ | | `severity` | Comma-separated `HIGH,MEDIUM,LOW,INFO` | | `state` | Result state enum (`TO_VERIFY`, `NOT_EXPLOITABLE`, `CONFIRMED`, …) | | `status` | `NEW`, `RECURRENT`, `FIXED` | Auth: OAuth2 client credentials. The framework caches the access token by its declared `expires_in` and refreshes it automatically. ### Prisma Cloud — CSPM alerts + asset inventory Two registry entries — `iac-prisma-cloud` (CSPM security alerts / policy violations) and `inventory-prisma-cloud` (cloud asset inventory). One fetcher drives both; each entry picks its endpoint internally. ```bash export PRISMACLOUD_URL=https://api.prismacloud.io # api.eu.prismacloud.io, api.anz.prismacloud.io, … export PRISMACLOUD_ACCESS_KEY= export PRISMACLOUD_SECRET_KEY= # Security alerts (CSPM policy violations): xygeni report-upload --pull -f iac-prisma-cloud # Cloud asset inventory: xygeni report-upload --pull -f inventory-prisma-cloud ``` With filters: ```bash xygeni report-upload --pull -f iac-prisma-cloud \ --filter status=open \ --filter severity=critical,high \ --filter cloud=aws,azure \ --filter time_range_days=7 ``` | Filter | Applies to | Notes | | -------------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `time_range_days` | both | Window length. Default `30` for alerts, `1` for inventory. | | `cloud` | both | Comma-separated cloud providers (`aws`, `azure`, `gcp`, `alibaba_cloud`, `oci`). | | `status` | alerts | Single value: `open`, `dismissed`, `resolved`, `snoozed`. Default `open`. | | `severity` | alerts | Comma-separated `critical,high,medium,low,informational`. | | `resource_type` | inventory | Comma-separated resource types (e.g. `aws_ec2_instance,gcp_compute_instance`). | | `rql` | inventory | Raw RQL query used verbatim (escape hatch — disables the `cloud` / `resource_type` composition). Example: `--filter rql="config from cloud.resource where finding.type = 'CVE'"`. | | `with_resource_json` | inventory | `true` (default) embeds the full provider-specific resource JSON in each item; set to `false` for a leaner payload. | Inventory uses Prisma Cloud's [RQL (Resource Query Language)](https://docs.prismacloud.io/en/enterprise-edition/content-collections/search-and-investigate/rql-reference/rql-reference). Auth is handled by the fetcher (POST `/login` for an `x-redlock-auth` token; transparent re-auth on 401); the registry declares `auth.type: basic` only to flow the access key + secret key through env-var resolution and log redaction. ### Wiz CNAPP Four registry entries — `iac-wiz-issues`, `sca-wiz-cnapp`, `iac-wiz-config`, `inventory-wiz-cnapp`. A single fetcher drives all four via per-entry `selectorDefaults.mode`. Wiz is the first GraphQL fetcher in the pull framework; the GraphQL endpoint and OAuth2 token URL are both configurable so any region (US / EU / Gov) works without code changes. ```bash export WIZ_API_URL=https://api.us1.app.wiz.io/graphql # full GraphQL endpoint export WIZ_CLIENT_ID= export WIZ_CLIENT_SECRET= # Optional — defaults to Cognito; legacy Auth0 tenants use https://auth.wiz.io/oauth/token # export WIZ_TOKEN_URL=https://auth.app.wiz.io/oauth/token # Issues (Toxic Combinations, Threats, Cloud Misconfigurations): xygeni report-upload --pull -f iac-wiz-issues # CVEs detected on cloud workloads: xygeni report-upload --pull -f sca-wiz-cnapp --filter severity=CRITICAL,HIGH # CSPM policy violations: xygeni report-upload --pull -f iac-wiz-config --filter result=FAIL,ERROR # Cloud asset inventory: xygeni report-upload --pull -f inventory-wiz-cnapp --filter cloud_platform=AWS ``` | Filter | Applies to | Notes | | ---------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | `status` | issues / vulnerabilities / config\_findings | Filtering the resolution state | | `severity` | issues / vulnerabilities / config\_findings | Wiz severity enum. The fetcher remaps the filter key to `vendorSeverity` for the vulnerabilities mode (Wiz schema quirk) | | `type` | issues / cloud\_resources | Issue category for issues; Wiz resource type for inventory | | `result` | config\_findings | `FAIL`, `ERROR` | | `cloud_platform` | cloud\_resources | `AWS`, `AZURE`, `GCP`, … | | `page_size` | all | Page size — clamped to Wiz's documented 500 max | Auth: OAuth2 client credentials with the `audience=wiz-api` claim. The framework caches the access token by `expires_in` and refreshes it automatically; the token URL is configurable so the same registry entry works against both Cognito-backed and legacy Auth0-backed Wiz tenants. ### Bright Security (Bright DAST) One registry entry — `dast-brightsec`. It pulls findings from Bright's REST API (`GET /api/v1/scans/{id}/issues`) and normalises them to the Xygeni DAST report. Bright's API is **regional**, so set `BRIGHTSEC_URL` to your cluster (e.g. `https://eu.brightsec.com` or `https://app.brightsec.com`). Auth is `Authorization: Api-Key ` — a personal, project, or organization API key works. **Required API key scopes** (least-privilege, read-only): `user` (mandatory for API authorization), `projects:read`, `scans:read`, and `issues:read`. The integration only *reads* completed scans — it never runs, edits, or deletes anything in Bright, so no `scans:run` / `*:write` / `auth-objects` scopes are needed. If your organization restricts visibility, you may also need `org:read`. ```bash export BRIGHTSEC_URL=https://eu.brightsec.com # your Bright regional cluster export BRIGHTSEC_TOKEN= # By scan id (from the scan URL or the API): xygeni report-upload --name MyApp --pull \ -f dast-brightsec \ --selector scan_id=iQ6pnfbHBNZqeVcRvob9CT # By project + scan name (resolves the latest COMPLETED scan with that name in that project): xygeni report-upload --name MyApp --pull \ -f dast-brightsec \ --selector project='My Project' \ --selector scan='Nightly authenticated scan' ``` The fetcher accepts only a scan in the **completed** (`done`) state — a running or stopped scan is rejected, so a partial finding set is never uploaded. It composes the scan and project metadata with the issues, so the report carries the scan target, timing, statistics, and the Bright project name. | Selector | Required | Notes | | ------------------ | :------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `scan_id` | one of | A Bright scan id. | | `project` + `scan` | one of | Bright **project name** and **scan name**; resolves the latest completed scan with that name. An application often has several scans (different navigations / use cases) — name the one you want. | No tool-specific `--filter` keys. {% hint style="info" %} **Branch.** Bright DAST findings have no VCS branch. When you don't pass `--branch`, the upload uses `unknown`. **Project name.** With no `--name`, the Xygeni project is taken from the Bright **project name**. {% endhint %} {% hint style="warning" %} **File alternative (reduced).** You can upload a saved API issues file — the JSON from `GET /api/v1/scans/{id}/issues` — with `-f dast-brightsec -r issues.json`. The findings are complete, but a bare file carries **no scan/project metadata or statistics** (the scanner logs a warning); use pull mode for a full report. The Bright **UI "summary export"** is *not* supported — it lacks the target URL and HTTP request/response evidence, and the loader rejects it with guidance to use pull mode or the `/issues` JSON. {% endhint %} ## Dry-run and inspecting the converted payload Before wiring the command into CI, run it once with `--no-upload --output ` to inspect the converted JSON: ```bash xygeni report-upload --pull -f sast-sonarcloud \ --selector project_key=acme/web --selector branch=main \ --no-upload --output /tmp/sonarcloud-converted.json ``` The output file holds the same payload that would have been uploaded — useful for verifying severity mapping, project name inference, or filter coverage. ## Troubleshooting **"No value for `${env:X}` — set the Java system property `-DX=…` or export the env var X"** The scanner refuses to run with an unresolved secret. Export the variable in the same shell that invokes `xygeni`, or pass `-DX=value` on the Java command line if your runner can't export environment variables. **"Format '' has no pull: block configured"** The format you passed to `-f` exists as a convert+upload entry but doesn't yet support pull mode. Either drop `--pull` and supply `--report`, or pick a format from the supported list above. **"--pull requires exactly one --format"** Pull mode takes one format per invocation. If you need to fetch from multiple tools, issue multiple commands. **HTTP 401 / 403** The token doesn't have permission for the resource you asked for. The error message includes the path that failed — verify the project key / scan id / tenant against the tool's UI, and check the token's scope. **Retries exhausted** The fetcher retries transient failures (HTTP 5xx, network errors) with exponential backoff. If retries exhaust, the tool's API is likely down — check the tool's status page and rerun. Pull mode is idempotent; re-invoking after a transient failure is safe. # SCA Report Import Software Composition Analysis findings — vulnerabilities in third-party dependencies (open source and proprietary). ## How to import a report 1. **Download** and configure the CLI Scanner. See [these guidelines](https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-installation). 2. Use the xygeni **report-upload command**: **Convert + upload** (a report file produced by the tool): ```bash xygeni report-upload -n= --report="path/to/report_file" -f= [--branch="branch"] ``` **Pull** (where supported — see the [Pull mode](#pull-mode) section below): ```bash xygeni report-upload -n= --pull -f= --selector key=value [--filter key=value] ```

If the --branch parameter is not set, the branch will be marked as "Unknown".

3. Move to the [**Xygeni dashboard**](https://in.xygeni.io) to see the results. ## Supported formats | Format | Tool | Description | | --------------------------- | -------------------------- | --------------------------------------------------------------- | | `sca-sarif` | \ | Component vulnerabilities detected by an SCA tool, SARIF format | | `sca-appscan-asoc` | HCL AppScan on Cloud / 360 | AppScan on Cloud / 360 SCA report, in XML format | | `sca-checkmarx` | Checkmarx SCA | CxSCA report, in JSON format | | `sca-checkmarx-one` | Checkmarx One | SCA scanner of Checkmarx One, in JSON format | | `sca-checkmarx-one-results` | Checkmarx One | SCA scanner of Checkmarx One, exported using `cx results show` | | `sca-snyk` | Snyk | Snyk SCA report, in JSON format | | `sca-trivy` | Trivy | Trivy SCA report, in JSON format | | `sca-wiz-cnapp` | Wiz CNAPP | Wiz CNAPP vulnerability findings export, in JSON format | | `sca-wiz-cli` | Wiz CLI | Wiz CLI scan report (vulnerabilities), in JSON format | ## Pull mode The following formats also support [pull mode](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) — the scanner calls the tool's API directly instead of reading a report file from disk: | Format | Tool | Auth | | ------------------- | ------------- | ------------------------------------------------- | | `sca-checkmarx-one` | Checkmarx One | OAuth2 client credentials | | `sca-wiz-cnapp` | Wiz CNAPP | OAuth2 client credentials with `audience=wiz-api` | See [Pull-mode fetch](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) for the per-tool walkthrough (env-var setup, selectors, filters). ## Dashboard results If the entered name matches an existing project, the vulnerabilities in the report will be added to that project in a new tab. If the project does not exist, a new project will be created. {% hint style="info" %} If you are ingesting a report to an existing project and the vulnerabilities do not appear, check the branch of the project. If you have not set the `--branch` parameter when executing the command, Xygeni could have marked the branch as "Unknown". {% endhint %} # SAST Report Import Static Application Security Testing findings — code vulnerabilities detected by source-code analysis. ## How to import a report 1. **Download** and configure the CLI Scanner. See [these guidelines](https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-installation). 2. Use the xygeni **report-upload command**: **Convert + upload** (a report file produced by the tool): ```bash xygeni report-upload -n= --report="path/to/report_file" -f= [--branch="branch"] ``` **Pull** (where supported — see the [Pull mode](#pull-mode) section below): ```bash xygeni report-upload -n= --pull -f= --selector key=value [--filter key=value] ```

If the --branch parameter is not set, the branch will be marked as "Unknown".

3. Move to the [**Xygeni dashboard**](https://in.xygeni.io) to see the results. ## Supported formats | Format | Tool | Description | | ---------------------------- | -------------------------- | --------------------------------------------------------------------- | | `sast-sarif` | \ | Code vulnerabilities detected by a SAST tool, in SARIF format | | `sast-appscan-xml` | HCL AppScan Source | AppScan Source SAST report, in XML format (legacy referential format) | | `sast-appscan-asoc` | HCL AppScan on Cloud / 360 | AppScan on Cloud / 360 SAST report, in XML format | | `sast-brakeman` | Brakeman | Brakeman SAST report for Ruby, in JSON format | | `sast-checkmarx` | Checkmarx | CxSAST JSON report | | `sast-checkmarx-xml` | Checkmarx | CxSAST XML report | | `sast-checkmarx-one` | Checkmarx One | SAST scanner of Checkmarx One, in JSON format | | `sast-checkmarx-one-results` | Checkmarx One | SAST scanner of Checkmarx One, exported using `cx results show` | | `sast-fortify-fpr` | Fortify | Fortify SAST report, in .fpr or .fvdl format | | `sast-fortify-xml` | Fortify | Fortify SAST XML report | | `sast-kiuwan` | Kiuwan | Kiuwan SAST XML report (via Local Analyzer + ExportRule) | | `sast-kiuwan-api` | Kiuwan | Kiuwan SAST findings via the native REST API (pull mode only) | | `sast-opengrep` | OpenGrep | OpenGrep SAST report, in JSON format | | `sast-sonarcloud` | SonarCloud | SonarCloud SAST JSON report | | `sast-sonarserver` | SonarServer | SonarServer SAST JSON report | | `sast-sonarqube` | SonarQube | SonarQube JSON report | ## Pull mode The following formats also support [pull mode](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) — the scanner calls the tool's API directly instead of reading a report file from disk: | Format | Tool | Auth | | -------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `sast-sonarcloud` | SonarCloud | Bearer token | | `sast-sonarqube` | SonarQube | Basic auth (token-as-username) | | `sast-kiuwan-api` | Kiuwan | Basic auth (API user + token) — **recommended for new Kiuwan integrations**; see the [Report upload for Kiuwan](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/external-scanners-supported/report-upload-for-kiuwan) page | | `sast-checkmarx-one` | Checkmarx One | OAuth2 client credentials | See [Pull-mode fetch](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) for the per-tool walkthrough (env-var setup, selectors, filters). {% hint style="info" %} For Sonar, the convert+upload JSON can be downloaded from the [SonarCloud Web API GET api/issues/search](https://sonarcloud.io/web_api/api/issues/search?deprecated=false\§ion=params) endpoint, using `additionalField=_all` to get all additional fields. If the number of issues exceeds 500, paginate the request — or use pull mode, which does this automatically. {% endhint %} ## Dashboard results If the entered name matches an existing project, the vulnerabilities in the report will be added to that project in a new tab. If the project does not exist, a new project will be created. {% hint style="info" %} If you are ingesting a report to an existing project and the vulnerabilities do not appear, check the branch of the project. If you have not set the `--branch` parameter when executing the command, Xygeni could have marked the branch as "Unknown". {% endhint %} # IaC Flaws Report Import Infrastructure-as-Code security findings — misconfigurations in Terraform, CloudFormation, Kubernetes manifests, and equivalent IaC artifacts, plus Cloud Security Posture Management (CSPM) findings on the deployed resources. ## How to import a report 1. **Download** and configure the CLI Scanner. See [these guidelines](https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-installation). 2. Use the xygeni **report-upload command**: **Convert + upload** (a report file produced by the tool): ```bash xygeni report-upload -n= --report="path/to/report_file" -f= [--branch="branch"] ``` **Pull** (where supported — see the [Pull mode](#pull-mode) section below): ```bash xygeni report-upload -n= --pull -f= [--selector key=value] [--filter key=value] ```

If the --branch parameter is not set, the branch will be marked as "Unknown".

3. Move to the [**Xygeni dashboard**](https://in.xygeni.io) to see the results. ## Supported formats | Format | Tool | Description | | --------------------------- | ------------- | ----------------------------------------------------------------------- | | `iac-sarif` | \ | IaC vulnerabilities detected by an IaC tool, in SARIF format | | `iac-checkov` | Checkov | Checkov IaC scanner, JSON format | | `iac-checkmarx` | Checkmarx | IaC scanner of Checkmarx, in JSON format | | `iac-checkmarx-one` | Checkmarx One | IaC scanner of Checkmarx One, in JSON format | | `iac-checkmarx-one-results` | Checkmarx One | IaC scanner of Checkmarx One, exported using `cx results show` | | `iac-kics` | KICS | IaC vulnerabilities detected by KICS, in JSON format | | `iac-prisma-cloud` | Prisma Cloud | Prisma Cloud CSPM security alerts (policy violations), JSON | | `iac-wiz-issues` | Wiz CNAPP | Wiz issues — Toxic Combinations, Threats, Cloud Misconfigurations, JSON | | `iac-wiz-config` | Wiz CNAPP | Wiz cloud configuration findings (CSPM), JSON | ## Pull mode The following formats also support [pull mode](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) — the scanner calls the tool's API directly instead of reading a report file from disk: | Format | Tool | Auth | | ------------------- | ------------- | ------------------------------------------------- | | `iac-checkmarx-one` | Checkmarx One | OAuth2 client credentials | | `iac-prisma-cloud` | Prisma Cloud | Custom `/login` token (Prisma `x-redlock-auth`) | | `iac-wiz-issues` | Wiz CNAPP | OAuth2 client credentials with `audience=wiz-api` | | `iac-wiz-config` | Wiz CNAPP | OAuth2 client credentials with `audience=wiz-api` | See [Pull-mode fetch](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) for the per-tool walkthrough (env-var setup, selectors, filters). ## Dashboard results If the entered name matches an existing project, the vulnerabilities in the report will be added to that project in a new tab. If the project does not exist, a new project will be created. {% hint style="info" %} If you are ingesting a report to an existing project and the vulnerabilities do not appear, check the branch of the project. If you have not set the `--branch` parameter when executing the command, Xygeni could have marked the branch as "Unknown". {% endhint %} # Secrets Report Import Hard-coded credentials and tokens detected by secret-scanning tools. ## How to import a report 1. **Download** and configure the CLI Scanner. See [these guidelines](https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-installation). 2. Use the xygeni **report-upload command**: ```bash xygeni report-upload -n= --report="path/to/report_file" -f= [--branch="branch"] ```

If the --branch parameter is not set, the branch will be marked as "Unknown".

3. Move to the [**Xygeni dashboard**](https://in.xygeni.io) to see the results. ## Supported formats | Format | Tool | Description | | -------------------- | ---------- | ---------------------------------------------------- | | `secrets-sarif` | \ | Secrets detected by a secrets tool, in SARIF format | | `secrets-gitleaks` | GitLeaks | Secrets detected by GitLeaks, in JSON format | | `secrets-trufflehog` | TruffleHog | Secrets detected by TruffleHog, in JSON-lines format | | `secrets-wiz-cli` | Wiz CLI | Wiz CLI scan report (secrets), in JSON format | ## Pull mode None of the currently supported secret-scanning tools expose a findings API the scanner can pull from — all entries above use **convert + upload** only. See [Pull-mode fetch](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) for the list of tools that do support pull mode. ## Dashboard results If the entered name matches an existing project, the secrets in the report will be added to that project in a new tab. If the project does not exist, a new project will be created. {% hint style="info" %} If you are ingesting a report to an existing project and the secrets do not appear, check the branch of the project. If you have not set the `--branch` parameter when executing the command, Xygeni could have marked the branch as "Unknown". {% endhint %} # DAST Report Import ## How to import a report 1. **Download** and configure the CLI Scanner. See [these guidelines](https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-installation). 2. Use the xygeni **report upload command**: ``` xygeni report-upload -n= --report="path/to/report_file" -f= [--brach="brach"] ``` {% hint style="info" %} If the --branch parameter is not set, the branch will be marked as "Unknown". {% endhint %} 3. Move to the [**Xygeni dashboard** ](https://in.xygeni.io)to see the results ## Supported formats Xygeni ASPM supports the following formats for DAST reports: | Format | Tool | Description | | ----------------- | --------------- | ---------------------------------------------------------------------------------- | | dast-acunetix-360 | Acunetix | Acunetix 360 DAST report, in JSON format | | dast-acunetix-xml | Acunetix | Acunetix DAST report, in XML format | | dast-zap | OWASP Zap | ZAP DAST report, in XML or JSON format | | dast-brightsec | Bright Security | Bright (Bright DAST) findings via the Bright REST API, or a saved scan-issues JSON | {% hint style="info" %} **Bright Security** is fetched directly from its REST API (no report file needed) — see [Connecting Bright Security](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch#bright-security-bright-dast) under Pull-mode fetch. You can also upload a saved `GET /api/v1/scans/{id}/issues` JSON with `-f dast-brightsec`. {% endhint %} ## Dashboard Results If the entered name matches an existing project, the vulnerabilities in the report will be added to that project in a new tab called DAST. If, however, the project does not exist, a new project will be created with the vulnerabilities in the report. {% hint style="info" %} If you are ingesting a report to an existing project and the vulnerabilities do not appear, check the branch of the project. If you have not set the --branch parameter when executing the command, Xygeni could have marked the Branch as "Unknown". {% endhint %} ### Xygeni DAST Prioritization Funnel
The **DAST Prioritization Funnel** progressively organizes all dynamically detected security findings by applying risk-based filters that reduce the total volume of vulnerabilities down to the most critical ones. Its purpose is to remove noise, focus on externally exploitable risks, and help security teams prioritize remediation efforts saving hours of time . * **All Issues**: Contains the full set of vulnerabilities detected by DAST with no filtering applied, representing the 100% baseline. * **Exposed**: Filters only the assets that are publicly reachable from the Internet. * **Unauthenticated**: Focuses on vulnerabilities that can be exploited without credentials. * **Business Value**: Prioritizes issues affecting critical business workflows. ### Example of DAST vulnerability Slider
# Inventory Report Import Cloud asset inventory — the workloads, containers, serverless functions, VPCs and managed services in your cloud accounts. Inventory imports give Xygeni the asset graph that other findings (IaC misconfig, SAST, SCA) can then be correlated against. ## How to import a report 1. **Download** and configure the CLI Scanner. See [these guidelines](https://docs.xygeni.io/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-installation). 2. Use the xygeni **report-upload command**: **Convert + upload** (a report file produced by the tool): ```bash xygeni report-upload -n= --report="path/to/report_file" -f= [--branch="branch"] ``` **Pull** (where supported — see the [Pull mode](#pull-mode) section below): ```bash xygeni report-upload -n= --pull -f= [--filter key=value] ``` 3. Move to the [**Xygeni dashboard**](https://in.xygeni.io) to see the results. ## Supported formats | Format | Tool | Description | | ------------------------ | ------------ | ------------------------------------------------------ | | `inventory-trivy-k8s` | Trivy | Trivy Kubernetes cluster inventory, in JSON format | | `inventory-prisma-cloud` | Prisma Cloud | Prisma Cloud cloud resources inventory, in JSON format | | `inventory-wiz-cnapp` | Wiz CNAPP | Wiz CNAPP cloud resources inventory, in JSON format | ## Pull mode The following formats also support [pull mode](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) — the scanner calls the tool's API directly instead of reading a report file from disk: | Format | Tool | Auth | | ------------------------ | ------------ | ------------------------------------------------------------------------------------- | | `inventory-prisma-cloud` | Prisma Cloud | Custom `/login` token (Prisma `x-redlock-auth`) — uses the RQL config-search endpoint | | `inventory-wiz-cnapp` | Wiz CNAPP | OAuth2 client credentials with `audience=wiz-api` | See [Pull-mode fetch](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) for the per-tool walkthrough (env-var setup, selectors, filters). ## Dashboard results If the entered name matches an existing project, the assets in the report will be linked to that project. If the project does not exist, a new project will be created. Cloud resources from the inventory feed populate the [Inventory](/xygeni-products/application-security-posture-management-aspm/inventory) section of the ASPM UI; correlation with other findings (IaC, SAST, SCA) happens automatically as those findings reference the same provider unique IDs. # External Scanners Supported The `xygeni report-upload` command normalizes and uploads findings from third-party security tools to the Xygeni platform. The input reports are typically export formats (JSON, XML) and may follow common exchange formats like *Static Analysis Results Interchange Format* ([SARIF](https://sarifweb.azurewebsites.net/)) or GitLab’s [Security Report Schemas](https://gitlab.com/gitlab-org/security-products/security-report-schemas). The following is the list of third-party security scanners and report formats supported. The list of supported formats can also be listed by running the *`report-upload --show-formats`* command within the Xygeni scanner. Formats and tools are listed in alphabetical order. Xygeni does not endorse any vendor or tool. Go to the [report-upload command reference](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools) for the command syntax, and to [Pull-mode fetch](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) for the API-driven alternative to file uploads. For per-category import walkthroughs (each with its own format table and pull-mode pointers), see: * [SCA Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/sca-report-import) * [SAST Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/sast-report-import) * [IaC Flaws Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/iac-report-import) * [Secrets Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/secrets-report-import) * [DAST Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/dast-report-import) * [Inventory Report Import](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/inventory-report-import) ### SCA (Software Composition Analysis) | Format | Tool | Description | | ------------------------- | ----------------------------- | --------------------------------------------------------------- | | sca-sarif | \ | Component vulnerabilities detected by a SCA tool, SARIF format | | sca-appscan-asoc | HCL AppScan on Cloud / 360 | AppScan on Cloud / 360 SCA report, in XML format | | sca-checkmarx | Checkmarx SCA | CxSCA report, in JSON format | | sca-checkmarx-one | Checkmarx One | SCA scanner of Checkmarx One, in JSON format | | sca-checkmarx-one-results | Checkmarx One | SCA scanner of Checkmarx One, exported using 'cx results show' | | sca-cyclonedx | \ | CycloneDX SBOM, in JSON or XML format | | sca-snyk | Snyk | Snyk SCA report, in JSON format | | sca-sonatype | Sonatype Lifecycle (Nexus IQ) | Sonatype Lifecycle Policy Evaluation Report, in JSON format | | sca-sonatype-cir | Sonatype Lifecycle (Nexus IQ) | Sonatype Lifecycle Component Information Report, in JSON format | | sca-spdx | \ | SPDX SBOM, in JSON or tag-value format | | sca-trivy | Trivy | Trivy SCA report, in JSON format | | sca-wiz-cli | Wiz CLI | Wiz CLI scan report (vulnerabilities), in JSON format | | sca-wiz-cnapp | Wiz CNAPP | Wiz CNAPP vulnerability findings export, in JSON format | ### SAST (Software Application Security Testing) | Format | Tool | Description | | -------------------------- | -------------------------- | --------------------------------------------------------------------- | | sast-sarif | \ | Code vulnerabilities detected by a SAST tool, in SARIF format | | sast-appscan-xml | HCL AppScan Source | AppScan Source SAST report, in XML format (legacy referential format) | | sast-appscan-asoc | HCL AppScan on Cloud / 360 | AppScan on Cloud / 360 SAST report, in XML format | | sast-brakeman | Brakeman | Brakeman SAST report for Ruby, in JSON format | | sast-checkmarx | Checkmarx | CxSAST JSON report | | sast-checkmarx-xml | Checkmarx | CxSAST XML report | | sast-checkmarx-one | Checkmarx One | SAST scanner of Checkmarx One, in JSON format | | sast-checkmarx-one-results | Checkmarx One | SAST scanner of Checkmarx One, exported using 'cx results show' | | sast-fortify-fpr | Fortify | Fortify SAST report, in .fpr or .fvdl format | | sast-fortify-xml | Fortify | Fortify SAST XML report | | sast-kiuwan | Kiuwan | Kiuwan SAST XML report | | sast-opengrep | OpenGrep | OpenGrep SAST report, in JSON format | | sast-sonarcloud | SonarCloud | SonarCloud SAST JSON report | | sast-sonarqube | SonarQube | SonarQube JSON report | {% hint style="info" %} For Kiuwan, exporting the findings to a local file needs special configuration, as documented in [xygeni-extensions - Report upload for Kiuwan](https://github.com/xygeni/xygeni-extensions/blob/main/extensions/report_upload/kiuwan/README.md) {% endhint %} {% hint style="info" %} AppScan SARIF output (AppScan Source v10.3+, AppScan on Cloud SAST, AppScan CodeSweep) is supported via the generic `sast-sarif` format with an AppScan-specific transformer — no separate format id is needed. {% endhint %} {% hint style="info" %} For Sonar, json report can be downloaded from issues/search endpoint at [SonarCloud Web API GET api/issues/search](https://sonarcloud.io/web_api/api/issues/search?deprecated=false\§ion=params), using the parameter `additionalField=_all` to get all additional fields from the project. If maximum number of issues exceed the limit (500), query should be paginated, …​ {% endhint %} ### IaC Flaws | Format | Tool | Description | | ------------------------- | ------------------- | -------------------------------------------------------------- | | iac-sarif | \ | IaC vulnerabilities detected by a IaC tool, in SARIF format | | iac-checkov | Checkov | Checkov IaC scanner, JSON format | | iac-checkmarx | Checkmarx | IaC scanner of Checkmarx, in JSON format | | iac-checkmarx-one | Checkmarx One | IaC scanner of Checkmarx One, in JSON format | | iac-checkmarx-one-results | Checkmarx One | IaC scanner of Checkmarx One, exported using 'cx results show' | | iac-kics | KICS | IaC vulnerabilities detected by KICS, in JSON format | | iac-prisma-cloud | Prisma Cloud (CSPM) | Prisma Cloud CSPM security alerts, in JSON format | | iac-wiz-config | Wiz CNAPP | Wiz CNAPP cloud configuration findings, in JSON format | | iac-wiz-issues | Wiz CNAPP | Wiz CNAPP issues export, in JSON format | ### Secret Leaks | Format | Tool | Description | | ------------------ | ---------- | ---------------------------------------------------- | | secrets-sarif | \ | Secrets detected by a secrets tool, in SARIF format | | secrets-gitleaks | GitLeaks | Secrets detected by GitLeaks, in JSON format | | secrets-trufflehog | TruffleHog | Secrets detected by TruffleHog, in JSON-lines format | | secrets-wiz-cli | Wiz CLI | Wiz CLI scan report (secrets), in JSON format | ### DAST (Dynamic Application Security Testing) | Format | Tool | Description | | ----------------- | -------------------------- | --------------------------------------------------------------------------- | | dast-acunetix-360 | Acunetix 360 | Acunetix 360 DAST report, in JSON format | | dast-acunetix-xml | Acunetix | Acunetix DAST report, in XML format | | dast-appscan-xml | HCL AppScan Standard/Ent. | AppScan Standard/Enterprise DAST report, in XML format (legacy referential) | | dast-appscan-asoc | HCL AppScan on Cloud / 360 | AppScan on Cloud / 360 DAST report, in XML format (flat format) | | dast-xguardian | XGuardian | XGuardian DAST report, in XML format | | dast-zap | OWASP Zap | ZAP DAST report, in XML or JSON format | ### Inventory | Format | Tool | Description | | ---------------------- | ------------------- | -------------------------------------------------------------- | | deps-cyclonedx | \ | CycloneDX SBOM as dependency inventory, in JSON or XML format | | deps-spdx | \ | SPDX SBOM as dependency inventory, in JSON or tag-value format | | inventory-prisma-cloud | Prisma Cloud (CSPM) | Prisma Cloud cloud asset inventory, in JSON format | | inventory-trivy-k8s | Trivy | Trivy Kubernetes cluster inventory, in JSON format | | inventory-wiz-cnapp | Wiz CNAPP | Wiz CNAPP cloud resources inventory, in JSON format | {% hint style="info" %} For native Kubernetes workload inventory (Deployments, StatefulSets, DaemonSets, Pods, Services, RBAC, NetworkPolicies, container images and their hierarchy) compatible with Xygeni's `inventory.1` format, use the [Kubernetes Inventory Exporter](https://github.com/xygeni/xygeni-extensions/blob/main/extensions/exporter/kubinv/README.md) — a Python script in `xygeni-extensions` that produces an `InventoryReport` JSON ready for upload with `report-upload --format inventory-xygeni`. {% endhint %} {% hint style="info" %} CycloneDX and SPDX SBOMs are accepted both as **dependency inventory** (`deps-cyclonedx`, `deps-spdx`) and as **SCA findings** input (`sca-cyclonedx`, `sca-spdx`). Use the inventory form to register components without their vulnerabilities; use the SCA form to ingest vulnerabilities declared in the SBOM. {% endhint %} # Report upload for Kiuwan [Kiuwan](https://www.kiuwan.com/) is an application security platform whose Static Application Security Testing (SAST) product detects security vulnerabilities in source code. Xygeni can ingest Kiuwan findings via two paths — pick whichever matches your Kiuwan deployment. ## Option A — Pull mode (recommended) The scanner calls Kiuwan's native REST API directly, fetches the latest analysis, and uploads it. **No Kiuwan-side install, no Local Analyzer custom rule, no quality-model edits.** Carries source/sink data-flow detail that SARIF / CSV exports drop. ```bash export KIUWAN_URL=https://api.kiuwan.com # SaaS; on-prem tenants use their own URL export KIUWAN_USER= export KIUWAN_TOKEN= xygeni report-upload --name MyApp --pull \ -f sast-kiuwan-api \ --selector application='My Application' ``` With an explicit analysis + filters: ```bash xygeni report-upload --name MyApp --pull \ -f sast-kiuwan-api \ --selector application='My Application' \ --selector analysisCode=A-1234567890123 \ --filter priority='High,Very high' ``` **Selectors** | Selector | Required | Notes | | -------------- | :------: | ------------------------------------------------------------------------- | | `application` | yes | Kiuwan application name | | `analysisCode` | no | Specific scan to fetch. Default: result of `/applications/last_analysis`. | **Filters** | Filter | Notes | | ---------------- | ------------------------------------------------------------------------------------------------- | | `priority` | Comma-separated. `Very low,Low,Normal,High,Very high`. | | `characteristic` | Comma-separated. Defaults to `Security` (SAST scope); pass to widen, e.g. `Security,Reliability`. | | `language` | Comma-separated tool-defined language list (e.g. `java,javascript`). | | `muted` | `true` / `false`. | Auth is HTTP Basic with the Kiuwan API user code as the username and the token as the password. See [Pull-mode fetch](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/pull-mode-fetch) for the framework-level context (env-var redaction, retry/backoff, dry-run with `--no-upload`). ## Option B — ExportRule + Local Analyzer (legacy, file-based) This is the original integration path. It applies to on-premise Kiuwan installations where you'd rather not give the scanner outbound network access, or where the **`sast-kiuwan-api`** pull-mode credentials aren't available. The Kiuwan Local Analyzer doesn't expose a built-in option to write findings to a local file. Xygeni provides a custom rule — [ExportRule](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/external-scanners-supported/report-upload-for-kiuwan/exportrule-.java) — that registers a post-process task to export the findings at the end of the analysis, using the standard `xml_issues` report format (the same format the Local Analyzer uses to send findings to the Kiuwan cloud service). ### Setup #### 1. Compile the extraction rule (optional) The rule JAR and rule descriptors are already provided in the [`dist`](https://github.com/xygeni/xygeni-extensions/blob/main/extensions/exporter/kiuwan/dist) directory for your convenience. To rebuild them yourself: ```bash $ cd extensions/exporter/kiuwan $ mvn package ``` The compilation copies the jar into `dist` and runs the [generate\_rules.sh](https://github.com/xygeni/xygeni-extensions/blob/main/extensions/exporter/kiuwan/bin/generate_rules.sh) script to create a rule descriptor per technology under [`dist/rules`](https://github.com/xygeni/xygeni-extensions/blob/main/extensions/exporter/kiuwan/dist/rules). {% hint style="info" %} Kiuwan only allows one technology per rule descriptor, so a descriptor is generated for each. The `OPT.CRITERIUM_VALUE.LANGUAGE_PARSER.` is set on each rule descriptor. {% endhint %} #### 2. Install the rules and jar file Upload the [`kiuwan-export-rule jar`](https://github.com/xygeni/xygeni-extensions/blob/main/extensions/exporter/kiuwan/dist/kiuwan-export-rule-1.0.jar) and the [rule descriptors](https://github.com/xygeni/xygeni-extensions/blob/main/extensions/exporter/kiuwan/dist/rules) to your Kiuwan tenant. See Kiuwan's [Installing custom rules created with Kiuwan Rule Developer](https://www.kiuwan.com/docs/display/K5/Installing+custom+rules+created+with+Kiuwan+Rule+Developer) for the full procedure. You also need to add the imported rules to an existing model so the Local Analyzer downloads them. Once rules and jar are uploaded and added to the Kiuwan model, the Local Analyzer will execute the export rule whenever the output-report environment variable is set. #### 3. Run the scan Run the Kiuwan Local Analyzer with the path to the report file in the `KIUWAN_JSON_REPORT` environment variable: ```bash $ KIUWAN_JSON_REPORT=/path/to/my/report.xml $ agent.sh -s DIR -n NAME -c ... Report file available at: /path/to/my/report.xml ``` {% hint style="info" %} The export rule does nothing if `KIUWAN_JSON_REPORT` is not given. The path can be absolute or relative — relative paths are resolved against `$HOME` (the OS user home directory). {% endhint %} #### 4. Upload the Kiuwan report to Xygeni ```bash xygeni report-upload --report=/path/to/my/report.xml --format sast-kiuwan ``` ## When to pick which * **New integrations, SaaS Kiuwan tenants, or any tenant where the scanner can reach `api.kiuwan.com`** → use **Option A (pull mode)**. Nothing to install Kiuwan-side; richer findings. * **Air-gapped Local Analyzer with no outbound network access**, or **existing pipelines that already publish `report.xml` to a shared location** → use **Option B (ExportRule)**. The ExportRule custom rule and its build artifacts live in [`xygeni/xygeni-extensions`](https://github.com/xygeni/xygeni-extensions/tree/main/extensions/exporter/kiuwan) — see that repo for the Java source, the rule descriptors generator, and the prebuilt jar. # ExportRule (.java) ```java package ext.kiuwan; import com.als.core.AbstractRule; import com.als.core.RuleContext; import com.als.core.io.IOUtils; import com.als.core.renderers.RenderException; import com.als.core.renderers.Renderer; import com.als.core.renderers.XmlIssuesRenderer; import com.als.core.util.StringUtil; import com.als.core.util.SysUtils; import com.optimyth.qaking.task.OneShotTask; import java.io.File; import java.io.IOException; import java.io.OutputStream; /** * ExportRule is a pseudo-rule that exports the Kiuwan SAST report to XML ('xml_issues' format), * for importing the raw scanner findings into other tools, like ASOC / ASPM. *

* The rule does not create any issue. It simply registers a {@link ReportExportTask} as a POST_PROCESS task * to be run at the end of the analysis. This task exports the report to XML, using the 'KIUWAN_JSON_REPORT' * property (either environment variable or java system property). * * @author lrodriguez * @version 30-Apr-2024 (lrodriguez) */ public class ExportRule extends AbstractRule { @Override public boolean accept(String technology, RuleContext ctx) { return true; // valid for any tech } @Override public void initialize(RuleContext ctx) { super.initialize(ctx); ReportExportTask exporter = new ReportExportTask(); ctx.getAnalysisTasks().addOneShotTask(exporter); } /** * The task that runs at the end of the analysis, for dumping the XML report * to the file specified in the $KIUWAN_JSON_REPORT environment variable. */ public static class ReportExportTask implements OneShotTask { private final String report = SysUtils.getProperty("KIUWAN_JSON_REPORT"); private final boolean isActive = StringUtil.hasText(report); @Override public boolean isActiveTask() { return isActive; } @Override public void start(RuleContext ctx) { if(!isActive) return; System.out.println(ExportRule.class.getName() + " active, will export report to: " + report); } @Override public void end(RuleContext ctx) { if(!isActive) return; File reportFile = getReportFile(); try(OutputStream os = IOUtils.openOutputStream(reportFile, false)) { getRenderer().render(ctx.getReport(), os, reportFile.getParentFile(), ctx); System.out.println("Report file available at: " + reportFile.getAbsolutePath()); } catch (IOException | RenderException e) { System.err.println("Error: cannot write report file "+ reportFile + ": " + e.getMessage()); } } private File getReportFile() { File reportFile = new File(report); if(!reportFile.isAbsolute()) { // Use $HOME as base directory if relative path is provided. // Often $HOME is writable even on CI/CD runners. reportFile = new File(SysUtils.getUserHome(), report); } // ensure the directory for report exists // noinspection ResultOfMethodCallIgnored reportFile.getParentFile().mkdirs(); return reportFile; } /** XmlIssuesRenderer with simple configuration. We do not render muted issues, but you may change this. */ private Renderer getRenderer() { XmlIssuesRenderer renderer = new XmlIssuesRenderer(); renderer.setIndentPositions(2); renderer.setRenderMutedIssues(false); // ignore muted renderer.setRenderChecks(true); renderer.setRenderCheckDetails(true); renderer.setRenderErrors(true); renderer.setRenderIssuesStatistics(true); return renderer; } } } ``` # Code Security (SAST) ### **Overview** Xygeni's **Static Application Security Testing (SAST)** tool provides in-depth analysis of your source code to uncover security vulnerabilities and malicious patterns **before code is compiled or deployed**. By scanning source files directly, Xygeni ensures early detection of flaws that could be exploited in production, enabling secure-by-design software development practices. Through integration with DevOps workflows and developer environments, Xygeni’s SAST scanner delivers actionable insights, prioritizes critical findings and facilitates **quick remediations** based on secure coding guidelines and regulatory standards. ### **Protect Applications from Malicious Code and Vulnerabilities Early** Modern applications often combine large volumes of custom code with third-party libraries. This increases the risk of hidden vulnerabilities or **intentionally inserted malicious logic**. Xygeni's SAST tool is built to uncover: * Insecure functions and APIs (e.g., use of `eval()`, hardcoded credentials, or unsafe deserialization). * Input validation flaws (e.g., XSS, SQL injection, command injection). * Misuse of cryptographic functions. * Data leakage risks due to improper handling of secrets. * Suspicious patterns indicative of **malware or backdoors** in source files. The scanner covers multiple languages and frameworks commonly used in web, backend, and cloud-native environments. For more information regarding Code Security, refer to these sections: * [Code Security User Interface Guide](/xygeni-products/code-security-cs/cs-user-interface-guide) * [Risks (SAST)](/xygeni-products/code-security-cs/cs-user-interface-guide/risks-sast) * [Malicious Code](/xygeni-products/code-security-cs/cs-user-interface-guide/risks-sast/malicious-code) * [Malware Scanner](/xygeni-products/code-security-cs/malware-scanner) * [SAST Scanner](/xygeni-products/code-security-cs/ci-cd-scanner) ## Related * [API Security](/xygeni-products/api-security) — static analysis of the API surface specifically. It shares SAST's parsers but reasons about endpoints rather than code paths, and applies **sensitivity tagging** (PII / PCI / PHI / credential) to parameters, response fields, and DTOs. Those tags are what let a data-exposure flaw be judged by *what* is exposed and to whom, and they carry into the Risk Graph so a SAST finding can be correlated with the endpoint that reaches it. * [API Security Scanner Configuration](/xygeni-products/api-security/api-security-scanner/api-security-scanner-configuration) — sensitivity classification settings and the correlation rules that compose findings across scans. # Code Security (SAST) User Interface Guide Code Security (SAST) User Interface can be accessed by selecting the SAST option under the [Risks](/xygeni-products/application-security-posture-management-aspm/all-risks) tab. The Code Security section includes the following content: * [SAST Risks](/xygeni-products/code-security-cs/cs-user-interface-guide/risks-sast) : A summary of all SAST security issues. * [**Malicious Code**](/xygeni-products/code-security-cs/cs-user-interface-guide/risks-sast/malicious-code) : Details of any potentially malicious code identified in your source code. SAST Risks:

# SAST Risks The **Risks (SAST) page** can be accesed by selecting the SAST option in the [**Risks**](/xygeni-products/application-security-posture-management-aspm/all-risks) tab. This tab offers an in-depth overview of all SAST security issues, clearly presented for ease of assessment. {% hint style="info" %} Xygeni provides two functionalities related to SAST scanning 1. Xygeni provides a [SAST Scanner](/xygeni-products/code-security-cs/ci-cd-scanner) that can perform static analysis over your application code. Please visit [Xygeni SAST Scanner](/xygeni-products/code-security-cs/ci-cd-scanner) for further information. 2. Xygeni also provides the functionality to [import scan results from 3rd-party tools](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools). This way, you can integrate 3rd-party data into Xygeni and benefit from the [Xygeni ASPM](/xygeni-products/application-security-posture-management-aspm) functionalities. The **supported SAST scanners** are listed in the [supported SAST scanners](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/external-scanners-supported#sast_software_application_security_testing) section. {% endhint %} By default, this page will display all the SAT issues, regardless of the tool that found the issues (Xygeni SAST Scanner or any other 3rd party tool). If you click on **More filter fields**, you can find the **Tools** filter where you can select a tool and only those issues reported by the selected tool will be displayed. {% hint style="info" %} You can reach the **Risks (SAST)** results under Code Security >> Risks (SAST) section. {% endhint %}
In the issues table, click on an issue to view its details.
# Malicious SAST Issues The **SAST Risk page** also displays SAST issues that have been marked as specificaly malicious.
{% hint style="info" %} To only view malicious SAST issues in the table, enter the CWE-506 filter pattern {% endhint %} In the issues table, by clicking on the ![](/files/4H3LZniNOmmCt33ndqmx) icon of any issue, you will see the details of the issue.
You can view all the evidence of malicious activity under the Malware evidence tab of the detail.
# Malware Scanner ## Table of Contents 1. [Purpose](#purpose) 2. [Quick Start](#quick_start) 3. [Usage](#usage) 4. [Malware Detectors](#detectors) ### Purpose A compromised software supply chain can result in alterations to the software, potentially serving as a vector for malware distribution. Allowing malicious actors to introduce harmful code, unintended behaviors and backdoors. **Malicious Code Evidence** consists of indicators of malicious software (malware) identified through static analysis of the target software. Analyzing software for potential supply chain vulnerabilities complements software security reviews with automation. Adversaries often employ obfuscation techniques to conceal their alterations from human review, but these methods can also provide evidence of their behaviour. See ([Common types of Malware found in Open Source Packages](/xygeni-products/open-source-security-oss/malware-early-warning-mew/common-types-of-malware-found-in-open-source-packages)) Based on the collected evidence, a `maliciousness score` is calculated for the software being analyzed. If sufficient evidence is gathered, the software may be classified as potentially malicious. The **Malware Scanner** is a tool that analyzes software project files and reports the evidence detected by the active malware policies assigned to the project. Detected evidence can be uploaded to Xygeni platform for consolidation and for enabling response actions. {% hint style="info" %} The `maliciousness score` of the project depends on the total **quantity** and **severity** of the **evidence identified**. {% endhint %} ### Quick Start Use the following command to run and upload the results of the **Malware Scan** to the **Xygeni Platform.** This command will scan the current directory for the target project. ```bash xygeni malware -n MyProject --upload ``` {% hint style="info" %} Malware scanner can be run in two different ways: * Running its own specific command ( `xygeni malware [options]` ) * Running the general command ( `xygeni scan --run="malware" [options]` ) {% endhint %} Export malware evidence with critical severity to CSV for review or to import findings into other tools: ```bash xygeni malware -n MyProject --detectors critical \ --format csv --output MyProject.malware.csv ``` ### Usage Use the `xygeni malware [options]` command to execute the Malware Scanner. To view all available options, use the `--help` flag: ```bash xygeni malware --help ``` The most important properties are: * **Name** of the Xygeni Project `-n` or `--name`. * **Input source** to analyze. Either specify a **directory** with: `-d` or `--dir` or specify a **repository** using: `--repo`. The scan will analyze the current working directory when no target is specified. * **Upload** results to the service `--upload`. By default, results are not uploaded. * **Output file** (`-o` or `--output`) and **format** (`-f` or `--format`). If no output file is specified (or stdout / - are used), the standard output is used. Use `--format=none` for no output. * Specify what detectors to run with the `--detectors` / `--skip-detectors` options. A common use-case is to consider only issues with high or critical severity with `--detectors=high`. * The *resource kinds* to be scanned could also be tailored with the `--kinds` / `--skip-kinds` options. ```bash Configuration options: --custom-detectors-dir= Directory with custom detectors. --detectors= Comma-separated list of IDs for detectors to run, PRIORITY or 'all' --skip-detectors= Comma-separated list of IDs for detectors to ignore, or PRIORITY --kinds= Resource kinds to scan (execution, file, network, _package, registry, sensitive_data, system, all). --skip-kinds= Resource kinds to ignore (execution, file, network, _package, registry, sensitive_data, system, all). ``` ### Malware Detectors Please refer to the [Malware detectors](/xygeni-products/code-security-cs/malware-scanner/malware-detectors) documentation for information regarding this topic. # Malware Scanner Configuration ### Malware Scanner Configuration The [**Malware Scanner**](/xygeni-products/code-security-cs/malware-scanner) is configured in the **YAML file** `conf/xygeni.malware.yml` : ```yaml # Configuration for xygeni Malware evidences scanner. # Arguments from command line have priority over properties in this file. # Includes: list of glob patterns to include in analysis. # # A pattern could use ** (to match zero or more directories), * (zero or more characters # in a directory or file name), and ? (one character). # Examples: **/*.txt matches all files with 'txt' extension. **/test/** matches all files under any test directory. # # If empty, ALL files will be matched. # The command-line argument -i or --include will be used when specified. # # A file is analyzed when matched by 'includes' AND NOT matched by 'excludes'. includes: [] # Excludes: list of glob patterns to exclude from analysis. # If empty, NO file will be excluded. # The command-line argument -e or --exclude will be used when specified. excludes: - ".git/**/*" - ".vscode/**/*" - "build/**/*" - "dev/**/*" - "**/__pycache__/**/*" - "**/.eggs/**/*" - "**/bower_components/**/*" - "**/integration/**/*" - "**/locales/**/*" - "**/spec/**/*" - "**/specs/**/*" - "**/test/**/*" - "**/tests/**/*" - "**/mock/**/*" - "**/mocks/**/*" - "**/node_modules/**/*" - "**/.xygeni.*.json" # mode=sequential runs analyzers sequentially; # mode=parallel runs analyzers in multiple threads, when analyzer is capable of parallel runs. mode: sequential # Config for reporters report: - format: json prettyPrint: true - format: sarif prettyPrint: true - format: csv # Allowed values: kind, hash, severity, confidence, detector, file, beginLine, endLine, code, tags columns: [ "severity", "kind", "hash", "resource", "detector", "file", "beginLine", "endLine", "confidence", "tags" ] # Order specification. 'default' lists highest severe first, then by type, file and line. # One of 'default', 'type', 'exposure' or 'severity-confidence'. Blank for no sort sort: default - format: text # Allowed values: kind, hash, type, severity, confidence, detector, file, beginLine, endLine, code, tags columns: [ "severity", "kind", "detector", "file", "beginLine", "tags" ] # Order specification. 'default' lists highest severe first, then by type, file and line. # One of 'default', 'type', 'exposure' or 'severity-confidence'. Blank for no sort sort: default # The style for table borders. # One of 'full', 'none', 'outside', 'inside', 'horizontal', 'vertical', 'topbottom'. # Use 'default' for border that works well for the underlying OS. borders: full # The block characters to use: 'ascii' (use '+', '|', '-' and '=') # or 'utf8' for UTF-8 block characters. # Use 'default' for the encoding that works best for the underlying OS. bordersEncoding: utf8 # The detectors to use for detecting Malware evidences # are configured in resource files under malware/*.yml # List of detectors to run: IDs or severity. # runDetectors: ['high'] will run all detectors with severity 'high' or greater. # runDetectors: ['hidden_file_extension'] will run these. # Leave empty for no restriction (all detectors not disabled will be chosen). # Command-line property --detectors overrides this. runDetectors: [] # Same format as runDetectors, but for skipping the selected detectors. # skipDetectors: ['high'] will skip all detectors with severity 'high' or lower. # Leave empty for no restriction (all detectors not disabled will be chosen). # Command-line property --skip-detectors overrides this. skipDetectors: []# Configuration for xygeni Malware evidences scanner. # Arguments from command line have priority over properties in this file. # Includes: list of glob patterns to include in analysis. # # A pattern could use ** (to match zero or more directories), * (zero or more characters # in a directory or file name), and ? (one character). # Examples: **/*.txt matches all files with 'txt' extension. **/test/** matches all files under any test directory. # # If empty, ALL files will be matched. # The command-line argument -i or --include will be used when specified. # # A file is analyzed when matched by 'includes' AND NOT matched by 'excludes'. includes: [] # Excludes: list of glob patterns to exclude from analysis. # If empty, NO file will be excluded. # The command-line argument -e or --exclude will be used when specified. excludes: - ".git/**/*" - ".vscode/**/*" - "build/**/*" - "dev/**/*" - "**/__pycache__/**/*" - "**/.eggs/**/*" - "**/bower_components/**/*" - "**/integration/**/*" - "**/locales/**/*" - "**/spec/**/*" - "**/specs/**/*" - "**/test/**/*" - "**/tests/**/*" - "**/mock/**/*" - "**/mocks/**/*" - "**/node_modules/**/*" - "**/.xygeni.*.json" # mode=sequential runs analyzers sequentially; # mode=parallel runs analyzers in multiple threads, when analyzer is capable of parallel runs. mode: sequential # Config for reporters report: - format: json prettyPrint: true - format: sarif prettyPrint: true - format: csv # Allowed values: kind, hash, severity, confidence, detector, file, beginLine, endLine, code, tags columns: [ "severity", "kind", "hash", "resource", "detector", "file", "beginLine", "endLine", "confidence", "tags" ] # Order specification. 'default' lists highest severe first, then by type, file and line. # One of 'default', 'type', 'exposure' or 'severity-confidence'. Blank for no sort sort: default - format: text # Allowed values: kind, hash, type, severity, confidence, detector, file, beginLine, endLine, code, tags columns: [ "severity", "kind", "detector", "file", "beginLine", "tags" ] # Order specification. 'default' lists highest severe first, then by type, file and line. # One of 'default', 'type', 'exposure' or 'severity-confidence'. Blank for no sort sort: default # The style for table borders. # One of 'full', 'none', 'outside', 'inside', 'horizontal', 'vertical', 'topbottom'. # Use 'default' for border that works well for the underlying OS. borders: full # The block characters to use: 'ascii' (use '+', '|', '-' and '=') # or 'utf8' for UTF-8 block characters. # Use 'default' for the encoding that works best for the underlying OS. bordersEncoding: utf8 # The detectors to use for detecting Malware evidences # are configured in resource files under malware/*.yml # List of detectors to run: IDs or severity. # runDetectors: ['high'] will run all detectors with severity 'high' or greater. # runDetectors: ['hidden_file_extension'] will run these. # Leave empty for no restriction (all detectors not disabled will be chosen). # Command-line property --detectors overrides this. runDetectors: [] # Same format as runDetectors, but for skipping the selected detectors. # skipDetectors: ['high'] will skip all detectors with severity 'high' or lower. # Leave empty for no restriction (all detectors not disabled will be chosen). # Command-line property --skip-detectors overrides this. skipDetectors: [] ``` ### Malware Detectors Configuration Detectors are configured with different YAML files located under the `conf/malware` directory of the [Xygeni scanner](/xygeni-scanner-cli/xygeni-cli-overview). There is a sample `_template.yml_` file that can be used to create your own [custom detectors](/introduction-to-xygeni/customizations#custom_detectors). {% hint style="info" %} Specify a directory for custom detectors with the `--custom-detectors-dir` command-line option to prevent scanner updates from overwriting your configurations. {% endhint %} Please refer to the [Malware detectors](/xygeni-products/code-security-cs/malware-scanner/malware-detectors) documentation for more information. # Malware Detectors ### Malware Detectors You can find a comprehensive list of all the available malware detectors at [detectors.xygeni.io](https://detectors.xygeni.io/xydocs/malware/detectors/index.html). # SAST Scanner ## Table of Contents 1. [Purpose](#purpose) 2. [Quick Start](#quick_start) 3. [Usage](#usage) ### Purpose A **Static Application Security Testing (SAST)** scan is employed to **analyze source code for security vulnerabilities** at an early stage in the development process. ### Quick Start Use the following command to detect code vulnerabilities in the current directory and upload the results to the Xygeni Platform: ```bash xygeni sast -n MyProject --upload ``` {% hint style="info" %} The SAST scanner can be run in two different ways: * Running its own specific command ( `xygeni sast [options]` ) * Running the general command ( `xygeni scan --run="sast" [options]` ) {% endhint %} Export code vulnerability with critical severity to CSV for review or to import findings into other tools: ```bash xygeni sast-n MyProject --detectors critical \ --format csv --output MyProject.misconfs.csv ``` ### Usage The SAST Scanner is launched using the `xygeni sast [options]` command. To view all available options, use the `--help` flag: ```bash xygeni sast --help ``` The most important properties are: * **Name** of the Xygeni Project `-n` or `--name`. * **Input source** to analyze. Either specify a **directory** with: `-d` or `--dir` or specify a **repository** using: `--repo`. The scan will analyze the current working directory when no target is specified. * **Upload** results to the service `--upload`. By default, results are not uploaded. * **Output file** (`-o` or `--output`) and **format** (`-f` or `--format`). If no output file is specified (or stdout / - are used), the standard output is used. Use `--format=none` for no output. * Specify what detectors to run with the `--detectors` / `--skip-detectors` options. A common use-case is to consider only issues with high or critical severity with `--detectors=high`. * The *resource kinds* to be scanned could also be tailored with the `--kinds` / `--skip-kinds` options. ```bash Configuration options: -c, --conf= Configuration filepath template (filename will be prefixed by 'SCAN.') --[no-]conf-download Download scanner config? (default: true} --detectors=SCAN=list[|SCAN=list...] Detectors to include per stage. is comma-separated of detector IDs, a severity or 'all'. Example: --detectors secrets=high|iac=critical|misconf=all --skip-detectors=SCAN=list[|SCAN=list...] Detectors to exclude per stage. is comma-separated list of detector IDs, or a severity. --custom-detectors-dir= Directory with custom detectors. ``` ### Currently Supported Programming Languages and Technologies: The Xygeni SAST Scanner ships with **native detectors** for the following languages — covering CWE-mapped vulnerability patterns, taint analysis, and framework-specific rules: * C# * Go * HTML * Java * JavaScript / TypeScript * Kotlin * PHP * Python * Swift **Additional language coverage** is available for the following languages through Xygeni-curated SAST rule packs: * C / C++ * Dart (including Flutter) * Objective-C * Rust * Scala For the full catalog of SAST detectors per language — including CWE, OWASP Top 10, MASVS and ASVS mappings — see the [Xygeni SAST detectors reference](https://detectors.xygeni.io/xydocs/sast/detectors/index.html). # SAST Scanner Configuration ### SAST Scanner Configuration The [**SAST Scanner**](/xygeni-products/code-security-cs/ci-cd-scanner) is configured in the **YAML file** `conf/xygeni.sast.yml`. ```yaml # Configuration for xygeni Sast scanner. # Arguments from command line have priority over properties in this file. # Includes: list of glob patterns to include in analysis. # # A pattern could use ** (to match zero or more directories), * (zero or more characters # in a directory or file name), and ? (one character). # Examples: **/*.txt matches all files with 'txt' extension. **/test/** matches all files under any test directory. # # If empty, ALL files will be matched. # The command-line argument -i or --include will be used when specified. # # A file is analyzed when matched by 'includes' AND NOT matched by 'excludes'. includes: [] # Excludes: list of glob patterns to exclude from analysis. # If empty, NO file will be excluded. # The command-line argument -e or --exclude will be used when specified. excludes: - ".git/**/*" - ".vscode/**/*" - "build/**/*" - "dev/**/*" - "**/__pycache__/**/*" - "**/.eggs/**/*" - "**/bower_components/**/*" - "**/integration/**/*" - "**/locales/**/*" - "**/node_modules/**/*" - "**/.xygeni.*.json" # mode=sequential runs analyzers sequentially; # mode=parallel runs analyzers in multiple threads, when analyzer is capable of parallel runs. mode: parallel # Parallelism specification (when mode=parallel): # 'auto', 'sequential', a number N, or one of 'availableProcessors + N', # 'availableProcessors - N', 'availableProcessors * N', 'availableProcessors / N' # 'auto' means 'availableProcessors - 1', 'sequential' means 1 # 'min(v1, v2)' means the minimum between the two values. # For example, 'min(availableProcessors - 1, 4)' is 4 if the number of cores is greater than 4, or cores - 1 otherwise. parallelism: auto #parallelism: min(availableProcessors - 1, 4) # Timeout, in seconds, for the analysis to complete. 0 or negative means no timeout. timeout: 18000 # Timeout, in seconds, for processing a source file. 0 or negative means no timeout. fileTimeout: 45 # Maximum CCN allowed for units (functions, classes, modules) when performing path navigation # Increasing this might potentially increase both the accuracy and the execution time, use wisely # When CCN is higher that this threshold a direct navigation will be performed which take less time maxAllowedComplexity: 19 # Commit resolution policy. One of: 'always', 'never', 'auto'. # 'auto' means that commit info is disabled if too many findings are reported. For benchmarking projects, commit resolution can be disabled. # 'never' means that commit resolution is disabled. No commit info (author, timestamp, commit ID and branch) will be reported. # 'always' means that commit resolution is enabled unconditionally. commitResolution: auto # When set to 'true' the tainting analyzer will only report the first source for every sink. # When false, all the paths will be analyzed and all the sources reaching a sink will be reported. reportOnlyFirstPath: false # Config for reporters report: - format: json prettyPrint: true - format: sarif prettyPrint: true - format: csv # Allowed values: severity, kind, detector, file, beginLine, endLine, details, code, commit, user, exposure, tags columns: [ "severity", "kind", "cwe", "detector", "file", "beginLine", "endLine", "tags", "details", "code" ] # Order specification. 'default' lists highest severe first, then by language, cwe, file and line. # One of 'default', 'language_cwe', 'detector', 'exposure' or 'newest'. Blank for no sort sort: default - format: text # Allowed values: severity, kind, detector, file, beginLine, endLine, details, code, commit, user, exposure, tags columns: [ "severity", "details", "tags", "file", "beginLine" ] # Order specification. 'default' lists highest severe first, then by kind, file and line. # One of 'default', 'language_cwe', 'detector', 'exposure' or 'newest'. Blank for no sort sort: default # The style for table borders. # One of 'full', 'none', 'outside', 'inside', 'horizontal', 'vertical', 'topbottom'. # Use 'default' for border that works well for the underlying OS. borders: full # The block characters to use: 'ascii' (use '+', '|', '-' and '=') # or 'utf8' for UTF-8 block characters. # Use 'default' for the encoding that works best for the underlying OS. bordersEncoding: utf8 # The detectors to use for detecting code vulnerabilities # are configured in resource files under sast/*.yml # List of detectors to run: IDs or severity. # runDetectors: ['high'] will run all detectors with severity 'high' or greater. # runDetectors: ['hidden_file_extension'] will run these. # Leave empty for no restriction (all detectors not disabled will be chosen). # Command-line property --detectors overrides this. runDetectors: [] # Same format as runDetectors, but for skipping the selected detectors. # skipDetectors: ['high'] will skip all detectors with severity 'high' or lower. # Leave empty for no restriction (all detectors not disabled will be chosen). # Command-line property --skip-detectors overrides this. skipDetectors: [] ``` ### SAST Detectors Configuration Detectors are configured with different YAML files located under the `conf/sast` directory of the [Xygeni scanner](/xygeni-scanner-cli/xygeni-cli-overview). There is a sample `_template.yml_` file that can be used to create your own [custom detectors](/introduction-to-xygeni/customizations#custom_detectors). {% hint style="info" %} Specify a directory for custom detectors with the `--custom-detectors-dir` command-line option to prevent scanner updates from overwriting your configurations. {% endhint %} # Code Quality Xygeni **Code Quality** analyses your source code for **maintainability and reliability defects** — code smells, complexity violations, dead code, duplication, and patterns that cause runtime failures — and surfaces them in a dedicated **Quality** section in the web platform, separate from security findings. Quality is delivered as its own scanner (`xygeni quality`) that shares the static-analysis engine with [SAST](/xygeni-products/code-security-cs) (parsers, AST, file discovery) but maintains its own rule catalog focused on quality, not security. ## Quality scanner Run a quality scan with the dedicated command: ```bash xygeni quality -d [options] ``` The alias `xygeni code-quality` is also accepted. The scanner shares its option model with `xygeni sast`. The most common options are: | Option | Description | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `-d`, `--dir ` | Directory to analyse. Defaults to the current working directory. | | `-n`, `--name ` | Project name to report under. | | `--upload` | Upload results to the Xygeni platform. By default, results are not uploaded. | | `--detectors ` | Comma-separated list of detector IDs to run, a severity (`critical`, `high`, `low`, `info`), or `all`. When a severity is given, that severity and any higher ones are included. | | `--skip-detectors ` | Inverse of `--detectors`. | | `-i`, `--include ` | Glob patterns of files to include. | | `-e`, `--exclude ` | Glob patterns of files to exclude. | | `-o`, `--output ` | Output file path. Defaults to stdout. | | `-f`, `--format ` | Output format. | | `--fail-on ` | Exit non-zero if findings of the given severity (or higher) are produced. Useful as a CI/CD gate. | | `--baseline ` | Compare against a baseline report and only return new findings. | For the full option list run: ```bash xygeni quality --help ``` ### Examples Run a quality scan on the current directory and upload the results: ```bash xygeni quality -n MyProject --upload ``` Export critical findings to JSON: ```bash xygeni quality -d --detectors critical --format json --output quality.json ``` ### Run quality alongside a SAST scan The SAST scanner accepts an `--include-quality` flag that runs the quality rules in the same pass. The SAST and quality rules share the parser stage, so this is more efficient than running `xygeni sast` and `xygeni quality` back to back when you want both. ```bash xygeni sast -d --include-quality ``` The scan produces both a SAST report and a separate quality report. SAST and quality findings remain on their own report files and on their own dashboard sections — `--include-quality` only changes how the scan is executed, not how the results are surfaced. ### Upload a previously generated quality report Quality results are normally sent to the platform during the scan with `--upload`. When the scan runs where there is no connectivity to Xygeni (an air-gapped enclave, or a CI runner without network egress), save the report and upload it later with [`report-upload`](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools): ```bash # 1. Scan, keep the report locally (no --upload) xygeni quality -d -n MyProject # 2. Later, from a host with platform connectivity, upload it xygeni report-upload -n MyProject -r depsdoctor-quality.json ``` The findings land in the **Quality** section exactly like a native quality scan — same triage, policy, baseline, and remediation behaviour — and never in the SAST / All Risks views. `report-upload` recognises the report from its standard file name `depsdoctor-quality.json`. If the file was renamed (for example via `--output`), pass the format explicitly so it is not mistaken for a SAST report (both share the same report shape): ```bash xygeni report-upload -n MyProject -r my-quality-report.json --format quality-xygeni ``` Uploading a quality report requires the **Code Quality** entitlement, the same as running the scan. ## Quality findings in the web platform Quality findings are uploaded to the Xygeni platform alongside any other scan output and are displayed in a **dedicated Quality section** of the dashboard, separate from SAST and the rest of the security risks. Filtering, slide-out detail, baselines, and reports work the same way as for the other risk tables. ## Related * [SAST Scanner](/xygeni-products/code-security-cs/ci-cd-scanner) — security-focused static analysis. Quality and SAST share the engine but ship as independent scan commands and rule catalogs. * [Xygeni CLI Configuration options](https://github.com/xygeni/UserDoc/tree/main/xygeni-products/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-configuration-options.md) — configuration files (`xygeni.yml`, `xygeni..yml`) and `--conf-option` overrides. # Dynamic Application Security Testing (DAST) ### **Overview** Xygeni's **Dynamic Application Security Testing (DAST)** tool performs automated security scanning of **running web applications and REST APIs** to uncover vulnerabilities that are exploitable at runtime. Unlike static analysis, DAST tests the application from the outside, simulating real-world attacks against live endpoints to identify security flaws before attackers do. Through integration with CI/CD pipelines and the Xygeni platform, the DAST scanner delivers actionable findings with full HTTP request/response evidence, enabling security teams to **quickly reproduce and remediate** vulnerabilities in web-facing applications. ### **Protect Web Applications and APIs from Runtime Vulnerabilities** Web applications and APIs are a primary attack surface. Even code that passes static analysis may expose vulnerabilities when deployed. Xygeni's DAST tool is built to detect: * **Injection flaws** (SQL injection, OS command injection, LDAP injection, XPath injection, and more). * **Cross-Site Scripting (XSS)** (reflected, stored, and DOM-based variants). * **Authentication and session management issues** (session fixation, weak credentials, CSRF). * **Security misconfigurations** (information disclosure, missing security headers, directory listing). * **Access control weaknesses** (path traversal, IDOR, privilege escalation). * **Known vulnerability patterns** (Log4Shell, Spring4Shell, Server-Side Template Injection). * **Known CVEs and exposures** — the `--vuln-check` option extends detection with template-based scanning against thousands of known CVEs and misconfigurations. The scan pipeline consists of: optional deep crawl (headless JS-aware URL discovery) → spidering and active/passive scanning → optional vulnerability check (CVE and misconfiguration detection) → report generation and upload. The scanner supports multiple application types: traditional server-rendered apps, JavaScript-heavy Single Page Applications (SPAs), and REST APIs with OpenAPI specifications. ### Supported Application Types | Type | Description | | --------------- | --------------------------------------------------------------- | | **Traditional** | Server-rendered web applications (PHP, JSP, ASP.NET, etc.) | | **SPA** | JavaScript-heavy Single Page Applications (React, Angular, Vue) | | **REST API** | REST APIs with OpenAPI/Swagger specification | | **GraphQL** | GraphQL APIs with schema import or introspection | | **SOAP** | SOAP web services with WSDL definition | For more information regarding DAST Security, refer to these sections: * [DAST User Interface Guide](/xygeni-products/dast-security/dast-user-interface-guide) * [Risks (DAST)](/xygeni-products/dast-security/dast-user-interface-guide/risks-dast) * [DAST Scanner](/xygeni-products/dast-security/dast-scanner) * [DAST Scanner Configuration](/xygeni-products/dast-security/dast-scanner/dast-scanner-configuration) * [DAST Detectors](/xygeni-products/dast-security/dast-detectors) ## Related * [API Security](/xygeni-products/api-security) — static discovery of the same API surface DAST tests at runtime. It reads source code and OpenAPI descriptors to produce an **endpoint inventory**, which is the join key the Risk Graph uses to match a DAST finding on a live URL to the handler that serves it. The two are complementary: API Security can see an endpoint that is never reached by a crawl (undocumented or unrouted), while DAST confirms what is actually exploitable on the deployed application. * [API Security Scanner Configuration](/xygeni-products/api-security/api-security-scanner/api-security-scanner-configuration) — how the inventory and its sensitivity tags are produced, including the correlation rules that compose findings across scans. # DAST User Interface Guide DAST User Interface can be accessed by selecting the DAST option under the [Risks](/xygeni-products/application-security-posture-management-aspm/all-risks) tab. The DAST section includes the following content: * [DAST Risks](/xygeni-products/dast-security/dast-user-interface-guide/risks-dast): A summary of all DAST security issues detected across your web applications and APIs. # DAST Risks The **Risks (DAST) page** can be accessed by selecting the DAST option in the [**Risks**](/xygeni-products/application-security-posture-management-aspm/all-risks) tab. This tab offers an in-depth overview of all DAST security issues, clearly presented for ease of assessment. {% hint style="info" %} Xygeni provides two functionalities related to DAST scanning: 1. Xygeni provides a [DAST Scanner](/xygeni-products/dast-security/dast-scanner) that can perform dynamic analysis over your web applications and REST APIs. Please visit [Xygeni DAST Scanner](/xygeni-products/dast-security/dast-scanner) for further information. 2. Xygeni also provides the functionality to [import scan results from 3rd-party tools](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools/dast-report-import). This way, you can integrate 3rd-party DAST data into Xygeni and benefit from the [Xygeni ASPM](/xygeni-products/application-security-posture-management-aspm) functionalities. {% endhint %} By default, this page will display all the DAST issues, regardless of the tool that found the issues (Xygeni DAST Scanner or any other 3rd party tool such as OWASP ZAP or Acunetix). If you click on **More filter fields**, you can find the **Tools** filter where you can select a tool and only those issues reported by the selected tool will be displayed. {% hint style="info" %} You can reach the **Risks (DAST)** results under DAST >> Risks (DAST) section. {% endhint %} ## Vulnerability Details Each DAST vulnerability includes the following information: * **Kind**: The vulnerability type (e.g., SQL Injection, Cross-Site Scripting). * **Severity**: The risk level (`critical`, `high`, `low`, or `info`). * **Confidence**: How confident the scanner is in the finding (`low`, `medium`, `high`, or `highest`). * **URL**: The affected endpoint. * **Method**: The HTTP method used (GET, POST, etc.). * **Parameter**: The vulnerable parameter name. * **Evidence**: The attack payload or proof string. * **CWE**: The associated Common Weakness Enumeration identifier. * **Compliance mappings**: Where applicable, findings carry the matching **NIST 800-53**, **SANS Top 25**, and **PCI DSS** controls so DAST results can be traced directly to compliance requirements. * **HTTP Request/Response**: Full request and response details for reproducing the issue (captured by the active/passive scanner and by the vulnerability check, when available). * **Potential PoC**: A best-effort proof-of-concept for the finding, including a `curl` command and an `expect` block (`status`, `bodyContains`, `bodyRegex`, `headerContains`) that describes how to recognise the vulnerable response. Each PoC carries a **confidence** score: `high` for deterministic matchers (vuln-check templates) and reflective findings where the evidence appears in the response body, or `low` for behavioural detections (timing, blind injection, auth bypass) — in the latter case the `notes` field explains the limitation. ## Severity Levels DAST findings are mapped to four severity levels: | Severity | Description | | ------------ | ---------------------------------------------------------------------------------------------------- | | **Critical** | High-risk vulnerabilities that are directly exploitable (e.g., SQL Injection, Remote Code Execution) | | **High** | Medium-risk issues that may lead to data exposure or further exploitation (e.g., XSS, CSRF) | | **Low** | Low-risk issues with limited impact (e.g., cookie without secure flag) | | **Info** | Informational findings that may indicate areas for improvement (e.g., missing headers) | # DAST Scanner ## Table of Contents 1. [Purpose](#purpose) 2. [Installation](#installation) 3. [Quick Start](#quick_start) 4. [Usage](#usage) 5. [Built-in Scan Profiles](#profiles) 6. [Authentication](#authentication) 7. [CI/CD Integration](#cicd) 8. [Command Reference](#command_reference) 9. [Exit Codes](#exit_codes) ### Purpose The **DAST Scanner** (`xy-dast`) performs automated **dynamic security testing** of running web applications and REST APIs. It tests applications from the outside -- simulating real-world attacks against live endpoints -- to identify vulnerabilities that are only exploitable at runtime. The scanner supports different application types: * **Traditional** server-rendered web apps (PHP, JSP, ASP.NET) * **SPA** JavaScript-heavy Single Page Applications (React, Angular, Vue) * **REST API** with OpenAPI/Swagger specifications or Postman collections * **GraphQL** APIs (schema import or introspection) * **SOAP** web services (WSDL import) * **CMS** platforms (WordPress, Drupal, Joomla) You choose *what* the target is and *how hard* to scan it on **two independent axes**: a **tech-stack profile** (`--profile`) and a **scan intensity** (`--intensity`). They compose freely — e.g. a deep scan of an SPA is `--profile spa --intensity deep`. See [Built-in Scan Profiles](#profiles). ### Installation The DAST scanner is distributed as a Docker image (`xygeni/xy-dast`). Install a lightweight wrapper directly from the image — no separate download is needed. The wrapper is a small, signed script that delegates to `docker compose run`, so once installed you invoke `xy-dast` as if it were a native command. #### One-command install (recommended) From 6.14.0 there is an installer that does all of the below for you: it finds Docker, pulls the image, **verifies its signature**, creates the install directory, and pins the wrapper to the exact image digest it verified. On a host with only Podman it stops and tells you to install Docker, rather than installing a wrapper that could not run. {% tabs %} {% tab title="Linux / macOS" %} ```bash curl -fsSL https://get.xygeni.io/latest/dast/get-dast.sh | sh # To pass options through the pipe, separate them with `-s --`: curl -fsSL https://get.xygeni.io/latest/dast/get-dast.sh | sh -s -- -d /usr/local/bin --add-to-path ``` Installs into the first writable of `$HOME/.local/bin` or a `$HOME/bin` already on your `PATH`, falling back to `$HOME/.local/bin`. {% endtab %} {% tab title="Windows" %} ```powershell iwr -useb https://get.xygeni.io/latest/dast/get-dast.ps1 | iex # `iex` cannot pass parameters. To use any, download the script and run the file: iwr -useb https://get.xygeni.io/latest/dast/get-dast.ps1 -OutFile get-dast.ps1 .\get-dast.ps1 -InstallDir C:\Tools\bin -AddToPath ``` Installs into `$HOME\.local\bin` unless `-InstallDir` says otherwise. {% endtab %} {% endtabs %} | Linux / macOS | Windows | Effect | | ------------------------- | ----------------------------- | ------------------------------------------------------------- | | `-d ` | `-InstallDir ` | Install somewhere other than the default | | `-i ` | `-Image ` | Pin a version instead of `latest` | | `--add-to-path` | `-AddToPath` | Add the install directory to your shell profile / user `PATH` | | `--prune` | `-Prune` | Also delete `xy-dast` wrappers found elsewhere on `PATH` | | `--allow-unverified` | `-AllowUnverified` | Proceed when no verifier is available | To check the installer itself before running it, compare it against the digest published in the `xygeni/xygeni` repository: {% tabs %} {% tab title="Linux / macOS" %} ```bash curl -fsSLO https://get.xygeni.io/latest/dast/get-dast.sh h=$(curl -fsS https://raw.githubusercontent.com/xygeni/xygeni/main/checksum/latest/get-dast.sh.sha256) echo "$h get-dast.sh" | sha256sum -c sh ./get-dast.sh ``` {% endtab %} {% tab title="Windows" %} ```powershell iwr -useb https://get.xygeni.io/latest/dast/get-dast.ps1 -OutFile get-dast.ps1 $h = (iwr -useb https://raw.githubusercontent.com/xygeni/xygeni/main/checksum/latest/get-dast.ps1.sha256).Content.Trim() (Get-FileHash .\get-dast.ps1 -Algorithm SHA256).Hash -eq $h.ToUpper() .\get-dast.ps1 ``` {% endtab %} {% endtabs %} The digest lives in a different place from the script it vouches for: an attacker would have to compromise both `get.xygeni.io` and the GitHub repository to pass this check. A signature that **fails** verification always stops the install. If no verifier is available at all (no `cosign`, no Docker-run fallback), the install reports that it could not verify and continues only when you pass `--allow-unverified`. #### Keeping it up to date ```bash xy-dast update # pull, verify, re-pin to the latest xy-dast update --version 6.14.0 # or a specific tag / sha256: digest ``` `update` verifies the new image exactly as the installer does, so it fails rather than re-pin to something it could not check. `--allow-unverified` covers the case where no verifier is available; a signature that *fails* is always fatal. `update` moves the wrapper and the image together. That matters: the two speak a versioned calling contract, and an image newer than its wrapper refuses to run rather than mis-resolve your local file paths — which used to surface as a confusing "file not found" for a file that was plainly there. #### Manual install The step-by-step route below works with any released image, and is the one to use where the installer cannot reach the internet. **Requirements** * **Docker Engine 20.10+** (or Docker Desktop) with Compose v2 — i.e. the `docker compose ...` subcommand. The legacy `docker-compose` v1 binary is not supported, and Podman is not a substitute: the wrapper drives `docker compose`, which Podman does not provide. * A directory on your `PATH` to drop the wrapper into. This guide uses `~/.local/bin` (Linux/macOS) and `%USERPROFILE%\.local\bin` (Windows). #### Step 1 — Create the install directory and ensure it is on your `PATH` This is the most common source of "command not found: xy-dast" issues. The install directory **must exist before the install command** (Docker creates it as `root` if it does not, which then fails to write), and it **must be on your `PATH`** for the short `xy-dast` command to work. {% hint style="warning" %} On **Windows** and **macOS** the `~/.local/bin` directory is **not** on the default `PATH`. On most Linux distributions it *is* added by `~/.profile`, but **only if the directory exists at login** — if you create it now in an existing shell, you still need to add it to `PATH` for the current session (or open a new login shell after creating it). {% endhint %} {% tabs %} {% tab title="Linux" %} ```bash # 1. Create the directory (idempotent) mkdir -p ~/.local/bin # 2. Make sure it is on PATH for the current shell case ":$PATH:" in *":$HOME/.local/bin:"*) ;; *) export PATH="$HOME/.local/bin:$PATH" ;; esac # 3. Persist for future shells (only needed once per shell rc) grep -q '\.local/bin' ~/.bashrc 2>/dev/null \ || echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc # zsh users: replace ~/.bashrc with ~/.zshrc ``` Verify: ```bash echo "$PATH" | tr ':' '\n' | grep -F "$HOME/.local/bin" # should print the path ``` {% endtab %} {% tab title="macOS" %} ```bash # 1. Create the directory mkdir -p ~/.local/bin # 2. Add to PATH for the current shell export PATH="$HOME/.local/bin:$PATH" # 3. Persist for future shells (zsh is the default since macOS Catalina) grep -q '\.local/bin' ~/.zshrc 2>/dev/null \ || echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc # bash users: replace ~/.zshrc with ~/.bash_profile ``` Verify: ```bash echo "$PATH" | tr ':' '\n' | grep -F "$HOME/.local/bin" ``` {% endtab %} {% tab title="Windows (PowerShell)" %} ```powershell # 1. Create the directory New-Item -ItemType Directory -Force -Path "$HOME\.local\bin" | Out-Null # 2. Add to PATH for the current shell $env:PATH = "$HOME\.local\bin;$env:PATH" # 3. Persist for future shells (User scope, no admin needed) $userPath = [Environment]::GetEnvironmentVariable('PATH', 'User') if ($userPath -notlike "*$HOME\.local\bin*") { [Environment]::SetEnvironmentVariable('PATH', "$HOME\.local\bin;$userPath", 'User') } ``` Verify (open a **new** PowerShell window after persisting): ```powershell $env:PATH -split ';' | Select-String '\.local\\bin' ``` {% hint style="info" %} The Windows wrapper is a PowerShell script (`xy-dast.ps1`) signed with an Authenticode certificate. If your execution policy blocks running scripts, run `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` once. {% endhint %} {% endtab %} {% endtabs %} #### Step 2 — Install the wrapper from the Docker image The image's `install` subcommand drops two files into the mounted directory: the `xy-dast` wrapper script itself and a sidecar `xy-dast-compose.yml` that holds the image reference, environment forwarding, and runtime parameters. {% tabs %} {% tab title="Linux / macOS" %} ```bash docker run --rm -v ~/.local/bin:/mnt/install xygeni/xy-dast install ``` {% endtab %} {% tab title="Windows (PowerShell)" %} ```powershell docker run --rm -v "${HOME}\.local\bin:/mnt/install" xygeni/xy-dast install --powershell ``` `--powershell` produces the signed `.ps1` wrapper (and matching sidecar) instead of the bash one. {% endtab %} {% endtabs %} Verify: ```bash xy-dast --version ``` If you get `command not found` (or `not recognized as ... cmdlet`), revisit Step 1 — the directory is almost certainly not on your `PATH` yet. #### Quick install vs. secure install The plain `install` command above is a **quick install**: convenient for desktop and ad-hoc use. The wrapper itself is signed at release time, but the image reference written into `xy-dast-compose.yml` is a mutable tag (e.g. `xygeni/xy-dast:6.7.0`). For production environments — and any setting that needs defence-in-depth against registry-side supply-chain attacks — use the **secure install** flow, which pins the image to its immutable digest and verifies the cosign (Sigstore keyless) signature before installing: ```bash TAG=xygeni/xy-dast:6.7.0 # or :latest # 1. Pull the image so the digest is in your local image cache. docker pull "$TAG" # 2. Verify the cosign signature, signed by the xy-dast GitHub Actions identity. cosign verify \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ --certificate-identity-regexp 'github\.com/xygeni/xy-dast' \ "$TAG" # 3. Resolve the immutable digest the registry served us. DIGEST=$(docker image inspect "$TAG" --format '{{index .RepoDigests 0}}') # 4. Install. --image rewrites only the `image:` line in xy-dast-compose.yml # to pin the resolved digest — wrapper bytes stay byte-identical. docker run --rm -v ~/.local/bin:/mnt/install "$TAG" install --image "$DIGEST" ``` To upgrade later, repeat the four-step flow with the new version — or run `xy-dast update`, which pulls, verifies and re-pins the wrapper and the image together. #### How the wrapper works * It is a pre-built, byte-stable script signed at release time (Authenticode for `.ps1`); `install` copies it byte-exact so the signature is preserved. * It delegates to `docker compose -f xy-dast-compose.yml run --rm xy-dast …`. Compose handles env forwarding (`XYGENI_TOKEN`, `XYGENI_URL`, `XYGENI_DASHBOARD_URL`, `XYGENI_DAST_DIR`), `network_mode: host`, and `shm_size: 2gb`. * When you pass `-o `, the wrapper mounts the output directory into the container (read-write) so the report appears on your host filesystem. * Local input files (`--openapi`, `--postman`, `--graphql`, `--wsdl`, `--url-list`, `--client-cert`, `--auth-config`, `--session-file`, and a `--profile` file) are read from a **base directory** — your current directory by default, or set explicitly with `--base-dir`. It is mounted read-only, so paths must live under it; relative paths resolve against it. This also reaches files referenced *inside* a profile or auth config. Use a `--base-dir` that contains all your inputs, or pass URLs instead. * It looks for the sidecar at `/xy-dast-compose.yml` by default. Override the location with the `XY_DAST_COMPOSE_FILE` environment variable. To pin a different image, edit the `image:` line in the sidecar or re-run `install --image `. ### Quick Start #### Let the scanner write your configuration From 6.14.0, if you would rather be asked than read the options, run the guided setup: ```bash xy-dast interactive ``` It asks about your target and writes a profile YAML, a ready-to-run command line, or both. Only relevant questions are asked — answering "REST API" skips the crawling questions — and every question has a default, so pressing `Enter` throughout still produces a working configuration. It can also probe the target and propose the profile matching what it finds. Where a question offers a list, move with the arrow keys or `Tab`, press `1`-`9` to take an option outright, and `Enter` to accept the highlighted one. Single keys carry the commands: `b` back, `s` skip, `d` defaults for everything remaining, `q` quit without writing, `?` help. `Esc` swaps the list for a typed prompt. At a typed question the same commands are written with a colon — `:b`, `:s`, `:d`, `:q` — and `?` still asks for help. The keys in use are always shown under the question, so there is nothing to memorise. {% hint style="info" %} The wizard never asks you to type a password or token. Where a credential is needed it asks for the **name of the environment variable** holding it and writes `${env:VAR}` into the profile, so the generated files are safe to commit. {% endhint %} Scan a web application: ```bash xy-dast scan -u https://example.com ``` Results are uploaded to the Xygeni platform by default. To save a local report instead, use `-o`: ```bash xy-dast scan -u https://example.com -o report.json ``` Scan a REST API with an OpenAPI specification: ```bash xy-dast scan -u https://api.example.com \ -p openapi \ --openapi https://api.example.com/v3/api-docs \ --bearer-token env:API_TOKEN ``` Scan a REST API from a Postman collection (v2.x). Use a local file or a URL, and override collection variables with `--postman-vars`: ```bash xy-dast scan -u https://api.example.com \ --postman ./api.postman_collection.json \ --postman-vars "baseUrl=https://api.example.com,apiKey=demo" ``` Scan a Single Page Application: ```bash xy-dast scan -u https://app.example.com -p spa ``` Scan a GraphQL API: ```bash # With schema URL xy-dast scan -u https://api.example.com \ -p graphql \ --graphql https://api.example.com/graphql/schema # With introspection (no schema needed) xy-dast scan -u https://api.example.com -p graphql ``` Scan a SOAP web service: ```bash xy-dast scan -u https://api.example.com \ --wsdl https://api.example.com/service?wsdl ``` Scan a REST API with OAuth2 (client credentials). The scanner obtains a token from the token endpoint before the scan and sends it as a bearer token on every request: ```bash xy-dast scan -u https://api.example.com \ --oauth2-token-url https://idp.example.com/oauth/token \ --oauth2-client-id env:OAUTH_CLIENT_ID \ --oauth2-client-secret env:OAUTH_CLIENT_SECRET \ --oauth2-scope api.read ``` The `password` and `refresh_token` grants and advanced options are configured via a [profile](/xygeni-products/dast-security/dast-scanner/dast-scanner-configuration). Seed the scan from traffic you have already recorded with `--navigation`, so endpoints that crawling alone would miss are scanned too. The format is auto-detected: a recorded **browser navigation** — a **Selenium IDE** (`.side`) or a **Chrome DevTools Recorder** (`.json`) recording — is replayed in a real browser to generate the traffic; a recorded **HAR** (from browser DevTools, a proxy, or a test tool) is imported directly: ```bash # A recorded browser navigation (replayed): Selenium IDE .side … xy-dast scan -u https://app.example.com --navigation ./browse.side # … or a Chrome DevTools Recorder export xy-dast scan -u https://app.example.com --navigation ./recording.json # A recorded HAR (imported; local file or URL) xy-dast scan -u https://app.example.com --navigation ./recording.har ``` Use `--navigation-format selenium|chrome-devtools|har` to set the format explicitly when the extension is ambiguous (for example, a `.json` that is neither a DevTools recording nor a HAR). A `.side` given to `--navigation` is **always** replayed and seeded — it is a navigation input, not a login method, so the profile `script.seedNavigation` setting does not apply to it (that setting gates a scripted *login* `.side`; see [Scripted Browser Login](/xygeni-products/dast-security/dast-scanner/dast-scanner-configuration)). The navigation script and an optional scripted login are separate inputs: when both are given, a `.side` navigation is replayed in the same authenticated browser so it can reach gated pages. Only requests on the target's host are kept. Add `--navigation-only` to scan **only** the recorded endpoints (skipping the crawl). ### Usage The DAST Scanner is launched using the `xy-dast scan [options]` command. To view all available options, use the `--help` flag: ```bash xy-dast scan --help ``` The most important options are: * **Target URL** (`-u` or `--url`) -- the base URL of the application to scan (required). * **Tech-stack profile** (`-p` or `--profile`) -- what the target is: `traditional`, `spa`, `openapi`, `graphql`, `soap`, or `cms` (or a custom profile). * **Scan intensity** (`--intensity`) -- how hard to scan: `quick`, `balanced` (default), `deep`, or `passive`. Overlays attack strength, durations, and CVE / deep-crawl on top of the tech profile. * **OpenAPI spec** (`--openapi`) -- URL or file path to an OpenAPI/Swagger specification (for REST API scans). * **Postman collection** (`-pm` or `--postman`) -- URL or file path to a Postman v2.x collection; `--postman-vars` overrides its variables (`key=value`, comma-separated). * **Recorded traffic** (`--navigation`) -- seed the scan from a recorded browser navigation (`.side`, replayed) or a recorded HAR (imported); `--navigation-only` scans only the recorded endpoints. * **Output file** (`-o` or `--output`) -- path for the JSON report. Use `-` for stdout. * **Project name** (`-n` or `--project-name`) -- identifies the project in the Xygeni platform. * **Upload** -- reports are uploaded to the Xygeni backend by default. Disable with `--no-upload`. * **Filtering** -- use `--exclude-rules` to skip noisy rules, or `--risk-threshold` to set a minimum severity. #### Custom Scan Settings Override timing defaults directly from the command line: ```bash xy-dast scan -u https://example.com \ --spider-duration 15 \ --ajax-spider-duration 10 \ --active-scan-duration 30 \ --timeout 90 \ -o report.json ``` Durations accept `30s` / `5m` / `1h` (a bare number is minutes). A duration of **`0` means unlimited** (no timeout for that phase, or no overall cap for `--timeout`) — it never means "skip". To disable a phase, use an explicit flag — `--passive-only` (alias `--skip-active-scan`), `--skip-spider`, or `--skip-ajax-spider`: ```bash # Passive-only scan (no active attacks) xy-dast scan -u https://example.com --passive-only -o report.json # Spider + passive only (skip the active scan and the AJAX spider) xy-dast scan -u https://example.com --passive-only --skip-ajax-spider -o report.json ``` For a production-safe scan packaged as a profile, use `--intensity passive` (crawl + passive analysis, no active attack payloads) with any tech base: `xy-dast scan -u https://app.example.com --profile spa --intensity passive`. #### Filtering Results ```bash # Exclude noisy rules by ID xy-dast scan -u https://api.example.com \ --exclude-rules 10094,10038 \ -o report.json # Only report findings at MEDIUM risk or above xy-dast scan -u https://api.example.com \ --risk-threshold MEDIUM \ -o report.json # Set attack strength xy-dast scan -u https://example.com \ --policy-strength LOW \ -o report.json ``` #### Deep Crawl The `--deep-crawl` option runs a headless browser-based crawler before the main scan. It discovers URLs that traditional spiders miss, especially in JavaScript-heavy applications where content is rendered dynamically. ```bash xy-dast scan -u https://app.example.com --deep-crawl ``` Discovered URLs are fed as seed URLs into the scanner's spider, improving coverage. You can tune the crawl depth and timeout: ```bash xy-dast scan -u https://app.example.com \ --deep-crawl \ --crawl-depth 5 \ --crawl-timeout 10m ``` The `deep` intensity (`--intensity deep`) enables deep crawl by default. #### Vulnerability Check The `--vuln-check` option runs a template-based vulnerability scanner after the main scan completes. It checks the discovered endpoints against thousands of known CVEs, misconfigurations, and exposures — complementing the active scanning with signature-based detection. ```bash xy-dast scan -u https://app.example.com --vuln-check ``` Both features can be combined for maximum coverage: ```bash xy-dast scan -u https://app.example.com -n my-app \ --deep-crawl --vuln-check ``` Vulnerability check findings appear in the same report as regular scan findings, with detector IDs prefixed by `vuln/` (e.g., `vuln/CVE-2021-44228`). See [DAST Detectors](/xygeni-products/dast-security/dast-detectors) for details. You can filter by severity and control the scan rate: ```bash xy-dast scan -u https://app.example.com \ --vuln-check \ --vuln-check-severity critical,high \ --vuln-check-timeout 5m ``` The `deep` intensity (`--intensity deep`) enables vulnerability check by default. #### Out-of-Band Detection (OAST) Some vulnerabilities never surface in the HTTP response — the proof is a *side effect*: the target opens a connection to a server you control. Blind SSRF, blind XXE, Log4Shell, blind SSTI and out-of-band XSS are detected this way. The scanner injects a payload and, if the target is vulnerable, it calls back to an **OAST server** (out-of-band application security testing). These rules are inert unless an OAST service is configured, so it is **off by default** — enable it explicitly: ```bash # Same network: the scanner is its own OAST server (no external service) xy-dast scan -u http://target:8080 --oast-service=callback -o report.json # Public server (target needs outbound egress) xy-dast scan -u https://app.example.com --oast-service=boast -o report.json # Self-hosted server for an internal / air-gapped target xy-dast scan -u https://app.internal \ --oast-service=interactsh \ --oast=https://oast.internal.example.com \ --oast-token env:OAST_TOKEN \ -o report.json ``` **Choosing a service.** An OAST callback only works if the target can reach the server *and* the scanner can observe the hit: | Service | Best for | Reachability | | ------------ | --------------------------------------------------- | --------------------------------------------------- | | `callback` | Internal targets on the same network as the scanner | Target must route back to the **scanner** container | | `boast` | Public targets (zero-config public server) | Target needs outbound internet egress | | `interactsh` | Public or **self-hosted** | Public egress, or a self-hosted server both reach | `callback` is the simplest and most reliable choice for internal targets and detects the HTTP-based out-of-band rules (blind SSRF, blind XXE). For a **self-hosted** OAST — the option for internal targets with no public egress that cannot route back to the scanner — run an [Interactsh](https://github.com/projectdiscovery/interactsh) server both the target and the scanner can reach, and point `--oast` at it. Tokens are read from the environment (`env:VAR` / `${env:VAR}`) and never logged. See [DAST Scanner Configuration](/xygeni-products/dast-security/dast-scanner/dast-scanner-configuration#out-of-band-detection-oast) for the profile block, per-rule detection notes, and self-hosting guidance. #### Automatic Profile Selection If you are unsure which profile fits your target, use `--auto-profile` to let the scanner probe the application and select the most appropriate profile: ```bash xy-dast scan -u https://app.example.com --auto-profile ``` This detects the technology stack (e.g., React SPA, REST API with OpenAPI, or a WordPress/Drupal/Joomla site → `cms`) and selects the corresponding **tech base**. If `--profile` is also specified, it takes precedence. `--intensity` still applies on top of the auto-detected base — e.g. `--auto-profile --intensity deep`. To see the available profiles: ```bash xy-dast scan --list-profiles ``` #### Incremental Scans Re-test only the endpoints that changed since a baseline — driven by Xygeni's API Security scan — for a large wall-time saving on pull-request pipelines, then merge with the previous report so the output is still a complete snapshot. Off by default; enable with `--incremental`. See [**Incremental DAST Scanning**](/xygeni-products/dast-security/dast-scanner/incremental-scanning) for the full workflow, the `--baseline-report` merge, and the full-scan fallback. ### Built-in Scan Profiles Profiles have **two independent axes** — pick a **tech base** with `--profile` and a **scan intensity** with `--intensity`, and combine them freely. **Tech base** (`--profile`) — *what the target is*. Controls the crawl, endpoint import, and scan policy. Auto-selectable with `--auto-profile`. | Tech base | Best for | Crawl | Endpoint import | | ------------- | ---------------------------------------- | ------------------------------- | ---------------------------------- | | `traditional` | Server-rendered apps (PHP, JSP, ASP.NET) | Spider + moderate browser crawl | — | | `spa` | JS-heavy SPAs (React, Angular, Vue) | Heavy browser (AJAX) crawl | — | | `openapi` | REST APIs with an OpenAPI spec | Minimal spider, no browser | OpenAPI spec (API-Scan policy) | | `graphql` | GraphQL APIs | Minimal spider, no browser | Schema import / introspection | | `soap` | SOAP web services | Minimal spider, no browser | WSDL | | `cms` | WordPress / Drupal / Joomla | Server-rendered crawl | — (CVE checking on, CMS templates) | **Scan intensity** (`--intensity`) — *how hard*. Overlays attack strength, thresholds, phase durations, and CVE / deep-crawl on top of the tech base. | Intensity | Attack strength | CVE check | Deep crawl | Active scan | | -------------------- | --------------------------- | --------- | ---------- | ------------------------------------------------- | | `quick` | Low | off | off | on (fast, no browser crawl) | | `balanced` (default) | Medium | off | off | on | | `deep` | Insane (extended durations) | **on** | **on** | on | | `passive` | — | off | off | **skipped** (production-safe, no attack payloads) | **Composition recipes:** | Goal | Command | | ----------------------------------------- | -------------------------------------- | | Deep scan of a REST API | `--profile openapi --intensity deep` | | Fast CI gate on an SPA | `--profile spa --intensity quick` | | Production-safe scan (no attack payloads) | `--profile --intensity passive` | | Auto-detect the stack, deep intensity | `--auto-profile --intensity deep` | {% hint style="info" %} If no `--intensity` is given, `balanced` is used. Passing an intensity name directly to `--profile` (e.g. `--profile deep`) is accepted as shorthand for the `traditional` base at that intensity. {% endhint %} List all available profiles (including custom ones): ```bash xy-dast scan --list-profiles ``` {% hint style="info" %} Custom profiles can be placed in `$XYGENI_DAST_DIR/profiles/`, `./profiles/`, or `./conf/profiles/`. See [DAST Scanner Configuration](/xygeni-products/dast-security/dast-scanner/dast-scanner-configuration) for the full profile schema and examples. {% endhint %} ### Authentication The DAST scanner supports authenticated scanning to test areas of the application behind login. #### Form-Based Login ```bash xy-dast scan -u https://app.example.com \ --login-url https://app.example.com/login \ --username testuser \ --password testpass \ -o report.json ``` #### Bearer Token Read the token from an environment variable to avoid exposing secrets in command history: ```bash export API_TOKEN=your-secret-token xy-dast scan -u https://api.example.com \ --bearer-token env:API_TOKEN \ -o report.json ``` #### API Key / Custom Header For APIs that authenticate via a custom header (e.g., `X-API-Key`): ```bash xy-dast scan -u https://api.example.com \ --api-key-header X-API-Key \ --api-key-value env:MY_API_KEY \ -o report.json ``` #### HTTP Basic Authentication For targets protected with HTTP Basic auth (RFC 7617): ```bash xy-dast scan -u https://app.example.com \ --basic-username admin \ --basic-password env:BASIC_PASS \ -o report.json ``` #### Client Certificate (mTLS) For targets that require mutual TLS, supply a PKCS#12 (`.p12` / `.pfx`) certificate. The password is read from an environment variable and is redacted from any log output: ```bash export CERT_PASSWORD=cert-secret xy-dast scan -u https://mtls.example.com \ --client-cert /path/to/client.p12 \ --client-cert-password env:CERT_PASSWORD \ -o report.json ``` mTLS is orthogonal to the other authentication methods — combine it with `--bearer-token`, `--api-key-*`, `--basic-*`, or form login when the target requires both transport-level and application-level auth. The certificate path can also be set via the `clientCertificate` block in a profile YAML. #### OAuth2 The scanner obtains a token from the OAuth2 token endpoint before the scan and injects it as a bearer token on every request: ```bash xy-dast scan -u https://api.example.com \ --oauth2-token-url https://idp.example.com/oauth/token \ --oauth2-client-id env:OAUTH_CLIENT_ID \ --oauth2-client-secret env:OAUTH_CLIENT_SECRET \ --oauth2-scope api.read \ -o report.json ``` The `password` and `refresh_token` grants (and provider-specific options) are configured via the `authentication` block in a profile YAML — see [DAST Scanner Configuration](/xygeni-products/dast-security/dast-scanner/dast-scanner-configuration). For long scans where a short-lived token would expire before the scan finishes, add `--token-refresh` so the scanner renews the token during the scan and keeps authenticated coverage: ```bash xy-dast scan -u https://api.example.com \ --oauth2-token-url https://idp.example.com/oauth/token \ --oauth2-client-id env:OAUTH_CLIENT_ID \ --oauth2-client-secret env:OAUTH_CLIENT_SECRET \ --token-refresh \ -o report.json ``` The `refresh_token` grant and finer token-renewal settings are configured via the profile `tokenLifecycle` block — see [DAST Scanner Configuration](/xygeni-products/dast-security/dast-scanner/dast-scanner-configuration). #### Pre-authenticated Session Import (SSO) For OIDC/SAML SSO targets (Okta, Microsoft Entra ID, …), authenticate out-of-band and supply the resulting session cookies/headers — the scanner sends them on every request: ```bash xy-dast scan -u https://app.example.com \ --session-cookie "SESSION=env:SESSION_ID" \ --session-file session.json \ -o report.json ``` `--session-file` also accepts a **Playwright `storageState.json`** directly — the artifact produced by `context.storage_state()` in an existing Playwright login script. Its cookies are imported, and a JWT found in local storage is turned into an `Authorization: Bearer` header, so a session captured by a Playwright test can drive an authenticated scan with no conversion: ```bash xy-dast scan -u https://app.example.com \ --session-file storageState.json \ -o report.json ``` Opaque (non-JWT) local-storage tokens are **not** auto-mapped — the target header is ambiguous — so inject those explicitly with `--session-cookie` or a header. #### Scripted Browser Login (multi-step / advanced) For logins that simple form/bearer auth cannot express (identifier-first or multi-page flows, JavaScript-gated logins, SSO), provide a recorded **Selenium IDE (`.side`)** script via an auth-config file. The scanner drives a real browser through the login and reuses the captured session for the scan: ```bash xy-dast scan -u https://app.example.com \ --auth-config auth.yaml \ -o report.json ``` ```yaml # auth.yaml authentication: method: script script: engine: selenium # Selenium today; other frameworks (e.g. Playwright) planned file: auth/login.side vars: { USERNAME: "${env:DAST_USER}", PASSWORD: "${env:DAST_PASS}" } ``` See [DAST Scanner Configuration](/xygeni-products/dast-security/dast-scanner/dast-scanner-configuration) for capture/extraction options. {% hint style="warning" %} Always use `env:VAR_NAME` syntax for secrets (tokens, passwords, API keys, certificate passwords) rather than passing values directly on the command line, to prevent accidental exposure in shell history and process listings. {% endhint %} ### CI/CD Integration Use `--quiet` for minimal output and `--fail-on` to gate builds on vulnerability severity: ```bash xy-dast scan -u https://example.com \ --quiet \ --fail-on high \ -o report.json # Exit code 128 means alerts were found at or above the threshold if [ $? -eq 128 ]; then echo "Security vulnerabilities found!" exit 1 fi ``` The `--quiet` flag outputs a single summary line: ``` Scan completed in 5m 23s | 42 URLs | 15 alerts (2 critical, 5 high, 4 low, 4 info) ``` Pipe JSON to stdout for downstream processing: ```bash xy-dast scan -u https://example.com --quiet --output - | jq '.vulnerabilities | length' ``` #### SARIF output for GitHub Code Scanning `--format sarif` produces SARIF v2.1.0 output that GitHub Code Scanning, Azure DevOps, the VS Code SARIF Viewer, and most CI/CD security dashboards ingest natively. Findings appear in the repo's **Security → Code scanning** tab alongside SAST/SCA results. ```yaml # .github/workflows/dast.yml - name: Run xy-dast scan run: | xy-dast scan -u https://staging.example.com \ --format sarif \ --branch ${{ github.ref_name }} \ --no-upload \ -o dast.sarif - name: Upload SARIF to GitHub Code Scanning uses: github/codeql-action/upload-sarif@v3 with: sarif_file: dast.sarif category: dast/xygeni-dast ``` {% hint style="info" %} DAST findings reference HTTP URLs rather than source-tree files, so they appear in the Security tab but **do not** produce inline PR annotations. This is a known limitation of all DAST tooling that emits SARIF. {% endhint %} The `--format` flag only affects the file written by `-o`. The Xygeni backend upload payload (when `--no-upload` is omitted) is always Xygeni JSON regardless of `--format`. #### Saving raw scan artifacts Use `--keep-details` to save the underlying scanner output and the generated automation plan alongside the report. This is the easiest way to debug a scan that does not produce expected findings: ```bash xy-dast scan -u https://example.com -o report.json --keep-details # Creates: report.json, report.scan.json, report.plan.yml ``` #### GitHub Actions Example ```yaml - name: DAST Scan run: | xy-dast scan \ -u ${{ vars.APP_URL }} \ --profile spa \ --fail-on high \ --quiet \ -n ${{ github.repository }} \ -o dast-report.json env: XYGENI_TOKEN: ${{ secrets.XYGENI_TOKEN }} - name: Upload DAST Report if: always() uses: actions/upload-artifact@v4 with: name: dast-report path: dast-report.json ``` #### GitLab CI Example ```yaml dast_scan: image: xygeni/xy-dast:latest stage: test script: - xy-dast scan -u $APP_URL --profile spa --fail-on high --quiet -n $CI_PROJECT_NAME -o dast-report.json artifacts: paths: - dast-report.json when: always variables: XYGENI_TOKEN: $XYGENI_TOKEN ``` ### Command Reference ``` Usage: xy-dast scan [OPTIONS] -u Target Options: -u, --url= Base URL of the target application (required) --context-name= Scanner context name --openapi= OpenAPI/Swagger specification URL --graphql= GraphQL schema URL or file (introspection if omitted) --wsdl= WSDL definition URL or file for SOAP web services -pm, --postman= Postman collection (v2.x JSON) URL or file --postman-vars= Override Postman variables (comma-separated key=value) --navigation= Recorded navigation to seed the scan (.side and Chrome DevTools Recorder .json replayed, .har imported) --navigation-format= Format of --navigation: selenium|chrome-devtools|har (default: auto-detect) --navigation-only Scan only the recorded --navigation endpoints (skip crawl) --url-list= File with additional URLs --include= URL patterns to include (regex) --exclude= URL patterns to exclude (regex) Scan Options: -p, --profile= Tech-stack profile: traditional, spa, openapi, graphql, soap, cms, or custom --intensity= Scan intensity: quick, balanced (default), deep, passive --auto-profile Auto-detect target technology and select tech profile --list-profiles List available profiles and exit --timeout= Overall scan timeout (default: 60m) --spider-duration= Override spider duration --ajax-spider-duration= Override AJAX spider duration --active-scan-duration= Override active scan duration --passive-only Run only passive scan --lenient Continue scan despite OpenAPI validation errors --policy-strength= Attack strength: LOW, MEDIUM (default), HIGH, INSANE --exclude-rules= Comma-separated rule IDs to exclude --risk-threshold= Minimum risk level: HIGH, MEDIUM, LOW, INFO Deep Crawl: --deep-crawl Run deep crawl before scanning to discover URLs with headless JS support --crawl-depth= Deep crawl max depth (default: 3) --crawl-timeout= Deep crawl timeout (default: 5m) Vulnerability Check: --vuln-check Run vulnerability check after scanning for CVE detection and known vulnerability checks --vuln-check-severity= Severity filter (default: critical,high,medium) --vuln-check-rate-limit= Requests per second (default: 50) --vuln-check-timeout= Vulnerability check timeout (default: 15m) Out-of-Band Detection (OAST): --oast-service= Enable out-of-band detection: interactsh, boast, callback, none (default: none; inferred as interactsh when --oast is given) --oast= OAST server URL (Interactsh/BOAST) or callback advertised address --oast-token= Self-hosted OAST server auth token (supports env:VAR_NAME) --oast-poll-seconds= Poll frequency for interactsh/boast --oast-callback-port= Advertised callback port (0 = random); callback only Authentication: --login-url= Login form URL --username= Form authentication username --password= Form authentication password --username-field= Username field name (default: username) --password-field= Password field name (default: password) --bearer-token= Bearer token (supports env:VAR_NAME) --api-key-header= Header name for API key auth (e.g., X-API-Key) --api-key-value= Header value for API key auth (supports env:VAR_NAME) --basic-username= Username for HTTP Basic authentication --basic-password= Password for HTTP Basic auth (supports env:VAR_NAME) --client-cert= PKCS#12 client certificate for mTLS targets --client-cert-password= Certificate password (supports env:VAR_NAME) Incremental Scan: --incremental Scan only endpoints changed since a baseline (seed the changed set, skip the crawl); falls back to a full scan when none are available --changed-endpoints-file= Changed-endpoint manifest from 'xygeni apisecurity --incremental' (required) --baseline-report= Prior DAST report to carry unchanged-endpoint findings forward from (tagged 'kept-untested') Output Options: -o, --output= Output file (use '-' for stdout) --format= Output format for the file written by -o (default: json). 'sarif' emits SARIF v2.1.0 for GitHub Code Scanning. The Xygeni upload payload is always JSON. -n, --project-name= Project name for report --pretty Pretty-print the report (JSON or SARIF) --work-dir= Working directory for artifacts --no-upload Disable report upload to Xygeni backend --branch= Branch name for report upload --keep-details Keep raw scanner output (.scan.json) and generated automation plan (.plan.yml) -q, --quiet Suppress progress output, show only summary --fail-on= Exit with code 128 if alerts at or above severity (info, low, high, critical) Global Options: -v, --verbose Enable verbose output -nb, --no-banner Suppress the startup banner -h, --help Show help message -V, --version Show version information ``` ### Exit Codes | Code | Description | | ---- | ------------------------------------------ | | 0 | Scan completed successfully | | 1 | General error | | 2 | Scanner engine not found | | 3 | Scanner engine execution failed | | 4 | Invalid input arguments | | 128 | Alert threshold exceeded (see `--fail-on`) | ### Environment Variables | Variable | Description | Default | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------- | | `XYGENI_TOKEN` | API access token (required for report upload) | -- | | `XYGENI_URL` | Xygeni API endpoint | `https://api.xygeni.io` | | `XYGENI_DASHBOARD_URL` | Xygeni dashboard URL | `https://in.xygeni.io/dashboard` | | `XYGENI_DIR` | Base directory for logs | Current directory | | `XYGENI_DAST_DIR` | Configuration directory (containing `conf/`) | Script directory | | `XY_DAST_COMPOSE_FILE` | Override the location of the wrapper's `xy-dast-compose.yml` sidecar (which holds the image reference, environment forwarding, and runtime parameters) | `/xy-dast-compose.yml` | | `PROXY_HOST` | Proxy hostname | -- | | `PROXY_PORT` | Proxy port | `3128` | # DAST Scanner Configuration ### DAST Scanner Configuration The [**DAST Scanner**](/xygeni-products/dast-security/dast-scanner) is configured through **YAML scan profiles** that control how the scanner behaves for different types of applications. Profiles have **two independent axes**: a **tech base** (`--profile`) that describes *what the target is*, and a **scan intensity** (`--intensity`) that describes *how hard to scan*. They compose: ```bash # tech base × intensity xy-dast scan -u https://example.com --profile spa --intensity deep -o report.json ``` `--profile` selects the tech base (`traditional`, `spa`, `openapi`, `graphql`, `soap`, `cms`, or a custom profile); `--intensity` selects `quick`, `balanced` (default), `deep`, or `passive`. The intensity overlays attack strength, thresholds, phase durations, and CVE / deep-crawl enablement on top of the tech base, leaving its crawl and policy intact. ### Profile Locations Custom profiles can be placed in any of these directories: | Directory | Description | | ---------------------------- | ------------------------------------------ | | `$XYGENI_DAST_DIR/profiles/` | Installation-level profiles | | `./profiles/` | Project-level profiles (current directory) | | `./conf/profiles/` | Alternative project-level location | List all available profiles (built-in and custom): ```bash xy-dast scan --list-profiles ``` ### Tech Base × Intensity Built-in profiles split along two axes you combine with `--profile` and `--intensity`: | Axis | Option | Values | Controls | | ------------- | ------------- | --------------------------------------------------------- | ------------------------------------------------------------------- | | **Tech base** | `--profile` | `traditional`, `spa`, `openapi`, `graphql`, `soap`, `cms` | Scope, crawl, endpoint import, scan policy | | **Intensity** | `--intensity` | `quick`, `balanced` (default), `deep`, `passive` | Attack strength, thresholds, durations, CVE / deep-crawl enablement | Any tech base combines with any intensity: ```bash xy-dast scan -u https://api.example.com --profile openapi --intensity deep # deep API scan (CVE + deep crawl on) xy-dast scan -u https://app.example.com --profile spa --intensity quick # fast SPA smoke test xy-dast scan -u https://prod.example.com --profile traditional --intensity passive # production-safe: no active payloads ``` * `passive` skips the active scan entirely (crawl + passive analysis only) — safe for production/staging. * `deep` turns on CVE checking and the deep crawler and raises strength/durations. CVE and deep crawl can also be toggled independently on any intensity with `--vuln-check` and `--deep-crawl`. * When `--intensity` is omitted, `balanced` (the tech base's own settings) is used. `--auto-profile` picks the tech base; `--intensity` still applies on top. ### Profile Schema A profile is a YAML file with the following sections: ```yaml # Identity name: my-profile description: "Description of the profile" extends: openapi # Optional: inherit from a base profile # Scope - URL patterns to include/exclude scope: includePatterns: - "https://api.example.com/v2/.*" excludePatterns: - ".*logout.*" - ".*\\.js$" - ".*\\.css$" # Authentication (see "Authentication Configuration" below for every method) authentication: method: BEARER # NONE, FORM, BEARER, HEADER, BASIC, JSON, OAUTH2, SCRIPT loginUrl: "" # Login form URL (for FORM method) usernameField: "username" # Form field name for username passwordField: "password" # Form field name for password headerName: "Authorization" # Header name (for BEARER/HEADER) headerValue: "${env:API_TOKEN}" # Header value headerPrefix: "Bearer " # Header value prefix # Users (for form-based authentication) users: - name: "test-user" username: "admin" password: "admin123" default: true # Session management session: method: COOKIE # COOKIE, HEADER, or SCRIPT # import: # Pre-authenticated session import (SSO) — see below # cookies: [...] # headers: [...] # Technology context (helps optimize scanning) technology: language: javascript database: mysql framework: express include: - "Db / MySQL" - "Language / JavaScript" # Spider configuration # Durations: a positive value caps the phase; 0 means UNLIMITED (no timeout), never "skip". # To disable a phase, set its `skip: true` (or use the matching --skip-* CLI flag). spider: duration: 10 # Maximum duration in minutes (0 = unlimited) depth: 5 # Maximum crawl depth children: 10 # Maximum children per node skip: false # Set to true to disable the spider # AJAX Spider configuration (for SPAs) ajaxSpider: duration: 15 # Maximum duration in minutes (0 = unlimited) depth: 5 # Maximum crawl depth browsers: 4 # Number of browser instances skip: false # Set to true to disable AJAX spider # Active scan configuration activeScan: duration: 20 # Maximum duration in minutes (0 = unlimited) ruleDuration: 5 # Maximum duration per rule in minutes (0 = unlimited) policy: "" # Scan policy (e.g., "API-Scan") strength: "MEDIUM" # Attack strength: LOW, MEDIUM, HIGH, INSANE threshold: "MEDIUM" # Alert threshold: LOW, MEDIUM, HIGH skip: false # Set to true to disable active scan (= --passive-only / --skip-active-scan) rules: [] # Per-rule overrides (see below) # Passive scan configuration passiveScan: waitDuration: 5 # Maximum wait time in minutes # Passive WebSocket scanning — optional; see "WebSocket Scanning" below. # Equivalent to --websocket / --websocket-scripts on the CLI. Captured only # during AJAX spidering, so most useful for SPA targets (on by default for `spa`). webSocket: enabled: true # passiveScripts: # optional; omit to use the bundled disclosure scripts # - pii-disclosure # - email-disclosure # Deep crawl (headless browser-based pre-scan crawling) deepCrawl: enabled: false # Enable deep crawl before the scan (the `deep` intensity / --deep-crawl sets this) depth: 3 # Maximum crawl depth duration: "5m" # Crawl timeout (accepts: 30s, 5m, 1h) # Vulnerability check (template-based CVE/misconfiguration detection) vulnCheck: enabled: false # Enable post-scan vulnerability check (the `deep` intensity / --vuln-check sets this) severities: # Severity filter - critical - high - medium excludeTags: # Template tags to exclude (default: dos, fuzz) - dos - fuzz rateLimit: 50 # Requests per second timeout: "15m" # Scan timeout # templates: # Advanced: override template directories. The defaults # - ... # cover CVEs, exposures, misconfigurations, and known # # vulnerabilities and rarely need to be customised. # Client certificate (mTLS) — optional # Equivalent to --client-cert / --client-cert-password on the CLI. # Orthogonal to other authentication methods (combine as needed). clientCertificate: path: /path/to/client.p12 # PKCS#12 (.p12 / .pfx) certificate password: "${env:CERT_PASSWORD}" # Read from env to keep secrets out of YAML # Out-of-band detection (OAST) — optional; see "Out-of-Band Detection" below. # Equivalent to --oast-service / --oast / --oast-token on the CLI. Off by default. oast: service: interactsh # interactsh | boast | callback | none server: https://oast.internal.example.com # required for interactsh (no built-in default) token: "${env:OAST_TOKEN}" # self-hosted server auth token (env-resolved, never logged) # pollSeconds: 60 # poll frequency for interactsh/boast # port: 0 # advertised callback port (callback service only) # Result filtering filtering: excludeRules: # Rule IDs to exclude from results - "10094" riskThreshold: "" # Minimum risk: INFO, LOW, MEDIUM, HIGH ``` ### Profile Inheritance Use `extends` to inherit settings from a built-in or custom profile. Only the fields you specify are overridden; all other settings come from the parent. ```yaml name: my-api description: "Custom API profile with stricter scanning" extends: openapi activeScan: duration: 30 strength: HIGH ``` This profile inherits all settings from `openapi` (minimal spidering, no AJAX spider, API-Scan policy) but overrides the active scan duration and strength. For the intensity axis you rarely need `extends` at all: `--intensity {quick|balanced|deep|passive}` composes an intensity onto any tech base (built-in or custom) at scan time, so `--profile openapi --intensity deep` gives a deep API scan without a custom profile. ### Authentication Configuration #### FORM - HTML Form Login ```yaml authentication: method: FORM loginUrl: "https://app.example.com/login" usernameField: "username" passwordField: "password" users: - name: "test-user" username: "admin" password: "${env:APP_PASSWORD}" default: true ``` #### JSON - Login Returning a Token For a login endpoint that accepts JSON and answers with a token in the **response body** — the usual single-page-app shape. The scanner logs in, reads the token out of the reply, and sends it as the header you name on every subsequent request: ```yaml authentication: method: JSON jsonAuthUrl: "https://app.example.com/rest/user/login" jsonBody: '{"email":"{username}","password":"{password}"}' tokenJsonPath: "authentication.token" # dotted path into the login response headerName: "Authorization" headerPrefix: "Bearer " users: - name: "test-user" username: "${env:APP_USER}" password: "${env:APP_PASSWORD}" default: true ``` | Field | Meaning | | --------------- | ------------------------------------------------------------------------------------------------- | | `jsonAuthUrl` | Login endpoint the credentials are posted to | | `jsonBody` | Request body; `{username}` and `{password}` are filled from the `users` entry | | `tokenJsonPath` | Dotted path to the token in the login response, e.g. `authentication.token` or `data.accessToken` | | `headerName` | Header carrying the token on later requests (default `Authorization`) | | `headerPrefix` | Text placed before the token — usually `"Bearer "`, including the trailing space | The token is re-read from the login response whenever the scanner re-authenticates, so a long scan does not quietly continue as an anonymous user once the first token expires. {% hint style="info" %} Omit `tokenJsonPath` when the login sets a session **cookie** instead of returning a token: cookie session management is then used and no header is injected. {% endhint %} {% hint style="warning" %} `FORM` and `JSON` cannot log in without credentials to log in with. A profile declaring either without a `users:` block is refused before the scan starts, rather than running an unauthenticated scan that reports success. {% endhint %} #### BEARER - Bearer Token ```yaml authentication: method: BEARER headerName: "Authorization" headerValue: "${env:API_TOKEN}" headerPrefix: "Bearer " ``` #### HEADER - Custom Header ```yaml authentication: method: HEADER headerName: "X-API-Key" headerValue: "${env:API_KEY}" headerPrefix: "" ``` #### BASIC - HTTP Basic Authentication ```yaml authentication: method: BASIC users: - name: "test-user" username: "admin" password: "${env:BASIC_PASSWORD}" default: true ``` Credentials are Base64-encoded and sent as `Authorization: Basic ` on every request (RFC 7617). #### OAUTH2 - OAuth2 The scanner obtains an access token from the OAuth2 token endpoint **before** the scan and sends it as `Authorization: Bearer ` on every request. Three non-interactive grants are supported. ```yaml authentication: method: OAUTH2 grantType: CLIENT_CREDENTIALS # CLIENT_CREDENTIALS | PASSWORD | REFRESH_TOKEN tokenUrl: "https://idp.example.com/oauth/token" clientId: "${env:OAUTH_CLIENT_ID}" clientSecret: "${env:OAUTH_CLIENT_SECRET}" scope: "api.read" # optional ``` Additional optional fields cover provider differences and the other grants: ```yaml authentication: method: OAUTH2 grantType: PASSWORD tokenUrl: "https://idp.example.com/oauth/token" clientId: "${env:OAUTH_CLIENT_ID}" clientSecret: "${env:OAUTH_CLIENT_SECRET}" clientAuthMethod: "post" # "post" (default) sends credentials in the body; "basic" uses an HTTP Basic header audience: "https://api.example.com" # optional (e.g. Auth0) username: "${env:OAUTH_USERNAME}" # PASSWORD grant password: "${env:OAUTH_PASSWORD}" # PASSWORD grant refreshToken: "${env:OAUTH_REFRESH}" # REFRESH_TOKEN grant extraParams: # provider-specific token-request parameters resource: "urn:example:api" tokenLifecycle: # renew the token mid-scan on long runs (see below) expiryStatus: 401 ``` | Grant | Use case | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `CLIENT_CREDENTIALS` | Machine-to-machine API access (no user). | | `PASSWORD` | Scan as a user, using resource-owner credentials. | | `REFRESH_TOKEN` | Scan an API behind an interactive (browser) login: perform the login once out-of-band, capture the **refresh token**, store it as a secret, and let the scanner mint access tokens in CI. | **Token renewal for long scans.** By default the token is fetched once. If it might expire before the scan finishes, add a `tokenLifecycle` block so the scanner renews it during the scan and keeps authenticated coverage: ```yaml authentication: method: OAUTH2 grantType: REFRESH_TOKEN tokenUrl: "https://idp.example.com/oauth/token" clientId: "${env:OAUTH_CLIENT_ID}" clientSecret: "${env:OAUTH_CLIENT_SECRET}" refreshToken: "${env:OAUTH_REFRESH}" tokenLifecycle: expiryStatus: 401 # response status that signals expiry (default: 401) expiryPattern: "token.*expired" # optional response-body regex ``` On the CLI, `--token-refresh` enables this for the client-credentials flow (with `--token-expiry-status` to change the status code). Without it, the token is not renewed mid-scan — use token lifecycle, a longer-lived token, or a shorter scan. If a client certificate (`clientCertificate`) is configured, it is reused for the token endpoint when the endpoint requires mTLS (RFC 8705). {% hint style="info" %} Environment variables can be referenced with `${env:VARNAME}` syntax anywhere in profile values. This is the recommended approach for sensitive values like tokens and passwords. {% endhint %} #### SCRIPT - Scripted Browser Login (multi-step / advanced) For logins the declarative methods above cannot express — identifier-first flows, multi-page forms, JavaScript-gated logins, or apps that hand back the session token in a JS variable — provide a recorded **browser-automation script**. The scanner drives a real browser through the login, captures the resulting session (cookies, and tokens from response headers or browser storage), and injects it into the scan (active/passive scanning, the deep crawler, and the vulnerability check) — all authenticated. The script format is **Selenium IDE (`.side`)** today; the configuration is engine-neutral so other automation frameworks (e.g. Playwright) can be added in future. {% hint style="info" %} If the login is a single request that answers with the token in a JSON body, use [`JSON`](#json-login-returning-a-token) instead — it needs no browser and no recording, and re-reads the token whenever it re-authenticates. {% endhint %} ```yaml authentication: method: SCRIPT script: engine: selenium # selenium today; more frameworks planned file: auth/login.side # recorded login flow # seedNavigation: true # also use the login replay's traffic to seed the scan # # (default: on for the `spa` tech base, off otherwise) vars: # substituted into the script's ${VAR} placeholders USERNAME: "${env:DAST_USER}" PASSWORD: "${env:DAST_PASS}" extract: # optional: pin which value to reuse and how - name: bearer as: bearer # bearer | header: | cookie from: sessionStorage # sessionStorage | localStorage | cookie | responseHeader | responseBody | var key: currentUser jsonPath: $.token # optional, to dig into a JSON value ``` How the session is captured, layered (lowest-config first): (1) extraction the script itself declares (`store` / `executeScript` into a variable); (2) explicit `extract:` rules above; (3) otherwise a best-effort scan of cookies and browser storage (a captured JWT becomes a bearer header). {% hint style="info" %} Record the `.side` with the Selenium IDE browser extension. The **actuation** steps are replayed — navigation, field entry, clicks, checkboxes, waits, frame and window switches (`selectFrame` / `selectWindow`, so logins inside an iframe or a popup work), special keys recorded as `${KEY_ENTER}`, `${KEY_TAB}`, … and control flow (`if` / `else if` / `else` / `end`, `while`, `times`, `do` / `repeat if`) whose conditions are evaluated as JavaScript in the page. `assert`/`verify` test steps are ignored — the scanner authenticates, it does not run UI tests. Keep credentials out of the committed `.side` by using `${VAR}` placeholders supplied via `vars` (with `${env:...}`). {% endhint %} By default the login script is used **only to authenticate**. Set `script.seedNavigation: true` to also feed the pages it visits into the scan as navigation seeds — useful when the login flow already walks through gated areas you want covered. It defaults **on for the `spa` tech base** (whose JS-driven flows benefit most from seeds) and **off** otherwise; an explicit value always wins. This is separate from the standalone `--navigation` input, which seeds the scan from a recording independent of login. **When a recorded login does not complete** A scripted login that fails stops the scan, rather than continuing unauthenticated and reporting a misleadingly clean result for pages it never reached. The error names the step that failed, where the browser actually was, and two artifacts written next to the report: ``` Selenium .side step 10 of 10, command 'waitForElementVisible' on 'css=.app-header__profile' failed. Browser was at: https://app.example.com/login (page title: "Sign in") Screenshot: /path/to/xy-dast-side-failure-step10-waitForElementVisible.png Page snapshot: /path/to/xy-dast-side-failure-step10-waitForElementVisible.html Cause: Expected condition failed: waiting for visibility of element located by ... ``` The URL is usually the answer on its own — still on the login page means the flow never submitted, and the screenshot normally shows why. | What you see | Likely cause | | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Still on the login page, nothing visibly wrong | The submit click had no effect. A warning naming the element is logged when it never became clickable. | | Still on the login page, an error visible in the screenshot | Credentials rejected, or the app requires MFA / a captcha. | | A `Skipping .side step N/M ''` **warning** | The recording needs a step the scanner does not implement, so what followed ran against the wrong state. | | The step after a `selectFrame` cannot find its element | The frame locator did not match — check it against the recording. | | Timeout on the *first* step | The start URL is not reachable from the scanner. | | `unusable control flow` before any step runs | The recording's `if`/`while`/`do` blocks do not balance, or it uses `forEach` (unsupported). | | `condition … could not be evaluated in the page` | A recorded `if`/`while`/`repeat if` condition threw. It is never assumed true or false, since either guess would run the wrong half of the recording. | {% hint style="warning" %} The failure artifacts are written **only when a step fails**, to the report's output directory. Password fields are replaced with `***redacted***` in the page snapshot, but **the screenshot is not redacted** — it shows whatever was typed into visible fields, including the username. Treat both as sensitive. {% endhint %} #### Pre-authenticated Session Import (SSO / federated) For OIDC/SAML SSO targets (Okta, Microsoft Entra ID, …), authenticate **out-of-band** and hand the scanner the resulting session artifacts — no scripted login required. Orthogonal to the header-based methods (combinable with bearer / API-key / mTLS); mutually exclusive with form login. ```bash # CLI xy-dast scan -u https://app.example.com \ --session-cookie "SESSION=${SESSION_ID}" --session-cookie "XSRF-TOKEN=${XSRF}" \ --session-file session.json ``` ```yaml # Profile session: import: cookies: - name: SESSION value: "${env:SESSION_ID}" headers: - name: Authorization value: "Bearer ${env:SSO_TOKEN}" ``` Imported cookies are sent as a single `Cookie` request header and the headers verbatim, on every scan request. `--session-file` also accepts a **Playwright `storageState.json`** (the artifact from `context.storage_state()`): its cookies are imported and a JWT found in local storage becomes an `Authorization: Bearer` header, so a session captured by an existing Playwright login script needs no conversion. ### Authentication Methods Reference | Method | Description | Required Fields | | -------- | ------------------------------------------------------------------------ | ---------------------------------------------------------------- | | `NONE` | No authentication | -- | | `FORM` | HTML form login with username/password | `loginUrl`, `usernameField`, `passwordField`, `users` | | `JSON` | JSON login; the token is read from the response body | `jsonAuthUrl`, `jsonBody`, `tokenJsonPath`, `users` | | `BEARER` | Bearer token in Authorization header | `headerName`, `headerValue`, `headerPrefix` | | `HEADER` | Custom header authentication | `headerName`, `headerValue` | | `BASIC` | HTTP Basic authentication (RFC 7617) | `users` (username and password) | | `OAUTH2` | OAuth2 token acquired pre-scan, injected as a bearer token | `tokenUrl`, `clientId`, `clientSecret` (+ grant-specific fields) | | `SCRIPT` | Scripted browser login (Selenium `.side`) for multi-step / JS-gated auth | `script.engine`, `script.file` | Two further mechanisms are orthogonal to the `method` above and combine with it: **session import** (`session.import` / `--session-cookie` / `--session-file`) for pre-authenticated SSO sessions, and **client certificate** (`clientCertificate` / `--client-cert`) for mTLS. ### Out-of-Band Detection (OAST) Some vulnerabilities only reveal themselves **out-of-band** — the target opens a connection to a server you control rather than showing anything in its HTTP response. The scanner injects a payload and, if the target is vulnerable, it calls back to an **OAST server** (out-of-band application security testing). This is **off by default** (no surprise external callbacks); enable it with `--oast-service` / the `oast:` profile block. A bare `--oast ` infers `interactsh`. ```yaml oast: service: interactsh # interactsh | boast | callback | none server: https://oast.internal.example.com token: "${env:OAST_TOKEN}" # self-hosted only; env-resolved, never logged # pollSeconds: 60 # port: 0 # callback service only ``` CLI `--oast-*` flags take precedence over the profile block. #### Choosing a service — the reachability constraint An OAST callback only works if the **target** can reach the server *and* the scanner can observe the hit. Because the scanner runs in a container, pick the service to match how the target can reach back: | Service | How a hit is signalled | Use when | | ------------ | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | `callback` | Target connects back to the scanner's own advertised address (`--oast`/`--oast-callback-port`) | Target shares a network with the scanner (same Docker/host network) | | `boast` | Target does OOB to a BOAST server; scanner polls it | Public target with outbound egress (zero-config public server) | | `interactsh` | Target does OOB to an Interactsh server; scanner polls it | Public egress, or a **self-hosted** server both reach | * **`callback`** is the simplest, most reliable option for internal targets — the scanner is its own OAST server, no external service. It detects the HTTP-based rules (blind SSRF, blind XXE). * **Public** Interactsh/BOAST are best-effort — they depend on a third-party server being reachable. Prefer `callback` (internal) or a self-hosted server for dependable results. * **`interactsh` requires an explicit `--oast` URL** — there is no built-in default (a blank server leaves detection inert). Use `boast` for a zero-config public server. #### Per-rule detection | Rule | ID | Works with `callback` | | ---------------------------------------- | ----- | :------------------------------------------: | | Server Side Request Forgery (blind SSRF) | 40046 | ✅ | | XML External Entity Attack (blind XXE) | 90023 | ✅ | | Out-of-Band XSS | 40031 | ✅ (a browser must view the injected payload) | | Server Side Template Injection (blind) | 90036 | detected via timing¹ | | Log4Shell (CVE-2021-44228) | 44228 | ❌ needs an external OAST² | | Text4Shell (CVE-2022-42889) | 40047 | ❌ needs an external OAST² | ¹ Blind SSTI is detected by its time-based technique (no OAST server required). ² Log4Shell/Text4Shell payloads are JNDI/interpolation targets (`ldap://…`) the `callback` service can't carry; they need an `interactsh`/`boast` server. Log4Shell out-of-band is also covered independently by the [vulnerability check](/xygeni-products/dast-security/dast-scanner#vulnerability-check). #### Self-hosting an OAST server (internal / air-gapped targets) For internal targets that cannot route back to the scanner and have no public egress, run your own OAST server that **both the target and the scanner can reach**. The recommended option is [**projectdiscovery/interactsh**](https://github.com/projectdiscovery/interactsh): 1. **Provision** an `interactsh-server` on a host reachable by the target and the scanner (`go install github.com/projectdiscovery/interactsh/cmd/interactsh-server@latest`, or the published container image). 2. **Give it a domain.** Interactsh correlates via a unique DNS subdomain per payload, so its domain (e.g. `oast.internal.example.com`) needs an `NS` record pointing at the server, and the server must be reachable on DNS (53) and HTTP/S (80/443). Protect the poll API with a token (`-token`). This is the server's *own* (local) DNS — **not** public internet DNS exfiltration. 3. **Point the scanner at it:** ```bash xy-dast scan -u https://app.internal \ --oast-service=interactsh \ --oast=https://oast.internal.example.com \ --oast-token env:OAST_TOKEN ``` When `--oast-service=interactsh` is used with a server, the [vulnerability check](/xygeni-products/dast-security/dast-scanner#vulnerability-check) phase is pointed at the **same** server, so out-of-band detection is consistent across both engines. {% hint style="info" %} Run the self-hosted OAST server alongside the target, **not** inside the scanner container. Ensure the `interactsh-server` version is protocol-compatible with the scanner's OAST client. {% endhint %} ### WebSocket Scanning Applications that push data over **WebSocket** channels (`ws://` / `wss://`) can leak information the ordinary HTTP scan never sees. When enabled, the scanner runs **passive** checks over every WebSocket message exchanged during the scan — no messages are injected or replayed, so it is safe against production-like targets. ```yaml webSocket: enabled: true # passiveScripts: # optional; omit to use the bundled disclosure scripts # - pii-disclosure # - email-disclosure ``` Enable it with the `webSocket:` profile block or `--websocket`; `--websocket-scripts name1,name2` overrides the profile's `passiveScripts`. It is **on by default for the `spa` profile** and off elsewhere. {% hint style="info" %} WebSocket channels are captured only while the **AJAX spider** drives a real browser through the scanner — so this applies to SPA/AJAX scans, not the plain spider or an API-only (OpenAPI/Postman) import. {% endhint %} When no scripts are selected, a bundled set of disclosure checks runs: `pii-disclosure`, `email-disclosure`, `base64-disclosure`, `application-error`, `debug-error-disclosure`, and `xml-comments-disclosure`. A script named in the selection but not found is skipped with a warning — it never fails the scan. ### Per-Rule Policy Overrides The `activeScan.rules` list allows you to override threshold and strength for individual scan rules, or disable rules entirely: ```yaml activeScan: duration: 20 strength: MEDIUM rules: # Enable specific rules with higher strength - id: 40018 name: "SQL Injection" threshold: "Medium" strength: "High" - id: 40012 name: "Cross Site Scripting (Reflected)" threshold: "Medium" strength: "High" # Disable a rule - id: 30001 name: "Buffer Overflow" threshold: "Off" ``` {% hint style="info" %} Setting `threshold: "Off"` disables a rule entirely. Valid threshold values are `Off`, `Low`, `Medium`, and `High`. Valid strength values are `Low`, `Medium`, `High`, and `Insane`. {% endhint %} ### Example: OWASP Juice Shop Profile This complete example shows a custom profile for scanning the OWASP Juice Shop application: ```yaml name: example-juiceshop description: "Profile for OWASP Juice Shop application" extends: spa scope: includePatterns: - "http://localhost:3000/.*" excludePatterns: - ".*\\.js$" - ".*\\.css$" - ".*\\.png$" - ".*socket\\.io.*" - ".*logout.*" technology: language: javascript database: mysql framework: express include: - "Db / MySQL" - "Language / JavaScript" ajaxSpider: duration: 10 depth: 8 browsers: 3 skip: false activeScan: duration: 20 ruleDuration: 5 strength: "HIGH" threshold: "MEDIUM" rules: - id: 40018 name: "SQL Injection" threshold: "Medium" strength: "High" - id: 40012 name: "Cross Site Scripting (Reflected)" threshold: "Medium" strength: "High" - id: 40014 name: "Cross Site Scripting (Persistent)" threshold: "Medium" strength: "High" - id: 40026 name: "Cross Site Scripting (DOM Based)" threshold: "Medium" strength: "High" - id: 6 name: "Path Traversal" threshold: "Medium" strength: "High" - id: 90023 name: "XML External Entity Attack" threshold: "Medium" strength: "High" # Disable low-value rules for this app - id: 30001 name: "Buffer Overflow" threshold: "Off" - id: 40003 name: "CRLF Injection" threshold: "Off" ``` Run with: ```bash xy-dast scan -u http://localhost:3000 --profile example-juiceshop -o report.json ``` ### Profile Schema Reference | Section | Fields | Description | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | `name`, `description` | string | Profile identity | | `extends` | string | Parent profile to inherit from | | `scope` | `includePatterns`, `excludePatterns` | Regex lists for URL filtering | | `authentication` | `method`, `loginUrl`, `usernameField`, `passwordField`, `headerName`, `headerValue`, `headerPrefix`; OAuth2: `grantType`, `tokenUrl`, `clientId`, `clientSecret`, `scope`, `audience`, `username`, `password`, `refreshToken`, `clientAuthMethod`, `extraParams` | Authentication settings | | `users` | List of `{name, username, password, default}` | Credentials for form-based auth | | `session` | `method` | Session management: `COOKIE`, `HEADER`, or `SCRIPT` | | `technology` | `language`, `database`, `framework`, `include` | Technology context for scan optimization | | `spider` | `duration`, `depth`, `children` | Traditional spider settings | | `ajaxSpider` | `duration`, `depth`, `browsers`, `skip` | AJAX spider settings (for SPAs) | | `activeScan` | `duration`, `ruleDuration`, `policy`, `strength`, `threshold`, `rules` | Active scan settings | | `passiveScan` | `waitDuration` | Passive scan wait time | | `webSocket` | `enabled`, `passiveScripts` | Passive WebSocket scanning (SPA/AJAX only); on by default for `spa`. See [WebSocket Scanning](#websocket-scanning) | | `deepCrawl` | `enabled`, `depth`, `duration` | Pre-scan deep crawling | | `vulnCheck` | `enabled`, `templates`, `severities`, `excludeTags`, `rateLimit`, `timeout` | Post-scan vulnerability checking | | `clientCertificate` | `path`, `password` | PKCS#12 client certificate for mTLS targets (orthogonal to other auth methods) | | `oast` | `service`, `server`, `token`, `pollSeconds`, `port` | Out-of-band detection (OAST); off by default. See [Out-of-Band Detection](#out-of-band-detection-oast) | | `filtering` | `excludeRules`, `riskThreshold` | Result filtering | # Incremental DAST Scanning ### Incremental DAST Scanning A full DAST scan crawls and attacks the entire application on every run. On a typical pull request, though, only a few endpoints have actually changed. **Incremental scanning** re-tests only those changed endpoints and merges the result with the previous scan, so the report is still a complete snapshot — while cutting scan time dramatically on pull-request pipelines. Incremental scanning is **off by default**. Enable it with `--incremental`. ### How the changed endpoints are determined The endpoints to re-test come from one of two sources. The preferred one is Xygeni's **API Security** scan; where that is not available, the DAST scanner compares the endpoint surface your own inputs describe. Both are covered below. #### From API Security (preferred) The endpoints to re-test are identified by Xygeni's **API Security** scan. API Security compares the current code against the baseline using a **semantic signature** for each endpoint (its method, path, parameters, authentication requirements, response shape, and handler logic). Because the comparison is semantic, cosmetic edits — renaming, reformatting, or comment-only changes — do **not** mark an endpoint as changed, so you never waste time re-scanning endpoints that did not really change. API Security writes the result to a manifest file, `.xygeni.changed-endpoints.json`, describing which endpoints changed, which are unchanged, and (implicitly) which were removed. It prints the manifest path at the end of the scan. ```bash xygeni apisecurity --incremental --dir ./my-api --branch "$PR_BRANCH" ``` ### Running an incremental scan Pass the manifest to the DAST scanner, together with the previous DAST report as the baseline: ```bash xy-dast scan -u https://app.example.com \ --incremental \ --changed-endpoints-file ./.xygeni.changed-endpoints.json \ --baseline-report previous-dast-report.json \ -o report.json ``` The scanner seeds the changed endpoints directly, **skips crawling**, and actively tests (and vulnerability-checks) only those endpoints. It then merges the previous report so the output is a full snapshot. | Option | Description | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `--incremental` | Enable incremental scanning. | | `--changed-endpoints-file ` | The `.xygeni.changed-endpoints.json` manifest from API Security. Optional — the scanner finds it automatically when it is written next to the scan. | | `--baseline-report ` | The previous DAST report, used to carry findings on unchanged endpoints forward. Optional — the previous scan's own report is reused when this is not given. | ### What the merged report contains The incremental report matches what a full scan would have produced: | Endpoint | Result in the report | | ------------- | -------------------------------------------------------------------------------------- | | **Changed** | Fresh results from this run. A finding that no longer appears is treated as **fixed**. | | **Unchanged** | Previous findings are **carried forward**, marked **`kept-untested`**. | | **Removed** | Dropped from the report. | Occasionally an endpoint in the changed set cannot be turned into a request — a path template the scanner cannot fill, or an address outside the target. It is skipped with a warning naming it, and the rest of the changed endpoints are still scanned; the run is not abandoned. The **`kept-untested`** marker is important: because an unchanged endpoint was not actually re-attacked in this run, its findings are preserved (never silently reported as fixed) but flagged as *not re-verified this run*. A periodic full scan re-confirms them. ### Preparing the baseline Incremental scanning compares against the previous scan, so the first run for a project and branch always tests everything — there is nothing to compare with yet. You do not have to prepare for this. **Every** DAST scan records what a later incremental run needs, so `--incremental` narrows from the next run onward, even if the earlier scans were ordinary ones. The one part the DAST scanner cannot prepare by itself is the API Security side: that baseline lives in the Xygeni scanner's own cache, and only that scanner writes it. A DAST scan therefore prints the command to establish it: ```bash xygeni apisecurity --incremental --dir --branch ``` Or, if you pass `--sources` and the Xygeni scanner is installed alongside, the DAST scan establishes that baseline for you as part of the run — so the very first `--incremental` afterwards can narrow. ### Keeping the baseline fresh To prevent the baseline from drifting over many incremental runs, the scan automatically switches back to a **full scan** when: * there is no baseline yet (first run); * a broad change (such as a security-configuration or dependency change) affects the whole application; * more than a configurable share of endpoints changed in a single run — controlled by `fullScanThreshold` in `xy-dast.yml` (default **30**%). The recommended pattern is to run **incremental scans on pull requests** and a **full scan periodically** (for example nightly, or on merges to your main branch). If neither source can produce a changed set, the scan falls back to a full scan automatically. #### From your sources, at scan time If the Xygeni scanner is installed alongside the DAST scanner, point `--sources` at your code and the changed endpoints are worked out as part of the scan — you do not have to run API Security yourself or pass a manifest: ```bash xy-dast scan -u https://app.example.com --sources ./my-api --incremental ``` This discovers endpoints only; it does not look for API security flaws and it uploads nothing, so it neither replaces nor affects your API Security results. The first run establishes the baseline and still scans everything; runs after it are narrowed. Where the DAST scanner runs in a container, it cannot reach a Xygeni scanner installed on the host. It then prints the command to run and continues with a full scan. Note that **API Security is a separately licensed feature**. If your licence does not include it, or the analysis cannot complete for any other reason, the DAST scan reports why and continues as a full scan — it never fails because of it. Use the endpoint-surface comparison below in that case; it needs no API Security licence. #### From your API description (no API Security needed) When no manifest is available, the DAST scanner compares the endpoint surface described by the inputs you already pass — an OpenAPI specification, a Postman collection, a GraphQL schema, a WSDL, a recorded navigation, or a URL list — against the surface recorded by the previous scan, and re-tests what differs: ```bash xy-dast scan -u https://app.example.com --openapi ./openapi.yaml --incremental ``` This needs no API Security licence and no access to the source code. It does have a limit worth understanding: it compares only what those inputs **declare**, so a handler rewritten behind a route whose path and parameters did not change looks unchanged and is not re-tested. Where the sources and an API Security licence are available, prefer the manifest. The first run records the surface and scans in full — there is nothing to compare against yet — so the saving begins on the second run. Each report records which source was used, as the `dast.incremental.modality` property. ### Requirements and scope * An **API Security** scan of the repository gives the most precise changed set; it requires the API Security feature in your licence. Without it, the DAST scanner falls back to comparing the endpoint surface your inputs describe (see above), which needs no additional licence. * Authentication still runs on every scan; incremental scanning does not shortcut login. # DAST Detectors The DAST scanner uses two complementary detection sources: | Source | Detector IDs | What it finds | | ------------------------------------ | -------------------------------------------- | -------------------------------------------------------------------------------------- | | Active and passive scan rules | Numeric IDs (e.g., `40018`, `40012`) | Injection, XSS, authentication issues, security misconfigurations — over 200 detectors | | Vulnerability check (`--vuln-check`) | `vuln/` prefix (e.g., `vuln/CVE-2021-44228`) | Known CVEs, misconfigurations, and exposures matched by template signatures | Both sources produce findings in the same report. Each detector is mapped to a **CWE** identifier, and — where applicable — to the matching **NIST 800-53**, **SANS Top 25**, and **PCI DSS** controls, so DAST results can be traced directly to compliance requirements. Detectors also include remediation guidance. The full detector list with descriptions and references is published at [detectors.xygeni.io](https://detectors.xygeni.io/xydocs/dast/detectors/index.html). # API Security ### **Overview** Xygeni's **API Security** scanner discovers the API surface of an application — its services, endpoints, parameters, request and response shapes — and analyses it for the **OWASP API Security Top 10 (2023)** risks. It is a **static** analysis: the scanner reads source code and API descriptors and produces an inventory and a set of flaws, with no live traffic against a running application. API Security pairs naturally with the rest of the Xygeni platform. The **inventory** it produces is the join key that links **static** handler code (SAST findings) to **dynamic** endpoint behaviour (DAST findings) in the Risk Graph, giving security and engineering teams a single, deduplicated view of "what does my API expose, and which findings touch it?". ### **Protect APIs from Design and Implementation Flaws** APIs are the primary integration surface of modern applications — and the primary attack surface. Xygeni's API Security scanner is built to detect: * **Broken authentication and authorization** — unauthenticated endpoints (API2), missing role checks on admin-shaped routes (API5), missing ownership checks on object-by-id endpoints (API1 / IDOR). * **Sensitive data exposure** — PII / PCI / PHI fields reaching the wire (API3 / API10), over-fetched response shapes, sensitive parameters on unauthenticated endpoints (API2 + API3). * **Mass assignment** — request bodies that bind to privileged attributes (API3 write side). * **Configuration risks** — permissive CORS (API8), JWT misconfiguration (API2), absence of rate limiting (API4), Server-Side Request Forgery (API7). * **Inventory drift** — endpoints in code that are missing from the OpenAPI / Swagger spec, and operations declared in the spec with no corresponding handler (API9 — *shadow* and *orphan* APIs). Each flaw is mapped to its **OWASP API Top 10 (2023)** entry as the primary taxonomy, and to one or more **CWE** identifiers as the secondary taxonomy. Findings are produced with the same metadata, evidence, and severity model as the other Xygeni scans, so they integrate uniformly into dashboards, gates, and compliance reports. ### Supported Frameworks Endpoint discovery is framework-aware. The scanner ships with detectors for the most-used API frameworks across six languages: | Language | Frameworks | | ----------- | --------------------------------------------------------- | | **Java** | Spring MVC / Spring Boot, JAX-RS | | **C#** | ASP.NET Core (Controllers and Minimal APIs) | | **Python** | FastAPI, Flask, Django / Django REST Framework, Connexion | | **JS / TS** | Express, NestJS, Koa, Fastify, Hono | | **Go** | net/http, Gin, Echo, Chi, Fiber, gorilla/mux | | **PHP** | Laravel, Symfony, Slim | | **Any** | OpenAPI 3.x and Swagger 2.x specifications (YAML or JSON) | Before each scan, a lightweight **framework autodiscovery** pre-pass inspects the project's dependency manifests (`pom.xml`, `build.gradle`, `package.json`, `requirements.txt`, `pyproject.toml`, `*.csproj`, etc.) to determine which frameworks are present, and loads only the relevant detectors. This keeps scan time low and avoids cross-framework false positives. ### Scan Modes The scanner supports two modes selected by a single CLI flag: | Mode | What it does | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Full scan** | Discovery + flaw detection. Inventory plus all enabled OWASP API risk detectors. This is the default. | | **Inventory-only** | Discovery only (`--discovery-only`). No flaw detection. Useful when feeding the endpoint inventory to SAST / DAST correlators, or for catalog generation. | Even in inventory-only mode, the scanner runs **sensitivity classification** — endpoints, parameters, and DTO fields carry their PII / PCI / PHI / credential tags either way, since SAST and DAST correlators rely on those tags to score risk. For more information regarding API Security, refer to these sections: * [API Security User Interface Guide](/xygeni-products/api-security/api-security-user-interface-guide) * [Risks (API Security)](/xygeni-products/api-security/api-security-user-interface-guide/risks-api-security) * [API Security Scanner](/xygeni-products/api-security/api-security-scanner) * [API Security Scanner Configuration](/xygeni-products/api-security/api-security-scanner/api-security-scanner-configuration) * [API Security Detectors](/xygeni-products/api-security/api-security-detectors) # API Security User Interface Guide The API Security User Interface can be accessed by selecting the **API Security** option under the [Risks](/xygeni-products/application-security-posture-management-aspm/all-risks) tab. The API Security section includes the following content: * [Risks (API Security)](/xygeni-products/api-security/api-security-user-interface-guide/risks-api-security): A summary of all API Security issues detected across your applications, with the endpoint inventory, the flaws raised against each endpoint, and the OWASP API Security Top 10 (2023) mapping for every finding. # API Security Risks The **Risks (API Security) page** can be accessed by selecting the **API Security** option in the [**Risks**](/xygeni-products/application-security-posture-management-aspm/all-risks) tab. This tab presents the full set of findings raised by the API Security scanner, organised so flaws can be triaged quickly. {% hint style="info" %} Xygeni's API Security findings come from the bundled [API Security Scanner](/xygeni-products/api-security/api-security-scanner). API Security findings are automatically correlated with SAST and DAST findings on the same endpoint in the [Xygeni ASPM Risk Graph](/xygeni-products/application-security-posture-management-aspm), so a single broken endpoint shows the *static* code-level evidence, the *dynamic* runtime evidence, and the *shape* evidence side by side. {% endhint %} ## Inventory Each API Security scan produces an **endpoint inventory** in addition to the flaw list. The inventory is the structural backbone of the report and is exposed on its own panel: * **Services** — deployable applications or microservices discovered in the project (typically one per detected framework manifest). * **Modules** — controllers, resources, or routers that group related endpoints under a common path prefix. * **Endpoints** — individual callable operations. Each endpoint carries its HTTP method, path, authentication requirement, parameter list, and handler location (source file + line). * **Data Objects** — request and response shapes (DTOs / schemas / structs) referenced by endpoints. Fields are individually tagged when classified as PII / PCI / PHI / credential / crypto by the sensitivity classifier. The inventory is also written even in **inventory-only** mode (`--discovery-only`) — see the [API Security Scanner](/xygeni-products/api-security/api-security-scanner) page. ## Finding Details Each API Security finding (an *ApiFlaw*) includes the following information: * **Detector ID**: the rule that produced the finding (for example, `broken_object_level_authorization`, `excessive_data_exposure_java`, `unauthenticated_endpoint`). * **Severity**: the risk level — `critical`, `high`, `medium`, `low`, or `info`. Several detectors are *tiered* — for example, `cors_misconfiguration` produces HIGH when wildcard origin is combined with credentials, LOW for wildcard alone. * **Confidence**: how confident the scanner is in the finding — `low`, `medium`, `high`. Per-language detectors that walk the handler AST raise confidence to `high` when explicit evidence is found. * **Endpoint**: the affected endpoint — method, path, service, module, and handler source location. * **OWASP API Top 10 (2023)**: the matching entry — `API1:2023` through `API10:2023` — surfaced as a tag for filtering and as a column on the listing. * **CWE**: the associated Common Weakness Enumeration identifier(s). * **Compliance mappings**: where applicable, findings carry tags for **GDPR**, **PCI-DSS**, and **NIST SP 800-53** controls, so API Security results can be traced directly to compliance requirements. * **Evidence**: the concrete signal that produced the finding — for example, the request-body field name that triggered a Mass Assignment finding, the response DTO field tagged PII that produced an Excessive Data Exposure finding, or the OpenAPI operation that has no matching handler for an Orphan Spec finding. * **Remediation**: per-detector guidance, with framework-specific examples linked from the [API Security Detectors](/xygeni-products/api-security/api-security-detectors) catalog. ## Composite Findings The API Security scanner runs a **flaw correlator** that emits a composite finding when two related signals coincide on the same endpoint. The most important is: * **`pii_leak_in_unauthenticated_endpoint`** — emitted at **CRITICAL** severity when an endpoint is flagged both `pii_leak_in_response` *and* `unauthenticated_endpoint`. A single, prioritised line item replaces the two individual findings on the listing while preserving full traceability back to its component flaws. ## Severity Levels API Security findings are mapped to five severity levels: | Severity | Description | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Critical** | Directly exploitable, high-impact (composite findings such as PII leak on an unauthenticated endpoint, JWT `alg: none` accepted, signature verification disabled). | | **High** | Likely-real defect with confirmed evidence — BOLA / BFLA with no ownership / role check, PII / PCI / PHI in response, mass assignment of privilege fields, wildcard CORS with credentials. | | **Medium** | Plausible defect that needs review (typically MEDIUM-tier confidence variants of HIGH detectors — e.g. excessive data exposure on a field referenced in the request). | | **Low** | Defence-in-depth issues with limited direct impact — wildcard CORS without credentials, rate-limit absence (advisory; infrastructure-level limits are not visible to static analysis), SSRF-shaped parameter alone. | | **Info** | Informational findings flagged for context (typically suppressed candidates and inventory annotations). | ## Filtering and Triage Beyond the standard severity / confidence filters available across all Xygeni scans, the API Security view offers two API-specific facets: * **OWASP API Top 10 (2023)** — filter findings by `API1` through `API10`. Useful when working a single risk category across the codebase. * **Authentication state** — restrict the listing to endpoints flagged as *unauthenticated* (independently of any flaw they may carry), or conversely to endpoints that *do* require authentication. These compose with the global filters (severity, confidence, kind, project, repository, branch, tags), so a typical triage view — "all CRITICAL or HIGH API1 / API3 findings on `main` for the production projects" — is one click away. # API Security Scanner ## Table of Contents 1. [Purpose](#purpose) 2. [Installation](#installation) 3. [Quick Start](#quick_start) 4. [Scan Modes](#scan_modes) 5. [Inputs — Directory, Repository, Staged Files](#inputs) 6. [Hybrid Scanning — Specs & Live Probing](#hybrid) 7. [Output Formats](#outputs) 8. [Backend Upload](#upload) 9. [Framework Selection](#frameworks) 10. [CI / CD Integration](#cicd) 11. [Command Reference](#command_reference) 12. [Exit Codes](#exit_codes) ### Purpose The **API Security Scanner** performs static API discovery and security analysis on a source-code project. It walks the project tree and any OpenAPI / Swagger descriptors, builds an inventory of services, modules, endpoints, parameters, and data objects, and then runs the OWASP API Security Top 10 (2023) detectors against the inventory to produce a list of flaws. The scanner is invoked through the standard Xygeni CLI as the `apisecurity` subcommand. It produces the same metadata, evidence, and severity model as the other Xygeni scans, so its findings integrate uniformly into dashboards, gates, and compliance reports. ### Installation The API Security scanner ships as part of the Xygeni Scanner — there is no separate binary or container. Install the Xygeni Scanner following the [Xygeni CLI Installation guide](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-installation), then verify the `apisecurity` subcommand is available: ```bash xygeni apisecurity --help ``` ### Quick Start Scan a local checkout and write a JSON report: ```bash xygeni apisecurity --dir /path/to/project -f json -o report.json ``` Inventory-only mode (no flaw detection): ```bash xygeni apisecurity --dir /path/to/project --discovery-only -f json -o inventory.json ``` Scan and upload to the Xygeni backend: ```bash xygeni apisecurity --dir /path/to/project --upload ``` ### Scan Modes Two modes selected by a single flag: | Mode | Flag | What it does | | ------------------ | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Full scan** | (default) | Discovery + flaw detection. The inventory plus all enabled OWASP API risk detectors run end to end. | | **Inventory-only** | `--discovery-only` | Discovery only. No flaw detection. Useful for feeding the inventory to SAST / DAST correlators, generating an API catalog, or comparing the implemented API against a documented spec without producing flaw findings. Sensitivity classification (PII / PCI / PHI / credential tags) still runs in this mode. | ### Inputs — Directory, Repository, Staged Files Three input modes: | Flag | Effect | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | `--dir ` (default) | Scan a local checkout. | | `-r, --repo ` `--branch …` | Clone the remote repository to a temporary directory, scan it, and remove the clone after the scan completes. | | `--staged-files` | Scan only files staged in the local git index — useful as a pre-commit gate. Requires `--dir` to point at a git working tree. | `--include` and `--exclude` accept comma-separated glob patterns to narrow the file set further (for example, `--exclude '**/test/**,**/build/**'`). ### Hybrid Scanning — Specs & Live Probing Beyond the source-code scan, two optional inputs let you enrich and confirm the analysis: | Flag | Effect | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--spec ` | Ingest one or more OpenAPI / Swagger specs — local files **or** `http(s)` URLs — in addition to anything auto-discovered under `--dir`. Repeatable or comma-separated. Endpoints from the spec are merged into the same inventory, which also powers the `zombie_endpoint` / `orphan_spec` drift detector. | | `--base-url ` | Deployed-app base URL that **enables opt-in live probing** (off unless provided). For detectors that support it, the scanner issues a request per candidate endpoint and reads the gateway's response to confirm or refute the static verdict. | ```bash # Source scan + explicit specs (file and URL) xygeni apisecurity --dir . --spec openapi.yaml,https://api.example.com/openapi.json # Confirm "unauthenticated endpoint" findings against a live deployment xygeni apisecurity --dir . --base-url https://api.dev.example.com ``` Live probing is **non-destructive**: it never removes findings, it annotates each probed flaw with a `liveProbe` property — * `confirmed-` — the endpoint answered without credentials (the static finding is corroborated), * `refuted-401` / `refuted-403` — the deployed gateway enforces authentication the source did not show, * `unreachable` — the endpoint could not be contacted (connection refused, timeout, TLS error). Probes run concurrently with a bounded pool and a per-request timeout, and any network error is isolated — probing never aborts a scan. It is opt-in precisely because it makes outbound requests to the target you name; do not point `--base-url` at production without authorization. ### Output Formats `-f` (repeatable) selects one or more output formats; `-o` selects the target file. When more than one format is requested, the file name is decorated with the format extension. | Format | Description | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `text` (default) | Human-readable summary on stdout. Best for ad-hoc scans and developer feedback. | | `json` | Full report shape — services, modules, endpoints, data objects, flaws, statistics, scanner metadata. The canonical machine-readable shape. | | `xygeni-json` | Xygeni backend wire format — internally used by `--upload` but also emittable for offline upload pipelines. | | `csv` | Flat, one-row-per-finding tabular export for spreadsheets and quick triage. | | `markdown` | Markdown summary, convenient for PR comments and CI job summaries. | | `sarif` | SARIF 2.1.0 — for ingestion by GitHub Code Scanning, Azure DevOps, and other tools that consume SARIF. | The JSON shape mirrors the other Xygeni scans (`metadata`, `statistics`, top-level finding arrays, scanner properties, SCM information from the git working tree) so existing JSON consumers extend uniformly. ### Backend Upload ```bash xygeni apisecurity --dir /path/to/project --upload ``` `--upload` uses the standard Xygeni backend ingest endpoint, the same one used by the SCA / SAST / Secrets / IaC scanners. The project is resolved by name (defaulting to the directory name; override with `-n `), and the report is pushed under the same project's API Security scan history. A scan that does *not* set `--upload` produces local output only — useful for CI gates and pre-commit hooks where backend persistence is not desired. ### Framework Selection By default, **framework autodiscovery** is on: a lightweight pre-pass inspects the project's dependency manifests and loads only the detectors that match detected frameworks. This keeps scan time low and avoids cross-framework false positives. Two flags override autodiscovery: | Flag | Effect | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | `--frameworks ` | Pin the framework allowlist. Autodiscovery is **skipped** when this flag is set — user selection wins. | | `--skip-frameworks ` | Add a framework denylist. Honored **after** autodiscovery, so the autodiscovered list is filtered against the denylist. | Framework IDs follow the per-language naming used in [`xygeni.apisecurity.yml`](/xygeni-products/api-security/api-security-scanner/api-security-scanner-configuration) — for example, `spring-mvc`, `jax-rs`, `aspnet-core`, `fastapi`, `flask`, `django`, `express`, `nestjs`, `koa`, `fastify`, `hono`, `gin`, `laravel`, `openapi`. ### CI / CD Integration The scanner is intended to be invoked from CI alongside the other Xygeni scans, typically against the project's `main` branch on each push and against the PR head on pull requests. Two common patterns: ```yaml # Full scan on push to main — upload to backend - name: API Security scan run: xygeni apisecurity --dir . --branch main --upload # Pre-merge gate — fail the build on HIGH or above - name: API Security gate run: xygeni apisecurity --dir . --fail-on high ``` `--fail-on ` and `--never-fail` parallel the other Xygeni scans for gate behaviour. Most teams gate on HIGH for the first few weeks of adoption, then progressively tighten to MEDIUM as the noise floor settles. ### Command Reference | Flag | Description | | -------------------------- | ------------------------------------------------------------------------------------------------------------ | | `--dir ` | Local project directory to scan. | | `-r, --repo ` | Clone a remote repository, scan it, and clean up after. | | `--branch ` | Branch to check out from the repository (used with `-r`) or to record on the report (used with `--dir`). | | `--staged-files` | Scan only files in the git staging area. | | `-n, --name ` | Project name (defaults to inferred from `--dir`). | | `--discovery-only` | Inventory-only mode — skip flaw detection. | | `--frameworks ` | Comma-separated framework allowlist (skips autodiscovery). | | `--skip-frameworks ` | Comma-separated framework denylist (applied after autodiscovery). | | `--include ` | Comma-separated include globs. | | `--exclude ` | Comma-separated exclude globs. | | `--spec ` | OpenAPI / Swagger spec file(s) or URL(s) to ingest alongside the source scan (repeatable / comma-separated). | | `--base-url ` | Deployed-app base URL; enables opt-in live probing for detectors that support it (off unless set). | | `-c, --conf ` | Override the bundled `xygeni.apisecurity.yml`. | | `-f ` (repeatable) | Output format(s) — `text`, `json`, `xygeni-json`, `csv`, `markdown`, `sarif`. | | `-o, --output ` | Output file (extension added when multiple formats are requested). | | `-u, --upload` | Upload the report to the Xygeni backend. | | `--fail-on ` | Exit non-zero on findings of the given severity or above. | | `--never-fail` | Always exit `0`, regardless of findings. | ### Exit Codes These match the shared Xygeni exit-code convention used by the other scanners: | Code | Meaning | | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `0` | Success — no findings, all findings below the `--fail-on` threshold, or `--never-fail` set. | | `1` | Invalid arguments. | | `2` | Scan setup / run error (e.g., directory not found, repository clone failed). | | `128` | At least one finding matched `--fail-on` — used when `--fail-on` is a **severity threshold** (or is given with no value, meaning "any finding"). | | `129` | At least one finding matched a `--fail-on` **detector / expression** selector. | # API Security Scanner Configuration ### API Security Scanner Configuration The [**API Security Scanner**](/xygeni-products/api-security/api-security-scanner) is configured through a YAML file, `xygeni.apisecurity.yml`, that controls framework autodiscovery, per-detector enablement and tuning, sensitivity classification overrides, and the flaw correlation rules. A default configuration is bundled with the scanner. Most projects do not need to override it. A project-specific configuration is loaded automatically when a file named `xygeni.apisecurity.yml` is present in the scan directory, or explicitly via `-c `. ### Configuration File Layout ```yaml # Framework autodiscovery — lightweight pre-pass that probes the project's # dependency manifests to load only the relevant detectors. autodiscovery: enabled: true confidence_threshold: 0.5 # minimum probe confidence to accept a framework # Frameworks allowlist / denylist. When `enabled` is non-empty, autodiscovery # is skipped. `disabled` always applies after autodiscovery. frameworks: enabled: [] # e.g. ['spring-mvc', 'openapi'] disabled: [] # e.g. ['flask'] # Per-detector configuration. Every detector in the catalog can be disabled # (`enabled: no`), have its severity overridden, or accept detector-specific # properties (see the per-detector pages). detectors: unauthenticated_endpoint: enabled: yes severity: high properties: # Glob patterns added on top of the built-in public-path allowlist. publicPaths: - "/v2/public/**" - "/api/marketing/**" excessive_data_exposure_java: enabled: yes properties: # Minimum confidence tier that fires. Default 'high'. Set to 'medium' # to include 'sensitive AND referenced in request' findings. minConfidence: high rate_limit_absence: enabled: yes severity: low broken_object_level_authorization: enabled: yes properties: idParameterPatterns: - id - "*Id" - "*_id" - uuid # Sensitivity classification overrides. Used to disable false-positive tags # on a per-project basis (e.g., a newsletter app where `email` is intentionally # public). sensitivityClassifier: ignore: # Field-level overrides — exact match on FQN (DTO + field name) - com.acme.user.NewsletterSubscriber#email # Path patterns - "**/PublicProfile.*" # Correlation rules — compose individual flaws into composite findings. correlation: enabled: yes rules: [] # see correlation.rules below ``` ### Framework Autodiscovery Before each scan, the autodiscovery probe walks the project directory looking for known manifest files (`pom.xml`, `build.gradle`, `package.json`, `requirements.txt`, `pyproject.toml`, `*.csproj`, `composer.json`, `go.mod`) and maps declared dependencies to framework detector IDs with a confidence score in `[0.0, 1.0]`. * When **probes find evidence** above `confidence_threshold` (default `0.5`), the scanner loads **only** the matching source-code detectors. Descriptor detectors (e.g., OpenAPI) always load since they are cheap and self-gate on filename. * When **probes find no evidence**, all detectors load as a safe fallback — an empty probe result means "inconclusive", not "nothing is present". * When **`frameworks.enabled` is non-empty**, autodiscovery is skipped entirely (user selection wins). Detected frameworks are logged at INFO level and recorded on the report's statistics under `detectedFrameworks` (id, confidence, source manifest), so it is always visible in the scan output why a particular detector was or was not loaded. ### Recognised Framework IDs The `frameworks.enabled` / `frameworks.disabled` lists use these IDs: | Language | Framework IDs | | -------- | ---------------------------------------------------- | | Java | `spring-mvc`, `jax-rs` | | C# | `aspnet-core` | | Python | `fastapi`, `flask`, `django`, `connexion` | | JS / TS | `express`, `nestjs`, `koa`, `fastify`, `hono` | | Go | `gin`, `echo`, `chi`, `fiber`, `gorilla`, `net-http` | | PHP | `laravel`, `symfony`, `slim` | | Any | `openapi` (covers OpenAPI 3.x + Swagger 2.x) | ### Per-Detector Configuration Every detector accepts the common keys: * `enabled: yes | no` — turn the detector off entirely. * `severity: critical | high | medium | low | info` — override the default severity. Useful when calibrating the noise floor during adoption. * `properties:` — detector-specific knobs. The most common ones are listed below; see the [detector catalog](/xygeni-products/api-security/api-security-detectors) for the complete reference. Notable detector-specific properties: | Detector | Property | Effect | | ------------------------------------- | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | `unauthenticated_endpoint` | `publicPaths` | Glob patterns added on top of the built-in allowlist (`/health`, `/metrics`, `/actuator/**`, `/.well-known/**`, …) for legitimately public endpoints. | | `excessive_data_exposure_*` | `minConfidence` | Lowest confidence tier that fires. Default `high`; `medium` widens to include "sensitive AND referenced in request" findings. | | `pii_leak_in_response_*` | `minConfidence` | Same shape as above. | | `broken_object_level_authorization` | `idParameterPatterns` | List of parameter-name patterns that indicate an object id (`id`, `*Id`, `*_id`, `uuid`, …). | | `broken_function_level_authorization` | `adminPathPatterns` | URL prefixes that look administrative (`/admin/**`, `/management/**`, `/internal/**`, `/system/**`). | | `cors_misconfiguration` | `dangerousOrigins` | Origin values treated as wildcard (`*`, `null`). | | `jwt_misconfiguration` | `dangerousAlgorithms` | Algorithms treated as unsafe (`none`, `HS256` with weak secrets). | | `mass_assignment` | `protectedAttributes` | Field names whose presence in the request body raises a finding (the privilege / identity / financial vocabularies). | | `rate_limit_absence` | `recognisedLibraries` | List of rate-limit library names checked for in handler files and entry points (extends the built-in defaults). | | `ssrf` | `urlParameterPatterns` | Parameter-name patterns suggesting a URL input. | ### Sensitivity Classification The sensitivity classifier tags parameters and DTO fields based on names, types, and framework-specific markers, producing one of these tags: `PII`, `PCI`, `PHI`, `CREDENTIAL`, `CRYPTO_MATERIAL`. The tags drive several detectors (`excessive_data_exposure`, `pii_leak_in_response`, `sensitive_param_unauthenticated`) and surface on the inventory regardless of whether flaws are produced. When the classifier mis-tags a field — for example, a newsletter-subscription app where `email` is the *intentional* product surface — the tag can be suppressed per-project: ```yaml sensitivityClassifier: ignore: - com.acme.user.NewsletterSubscriber#email - "**/PublicProfile.*" # all fields of any PublicProfile class ``` Suppressing the tag is the recommended way to silence the resulting finding, since it also removes the false sensitivity signal from the inventory itself. Disabling the *detector* (via `detectors..enabled: no`) is heavier and should be reserved for cases where the detector is genuinely not applicable to the project. ### Correlation Rules A correlation rule composes two or more individual flaws on the same endpoint into a single composite finding with its own severity, kind, and remediation. The built-in rule set includes: * **`pii_leak_in_unauthenticated_endpoint`** — emitted at **CRITICAL** when an endpoint carries both `pii_leak_in_response` and `unauthenticated_endpoint` findings. The composite replaces the two individual findings on the listing while preserving traceability back to its components. Custom correlation rules can be added per project. A rule has the shape: ```yaml correlation: enabled: yes rules: - id: my_composite_rule whenAll: # all listed findings must be present on the endpoint - pii_leak_in_response - unauthenticated_endpoint emit: detector: pii_leak_in_unauthenticated_endpoint severity: critical suppressComponents: yes # remove the component flaws from the report ``` ### Example — Full Project Configuration A worked example that pins frameworks, tightens the sensitive-data detectors, suppresses a known-public field, and gates the build at HIGH: ```yaml autodiscovery: enabled: no frameworks: enabled: - spring-mvc - openapi disabled: [] detectors: excessive_data_exposure_java: enabled: yes properties: minConfidence: high pii_leak_in_response_java: enabled: yes severity: high jwt_misconfiguration: enabled: yes mass_assignment: enabled: yes properties: protectedAttributes: - admin - role - isAdmin - balance - tenantId # project-specific privileged field rate_limit_absence: enabled: no # gateway-level limits are in place sensitivityClassifier: ignore: - com.acme.user.NewsletterSubscriber#email ``` Run with: ```bash xygeni apisecurity --dir . -c xygeni.apisecurity.yml -f json -o report.json --fail-on high ``` # API Security Detectors The API Security scanner ships with twelve built-in detectors, each mapped to an entry of the **OWASP API Security Top 10 (2023)** as the primary taxonomy, and to one or more **CWE** identifiers as the secondary taxonomy. | Detector ID | Risk | OWASP API (2023) | CWE | Default severity | | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------- | ------------------------- | ------------------------------------------ | | `broken_object_level_authorization` | Object access by ID with no ownership check (IDOR). | API1:2023 | CWE-639, CWE-284 | high | | `unauthenticated_endpoint` | Endpoint reachable without authentication. | API2:2023 | CWE-306 | high | | `jwt_misconfiguration` | `alg: none`, signature verification disabled, hardcoded HMAC secret, expiration disabled. | API2:2023 | CWE-347, CWE-327, CWE-757 | high (critical tiers) | | `sensitive_param_unauthenticated` | PII / PCI / PHI / credential parameter on an unauthenticated endpoint. | API2:2023, API3:2023 | CWE-359, CWE-522 | high | | `excessive_data_exposure` (Java, Python, C#, JS / TS, Go, PHP) | Response shape contains sensitivity-tagged fields the client did not ask for. | API3:2023 | CWE-213, CWE-200 | high | | `mass_assignment` | Request body binds to privileged attributes (`admin`, `role`, `isAdmin`, …). | API3:2023 | CWE-915 | high (low for identity / financial fields) | | `pii_leak_in_response` (Java, Python, C#, JS / TS, Go, PHP) | Response carries PII / PCI / PHI fields. Composite CRITICAL when combined with unauthenticated endpoint. | API3:2023, API10:2023 | CWE-359 | high | | `rate_limit_absence` | Auth-required endpoint with no recognised rate-limiting library or middleware. | API4:2023 | CWE-770 | low | | `broken_function_level_authorization` | Admin-shaped or destructive-verb endpoint with no role check (BFLA). | API5:2023 | CWE-285, CWE-269 | high | | `ssrf` | URL-shaped input parameter; severity lifts to HIGH when the handler also performs an outgoing HTTP fetch. | API7:2023 | CWE-918 | low (high tier) | | `cors_misconfiguration` | Permissive CORS (wildcard origin, especially with credentials). | API8:2023 | CWE-942, CWE-346 | low (high tier) | | `zombie_endpoint` / `orphan_spec` | Drift between source code and OpenAPI / Swagger descriptors (shadow API or orphan operation). | API9:2023 | CWE-1059 | high | The full per-detector documentation — with description, rationale, vulnerable / fixed code examples per language, framework-specific remediation, and the complete reference list — is published at [detectors.xygeni.io](https://detectors.xygeni.io/xydocs/apisec/detectors/index.html). ### Per-Language Coverage Two detectors — `excessive_data_exposure` and `pii_leak_in_response` — ship with **per-language** implementations so the rationale and remediation pages can speak the idiom of the target stack. Coverage: | Language | Frameworks recognised | | -------- | ---------------------------------------------- | | Java | Spring MVC / Spring Boot, JAX-RS | | C# | ASP.NET Core (Controllers + Minimal APIs) | | Python | FastAPI, Flask, Django / Django REST Framework | | JS / TS | Express, NestJS, Koa, Fastify, Hono | | Go | net/http, Gin, Echo, Chi, Fiber, gorilla/mux | | PHP | Laravel, Symfony, Slim | All other detectors operate at the **model level** (HTTP method + path shape + authentication evidence) so they apply uniformly across every supported framework. Several model-level detectors are augmented with per-language source walking that confirms or refines the verdict — for example, the BOLA / BFLA detectors walk the handler body for explicit ownership / role checks, and SSRF walks for outgoing-HTTP-fetch calls. ### Sensitivity Classification Both `excessive_data_exposure` and `pii_leak_in_response` rely on the **sensitivity classifier**, which tags parameters and DTO fields by their *kind* — PII, PCI, PHI, credential, crypto material — based on field names, schema annotations, and (where available) framework-specific markers. The classifier is configured globally on the scan, not per-detector; see the [scanner configuration page](/xygeni-products/api-security/api-security-scanner/api-security-scanner-configuration) for details on overriding tags for false-positive fields. ### Compliance Tags Where applicable, findings carry tags that map the underlying risk to the most relevant compliance controls: * **GDPR** — Article 32 (security of processing). * **PCI-DSS v4.0** — Requirements 3.4 (render PAN unreadable), 6.4.3 (protection against payment-page tampering), 7.1 / 7.2 (least privilege), 8 (identify and authenticate access). * **NIST SP 800-53** — AC-3 (access enforcement), AC-6 (least privilege), IA-2 (identification and authentication), IA-5 (authenticator management). Tags appear on the finding's metadata in the UI and in the JSON / SARIF report output, so API Security findings flow into existing compliance dashboards alongside SAST, SCA, and Secrets findings. # Open Source (SCA)
## **OSS Overview** **Open Source Security** offers real-time monitoring of your **dependencies** to detect and mitigate threats before they impact your software. Recent reports reveal that nearly three-quarters of codebases now contain high-risk open-source components. Vulnerabilities have soared from 48% to 74% in just one year. Even more concerning, 91% of these components are at least 10 versions outdated, significantly heightening security risks. The rise of malicious open-source packages has been meteoric, with growth rates exceeding 300% year-over-year, resulting in over 245K malicious packages detected in 2023. It’s time to take action against these threats. Given these challenges, Xygeni’s **Open Source Security** solution is essential. It scans and blocks harmful packages upon publication, dramatically reducing the risk of malware and vulnerabilities infiltrating your systems. This comprehensive monitoring spans multiple public registries, ensuring all dependencies are scrutinized for safety and integrity. Xygeni also enhances your team’s ability to maintain secure and reliable software projects by contextually prioritizing critical issues and facilitating streamlined remediation processes Xygeni **Open Source Security** is designed to provide complete protection against vulnerabilities and malicious code, ensuring your applications remain secure and resilient. With a robust suite of capabilities, Xygeni offers unparalleled visibility and control over your open-source components, helping you to manage risks effectively. 1. **Comprehensive Component Identification** and cataloging of each open-source component within your software projects. 2. **Continuous Scanning and Vulnerability Management** to ensure that every component, whether direct, indirect, or undeclared, is assessed for security vulnerabilities, maintenance issues, and licensing compliance. 3. **Context-aware prioritization** based on their severity, exploitability, and potential business impact. This context-aware approach ensures that your security and development teams focus on the most critical issues. 4. **Expanded Security Beyond CVEs** by incorporating additional risk factors beyond just CVSS scores. Xygeni prevents the integration of packages that may be CVE-free but still risky. 5. **License Risk Management** with instant visibility into potential open-source license issues, helping your team avoid legal complications and ensure regulatory compliance. 6. The one-click **generation of SBOM and VDR** in SPDX or CycloneDX formats ensures that your software components are transparent and compliant with regulatory requirements. ### Comprehensive Component Identification At the heart of Xygeni’s Open Source Security is our advanced capability to precisely identify and catalog every open-source component in your software projects. This thorough approach provides complete visibility into your software’s architecture, enabling a detailed assessment of your project’s security posture and compliance status. Your team can make better decisions by understanding exactly what makes up your software. ### Strategic Approach for Risk Prioritization with ASPM Xygeni’s software security platform excels in identifying and prioritizing vulnerabilities that pose the most significant risks to your software projects. By systematically analyzing the severity and potential impact of each identified vulnerability, Xygeni enables organizations to focus their resources on mitigating the most critical issues first. Our prioritization is driven by a combination of factors such as vulnerability severity, exploitability, exposure, the potential impact on business operations, and any other custom property defined by customers. Some key features of Xygeni’s prioritization process are: 1. Continuous Scanning: Xygeni assesses each vulnerability based on its severity and the affected component’s context. This approach ensures that vulnerabilities are not just evaluated in isolation but are considered within the broader scope of the system’s architecture. 2. Context-Aware Prioritization: Understanding that not all vulnerabilities are created equal, Xygeni prioritizes issues based on their operational and strategic impact. This means vulnerabilities that could lead to significant security breaches are flagged and addressed first. 3. Customizable Risk Metrics: Xygeni allows organizations to customize how risks are scored and prioritized, aligning the prioritization process with their specific security policies and compliance requirements. This customization capability ensures that the security efforts perfectly sync with organizational priorities and risk ### Malware Early Detection, Blocking, and Notification As soon as new packages are published, Xygeni conducts a real-time scan to detect and block malware based on code behavior analysis, alleviating the need for extensive and urgent post-build remediation. Our systematic process sounds like this: #### Continuous Scanning: * Public Registries Monitored: The service continuously scans multiple public registries like NPM, Maven, PyPI, etc. * Immediate Notification to Affected Users: As soon as a potential threat is detected, the system immediately notifies the affected users, enabling rapid response to mitigate risks. Notifications can be raised through standard Xygeni mechanisms such as email, messaging platforms, and webhooks. #### Quarantine: * Automatic Blocking of Zero-Day Malware: Upon detection, suspicious packages are automatically quarantined. The customer can use this information to implement guardrails in their CI/CD to prevent the packages from entering the development environment or the broader software supply chain. #### Review and Confirmation: * Code Review by Security Researchers: A security research team reviews the quarantined package to verify the threat. * Confirmation by Public Registry: If confirmed by our internal team, we communicate it to the public registry, which should confirm the finding and validate the threat level and the nature of the malware or vulnerability. #### Disposal and Public Disclosure: * Disposal: Once a threat is confirmed, the appropriate measures are taken to dispose of the threat safely, ensuring it does not re-enter the ecosystem. * Public Disclosure: The usual details about the malware and its disposal are publicly disclosed through the product, Xygeni blog, or the package registry to inform the wider community and prevent ### Simplify Open Source Licensing Xygeni makes navigating the complexities of open-source licensing easy. Our scanning capabilities assess each component’s license, helping your team avoid legal issues and ensure compliance with both organizational policies and external regulations. With Xygeni, you can confidently use open-source software, knowing that all licensing requirements are met. ### Keep Your Software Updated and Secure Xygeni actively monitors and identifies outdated or obsolete components in your software projects. By ensuring your projects always utilize the latest and most secure versions, Xygeni not only reduces potential security risks but also boosts software performance and compatibility. ### Advanced Detection of Suspect Dependencies Xygeni’s Suspect Dependencies Scanner is crucial for identifying and managing suspect dependencies that could be targets for supply-chain attacks. By analyzing the dependency graph, our product can detect issues such as typo-squatting, dependency confusion, and suspicious installation scripts that may indicate a compromise. If a component is recognized as suspicious, Xygeni provides detailed mitigation and remediation strategies to help safely remove or isolate the threat. This includes recommendations for version pinning, using whitelisted components, and blocking suspicious installation scripts. ### Optimized and Accelerated Remediation Workflows Prioritizing vulnerabilities that pose the highest risk ensures that remediation efforts are concentrated where they are most needed, optimizing resource allocation and reducing the time and effort spent on lower-risk vulnerabilities. Moreover, Xygeni simplifies the remediation of open-source vulnerabilities by integrating directly into developers’ existing workflows and issue-tracking systems. This seamless integration provides all the necessary context for each vulnerability right within the tools developers already use, facilitating efficient and effective remediation. ### Enhance Transparency and Compliance with SBOM and VDR Generation Xygeni Open Source Security empowers organizations to maintain complete transparency over their software components with our SBOM generation feature. SBOM facilitates compliance with regulatory requirements and enhances supply chain security by providing a detailed inventory of all software dependencies. Additionally, our Vulnerability Disclosure Report (VDR) generation capability ensures that all stakeholders know potential vulnerabilities, enabling proactive risk management and reinforcing trust throughout the development lifecycle. ### Effective Vulnerability Management Xygeni enhances your software’s security by continuously scanning and analyzing open-source components for vulnerabilities. By connecting directly with the National Vulnerability Database (NVD), other vertical vulnerabilities databases and security advisories, and using Common Vulnerabilities and Exposures (CVE) information, Xygeni ensures fast and accurate detection of potential security issues to protect your software applications promptly and efficiently. ### Overview of Supported Package Managers Xygeni provides a comprehensive range of detectors tailored to the unique characteristics of various software package managers, ensuring comprehensive coverage and precise detection of dependencies.
{% hint style="info" %} Please visit [Supported Package Managers for Dependency Resolution Analyzers](/xygeni-products/open-source-security-oss/supported-package-managers-for-dependency-resolution) for a full description of supported package managers. {% endhint %} ### Types of Suspect Dependency Detector **Open Source Security** provides a comprehensive range of detectors tailored to the unique characteristics of various software ecosystems, ensuring comprehensive coverage and precise detection of suspect dependencies, among others : maven, PyPi, NPM, nugget, etc. See [Open Source Analyzers](/xygeni-products/open-source-security-oss/dependency-scanner/dependency-analyzers) for a complete list. * **Anomalous Dependencies**: Identifies unusual or unexpected dependencies within the context of the project, which may signal a security concern. * **Dependency Confusion**: This feature detects cases where internal package names may be confused with similarly named packages from public repositories, potentially leading to security breaches. * **Known Vulnerabilities**: Flags dependencies that contain recognized security vulnerabilities. * **Malware**: Looks for dependencies known to contain malware, providing critical security alerts to prevent potential harm. * **Suspicious Scripts**: Monitors for scripts within dependencies that might perform unauthorized or harmful actions. * **Typosquatting**: Aims to catch potentially malicious typosquatting attempts where package names are slightly altered to trick users into installing them. * **Unscoped Internal Components**: This is a special detector for NPM that identifies unscoped internal components and thus might be at risk of being publicly exposed or confused with external packages To accomplish these functionalities, Xygeni provides a **Scanner** (to search for dependencies and security issues) and a **Web UI** to view the results. {% hint style="info" %} See [Scan with Xygeni CLI](/xygeni-scanner-cli/xygeni-cli-overview) and, more specifically, [Dependency Scanner](/xygeni-products/open-source-security-oss/suspect-dependencies-scanner) and [Suspect Dependencies Scanner](/xygeni-products/open-source-security-oss/suspect-dependencies-scanner) for instructions on how to execute an Open Source scan. {% endhint %} ### SBOM and VDR capabilities In response to growing cybersecurity threats, regulatory bodies worldwide are increasingly mandating using Software Bill of Materials (SBOMs). SBOMs provide essential visibility into the components of software applications, facilitating better vulnerability management and compliance with security standards. ### Analyzers Dependencies for each ecosystem are processed by a specific analyzer. The analyzer processes dependency descriptors to extract direct and indirect dependencies, resolve their versions, and gather context information like licensing, provenance and other metadata. {% hint style="info" %} See [Scan with Xygeni CLI](/xygeni-scanner-cli/xygeni-cli-overview) and, more specifically, [Dependency Scanner](/xygeni-products/open-source-security-oss/dependency-scanner) and [Suspect Dependencies Scanner](/xygeni-products/open-source-security-oss/suspect-dependencies-scanner) for instructions on how to execute an Open Source scan. See [Malware Detection](/xygeni-products/code-security-cs/malware-scanner) and [Malware Early Warning Service](/xygeni-products/open-source-security-oss/malware-early-warning-mew) {% endhint %} # Open Source (SCA) User Interface Guide The **Open Source (SCA)** User Interface can be accessed by selecting the **SCA** option within the [**Risks**](/xygeni-products/application-security-posture-management-aspm/all-risks) **tab**. The Open Source section is divided into the following * [SCA Risks](/xygeni-products/open-source-security-oss/risks-sca): A summary of all SCA security issues. * [Components](/xygeni-products/application-security-posture-management-aspm/inventory/components): A comprehensive view of all your dependencies
# Supported Package Managers for dependency resolution
Package ManagerLanguageSupported Dependency Files
Maven Javapom.xml
Gradle Java, Kotlinbuild.gradle, build.gradle.kts, gradle.lockfile, gradle.properties
NPM JavaScriptpackage.json, package-lock.json
Yarn JavaScriptyarn.lock
PNPM JavaScriptpnpm-lock.yaml
Bower JavaScriptbower.json
Nuget .NET, C#project.assets.json, packages.lock.json
Pip Pythonrequirements.txt, setup.py, setup.cfg
Uv Pythonuv.lock
Poetry Pythonpoetry.lock
Go Modules Golang (Go)go.mod, go.sum
Composer PHPcomposer.json, composer.lock
RubyGems RubyGemfile, Gemfile.lock
Swift Package ManagerSwiftPackage.resolved
CocoaPodsSwiftPodfile.lock
CarthageSwiftCartfile.resolved
PubDartpubspec.yaml, pubspec.lock
--- [Next Page](/llms-full.txt/1)