Only this pageAll pages
Powered by GitBook
Couldn't generate the PDF for 194 pages, generation stopped at 100.
Extend with 50 more pages.
1 of 100

Xygeni User Guides

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Xygeni Products

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Getting Started

To explore Xygeni's features effortlessly as a new user, follow these simple steps

Please ensure that you have an active Xygeni account before proceeding.

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.

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.

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).

Please go to and follow the suggested steps.

Please go to and follow the suggested steps.

Visit here to .

Quick Start with your code repository
Quick Start with Xygeni CLI
Quick start with a preloaded project

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

Introduction to Xygeni

Xygeni Configuration and Administration

Please, follow our for an easy onboarding process to the Xygeni platform.

Connect your SCM to Xygeni and start scanning

Scan with Xygeni CLI locally in command line

Quick view of the available Xygeni products

Understand the architecture behind Xygeni and how it works

Learn about how to use the Xygeni Web User Interface

Learn about Xygeni CLI and the various scans types

Integrate Xygeni into your own CI/CD pipelines

Secure your build process by setting Security Gates

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

Integrate Xygeni within your own SDLC processes and tools

Manage and configure your Xygeni platform

Leverage Xygeni functionality with the Xygeni REST API

Getting Started Guide
Quick start with your code repo
Quick start with Xygeni CLI
Xygeni Products Overview
How Xygeni works
Xygeni Web UI
Xygeni Scanners
Integrating Xygeni into your Workflow
Security Gates with Xygeni
Generate a SBOM
Supported Integrations
Platform Administration
Xygeni REST API

Subscribe to Xygeni

Subscribe to Xygeni

After you finish your trial period you can upgrade your plan to continue monitoring and improving the security of your applications and organization.

To manage your plan and review scan utilization, please navigate to Settings >> Subscription

You can check the complete information of Subscription Section in Settings block in the following page of the documentation: Subscription

Access to Subscribe section

Open the Settings menu and select Subscription. The subsequent screen with appear:

Subscribe

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.

Click the Subscribe button to commence the selection of plans and determine the quantity of daily scans. Visit the for detailed information on plans and pricing.

pricing page

Create a Free Trial Account

You must have an active Xygeni Account to use Xygeni's features.

Create a Free Trial account

You can either create a Free Trial account or sign up for a Xygeni pricing plan;

A comprehensive set of features is available for evaluation over a 14-day trial. The registration process doesn't require payment information and no automatic subscription starts after the trial. Should the user choose not to subscribe, the account will be deactivated.

  1. Choose your preferred signup method.

Visit for more details.

Go to

Follow the prompts to create a new account. You should now have a free Xygeni account and can log in at any time at

Xygeni Pricing Plans
https://xygeni.io/xygeni-free-trial/
https://in.xygeni.io/auth/login

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 CLI

A Scan is the action performed by the Xygeni Scanner to find security issues in your project.

You can follow the steps below for a quick start guide to using the Xygeni CLI

1. Install the Scanner CLI

An installation script is provided for automated installation.

For manual installation, the scanner can be downloaded from: https://get.xygeni.io/latest/scanner/xygeni-release.zip or using the https://apidev.xygeni.io/scan/releases GET API endpoint, unzipped, and configured by setting your credentials and proxy details (if any is used) in the configuration file conf/xygeni.yml

The recommended, automated way to install the scanner is to use the installation script.

The Xygeni installation scripts provided by Xygeni as a way to speed up your xygeni experience by setting your scanning environment as fast as possible.

Download the script

Run one of the following commands depending on your preferences:

  curl -sLO https://get.xygeni.io/latest/scanner/install.sh
 iwr https://get.xygeni.io/latest/scanner/install.ps1 -useb -OutFile install.ps1

2. Fetch your Xygeni account credentials or API token

Active Xygeni account credentials are mandatory to run the script, so make sure you’ve signed up first!

An Access Token, also referred to as an API token or API key, is used by applications such as the Xygeni Scanner or other integrations to access the Xygeni platform's API.

Describe what the token will be used for, choose the validity period, and select the permissions granted to the token. Click on the Generate button:

Each permission grants the key access to specific API endpoints. Typically, the scanner requires permissions to upload scan results.

Finally, the token is generated:

3. Run the installation script

The variable XYGENI_TOKEN refers to an environment variable that stores the Xygeni API token. This token will be used to authenticate with the service.

./install.sh -o -v -t $XYGENI_TOKEN
PS .\install.ps1 -o -verbose -t $Env:XYGENI_TOKEN

For a list of available options, execute ./install.sh --help on Unix-based systems or PS .\install.ps1 --help on Windows.

4. 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.

$ cd /my/project
$ xygeni scan 

You can also use these commands below for other cases:

# Assuming that $XYGENI_HOME in path or xygeni shortcut set
# Scan a directory
$ xygeni scan -n <your_project_name> --dir <path_to_analyze>

# Scan a repository
$ xygeni scan --repository <repo_url>

# Scan a container image
$ xygeni scan --repository <image>

# You may add --no-upload to the scan command if you want to view
# the results before uploading to Xygeni platform. 

Usually, the preferred option is to pass the token in an environment variable (like GITHUB_TOKEN or GITLAB_TOKEN).

5. View scan results

To create an access token in the Dashboard, go to the Settings >>Profile>> Access tokens, then click on the Generate new token button. Go to for further details.

IMPORTANT: In case you want the scanner performs checks against your repository and organization (See ), ensure that you provide your SCM and/or CI/ CD systems tokens to the scanner.

See to know more about this topic.

See for the full scanner command-line reference.

After the scan is done, log into the and navigate to the Governance tab to access the Security Posture Summary screen.

Go to for a guide to browse the dashboard.

SCM and CI/ CD tokens
Xygeni Scanner Reference
Dashboard
Xygeni Web UI
Install the Scanner CLI
Fetch your Xygeni credentials
Run the installation script
Run your first scan
View the scan results

Detected Issues

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.

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.

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...

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.

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.

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.

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.

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.

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.

Quick start with your code repository

Creating an Integration with your SCM

First, go to Home >> Managed Scans

Click on Add Repository button to create an integration with your SCM. A dialog will open to select your SCM:

For this example, we will use GitHub. So clicking on GitHub will install Xygeni GitHub Application.

As you can see below, the installation procedure will let you specify the scope of the installation (user- or organization-level)

The installation will ask you to grant permission to Xygeni GitHub Application to all or only selected repositories.

After clicking on Install & Authorize button, the Managed Scans page will display the new integration.

It also display a table listing the granted repositories (this list depends on previous step).

Clicking on the Scan Now button of any repo will execute a scan on that repo.

If you go now to GitHub, you will see a workflow running the scan:

That's all!!

Log in 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.

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.

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:

Introduction to Xygeni

Key Concepts

The following sections describe the key elements within the Xygeni Platform.

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.

The runs on your premises to analyze DevOps tools and software projects, including source code and configurations.

Publicly known vulnerabilities are published as CVEs. Xygeni is able to scan your dependencies to find CVEs from public sources (, and among others )

See , and for more details.

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 or Typosquatting.

See and for more details.

See and for further information.

See and for further information.

See and for further information.

See and for further information.

See , and for full documentation on the supported standards and their checkpoints.

See and for further information.

See and for further information.

Xygeni provides a quick way to scan your repositories directly from the UI. With this functionality () you will be able to scan your repos and Xygeni will manage everything behind the scenes.

After the scan is completed, you can find the results in the . The name of your project will be the same as your repository name.

You can also configure to be notified when the scan is finished. See .

Please, visit for other available options such as scheduling a scan or trigger the scan upon Pull Request creation.

Go to our Login page:

You can login either by using your Xygeni identifier or using your preferred Authentication system (go to to learn how to integrate authentication through SAML )

If you use Xygeni authentication, you will need to provide a password. In case you are new to Xygeni, please go to .

For more information, read .

Xygeni Scanner
NIST's NVD
GitHub Advisory Database
OSV
Open Source Security (OSS)
Dependency Scanner
Dependency Analyzers
Dependency Confusion
Open Source Security (OSS)
Suspect Dependencies Scanner
Software Supply-Chain Security (SSCS)
CI/CD Scanner
Code Security (CS)
Malware Scanner
Secrets Security
Secrets Scanner
IaC Security
IaC Scanner
Software Supply-Chain Security (SSCS)
Compliance Scanner
Software Supply Chain Standards
Anomaly Detection
Code Tampering Scanner
Anomaly Detection
Xygeni Sensors
Managed Scans
Dashboard
Notifications
Managed Scans
https://in.xygeni.io/auth/login
Xygeni Single-Sign-On (SSO) Authentication
Quick start with your code repository
Quick start with Xygeni CLI
Quick start with preloaded project
First Login to Xygeni
Xygeni Products
How Xygeni works
Xygeni Web UI
Scanners
Scanner CLI Overview
Scanner Docker Image
Integrate Xygeni into your workflows
Security Gates (GuardRails)
SBOM Generation
Reports
Supported Integrations
Customizing Xygeni
Projects in Xygeni
Detected Issues
Remediation Actions
Policies
Risk Level
SDLC Inventory
Standards Compliance
GuardRails
Projects in Xygeni

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.

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.

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.

Please, go to the below sections for further information on automatic remediation:

Handling Actions in Xygeni Dashboard

  • 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.

  • 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.

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.

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.

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.

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.

Please note, the 'Actions' tab will only be active when at least a single issue has been selected.

Read more about .

Read more about .

The offers contextual remediation actions for each security issue or unusual activity alert. The common actions are:

See in Inventory: Shows the asset where the issue was located in the , .

The remediation actions can be invoked from the Remediation Actions popup in the .

SDLC Inventory
Policies in Xygeni
Open Source auto remediation
Secrets auto remediation
Dashboard
SDLC Inventory
Dashboard

Standards Compliance

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

Xygeni Web UI Overview

The Dashboard pages are composed of three elements:

  1. The actual page content.

Navigation Bar

The Navigation Bar lets you access all the Xygeni functionalities:

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.

GuardRails

For pipelines or security policies that need specific rules or exit codes, complex conditions can be set using guardrail expressions.

Projects Screen

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.

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.

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.

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 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.

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.

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 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 row or choosing the 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.

Important: If the project contains malware a red notice will be shown on top. Detailed sections containing malware are available in the Findings section.

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.

Malware detection requires ´Premium´ or ´Enterprise´ plan to enable malware detection capabilities.

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

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.

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.

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:

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 platform is represented by the chart below:

Scanner

Dashboard

Trends exploration, reporting, and platform administration, among other facilities are also displayed.

Rest API

Integrations

Xygeni provides integrations for running scans or uploading security issues, performing administrative operations, or exporting findings to communication and reporting tools.

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.

Xygeni ensures your software aligns with various 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.

See for more information.

The .

The .

, , and Scan History,

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.

See for further details.

The Projects Screen is the first page you see when you login to

Finally, there is a quick access to the 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.

In the , the Risk Level is displayed alongside its variation in relation to the current baseline of projects.

See for further information and details.

Clicking on the name of the project, goes to the section to review the projects associated risk.

View All Issues: Goes to the section.

In the , the Risk Level is displayed alongside its variation in relation to the current baseline of projects.

The , runs in your internal network and asses your infrastructure for different types of vulnerabilities (Visit 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 ) or keep the results locally for further processing.

Xygeni provides a command-line interface (CLI) for running the . The scanner can either run analysis commands separately, like detecting hardcoded secrets or misconfigurations, or run all the analyses at once.

The is java based and can be triggered directly from the , from any (Unix shell script, Windows batch, PowerShell script, etc.), from (pre-commit, pre-receive) or embedded into .

The scanner can be scan a , a , a or group of repositories and even a whole .

The Xygeni Scanner can be automatically installed into you repositories or manually embedded into your pipelines. Please visit and for further information.

Scanner findings can be inspected in the , downloaded via Xygeni , in several formats (csv, json, etc...) and also create (Jira, GitHub) or opening (Slack) to notify your team about an issue.

See for further detail

The 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.

See for further detail

The 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.

See for further detail

See and for further detail

See and for further details.

supported standards
ASPM (Application Security Posture Management)
Xygeni Products
Malicious Packages DB
SSCS Compliance
Manage Scans
Platform Administration and Settings
Guardrails Gates
GuardRails Specification
Navigation Bar
Projects Selector
https://in.xygeni.io/auth/login
Managed Scans
All Risks
All Risks
All Risk
Xygeni Scanner
here
Xygeni Dashboard
scanner
scanner
command line
batch program
git hooks
CI/CD pipelines
file directory
container image
repository
SCM organization
Quick start with your code repository
Quick start with Xygeni CLI
Dashboard
REST-API
exported
tickets
messages
Xygeni Scanner
Dashboard
Dashboard
REST API
REST API
Integrating Xygeni into your Workflow
Integrations
Xygeni Sensors
Anomalus Activity
Dashboard
Dashboard

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.

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.

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.

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.

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

Malicious code can be injected into your application code by attackers infiltrating your systems or even by internal attackers.

Minimize Open-Source Risk and Keep your Application Safe From Malicious Packages

Optimize Your CI/CD Ecosystem for Robust Protection

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

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

Scale Cloud Security Identifying All Cloud Misconfigurations

Prevent Malicious Activity Detecting Behavior-Based Risks

Reachability should be considered as a main criteria for vulnerability prioritization (see )

Application Security Posture Management (ASPM)
Code Security (CS)
Open Source Security (OSS)
Software Supply-Chain Security (SSCS)
Build Security
Secrets Security
IaC Security
Anomaly Detection

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.

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.

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:

# 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

Prioritization Funnels

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.

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).

Criteria
Description
Calculation
Nature
Scope

Reachability

Auto

Technical

Issue

Exploitability

Auto

Technical

Issue

Fixable

Auto

Technical

Issue

In application code

Is this vulnerability is app code (i.e. not in tests code)

Auto

Technical

Issue

Deployed

Is this application being deployed? Xygeni can detect if the application is being deployed to some resource, but you can also manually assign the correct value

Both

Technical

Project

Active Development

Is 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 value

Auto

Technical

Project

Internet Exposed

Is this application exposed to the Internet?

Both

Technical

Project

Legacy

Is this a legacy (i.e. out of active maintenance) application?

Manual

Technical

Project

Product Unit

To which Product Unit this application belongs?

Manual

Business

Project

Business Value

What is the Business value of this application?

Manual

Business

Project

Provider

Who is the provider of this application?

Manual

Business

Project

Architecture

Which is the technical architecture of this application?

Manual

Business

Project

Business Area

To which Business Area (or dept) does the application belong to?

Manual

Business

Project

Any custom criteria

Manual

Business

Project

We are continuously adding new criteria so you will likely find more criteria than explained at the time of writing this document.

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.

Criteria
Open Source
Supply Chain
Secrets
IaC

Fixable

A 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 True

Always True

Always True

In application code

The 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" directory

The issue is located into a file with a path that does not contain any "test" directory

The issue is located into a file with a path that does not contain any "test" directory

Reachability

The vulnerability is reachable because the application code execution reaches the vulnerable code in the component

It 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

Exploitable

This 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 Development

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.

The project has commits in the last 90 days.

Deployed

A component's vulnerability is considered as Deployed if Xygeni detects a pipeline or workflow that deploys (checkout) the project, image or package.

Always True

A 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 Exposed

Any 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.

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.

Integrating Xygeni into your Workflow

Integration Scenarios

Xygeni provides two main facilities for monitoring your build & deployment systems: a Scanner that runs on demand or when a certain event occurs, and connects to the target system for analysis. As well as a Sensor that is installed in the target system and notifies the Xygeni Platform when events of interest occur.

The following are the most common scenarios:

Using the Scanner Command Line

You may run a scan from the command line to analyze any local software project, a software repository, or a container image. The scanner discovers the assets and performs static analysis on the source code, package metadata and configurations.

The scanner runs scan steps aiming at each potential security issue class, and generates reports that can be uploaded to the platform.

To quickly access the Xygeni scanner after installation, execute the following command in the terminal:

# Scan a directory with software
xygeni scan --dir PATH/TO/PROJECT

# Scan a software repository
xygeni scan --repository URL

# Scan a container image
xygeni scan --image IMAGE

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...

Integrate the Scanner into a CI/CD Pipeline

Integrating the scanner within a CI/CD pipeline offers a proactive approach, enabling the early detection of potential issues during the build and development process. This ensures problems are addressed promptly.

Under Continuous Integration / Continuous Delivery, an event on the source code repository often triggers a pipeline or workflow that builds, tests and performs different checks on the sources and the artifacts built. A Xygeni scan is an essential check, ensuring continuous monitoring of security issues that may compromise the software supply chain.

For streamlined integration, Xygeni provides facilities for integration into build pipelines for the primary CI/CD systems.

Running the Scanner as a Gate in a Git Hook

The Xygeni scanner could be run at client-side, before a commit is applied, by adding a pre-commit git hook.

If you have control over git hooks at your git server, you may add a pre-receive hook at server side, so a push may be rejected if the scanner finds critical security issues.

Two common use cases for such hooks are: avoiding secret leaks committed to sources and critical file modifications not following a required change protocol.

Using Sensors for Activity Monitoring

Unusual activity may indicate either a running attack or a sloppy change in the security configuration that opens the door to bad actors. To capture the activity as it happens in the software build & deploy systems, Xygeni provides a collection of plugins ("Sensors") that, once installed in the target systems, notifies to the platform the events of interest for correlation and identification of anomalies.

Live notifications for high severity alerts are provided to the user, allowing them to take immediate action to mitigate the risk and prevent further damage.

Uploading Findings from External Security Tools

Xygeni prioritization and response can also be used with security findings reported by other (open-source and commercial) third-party security tools.

The scanner provides a report-upload command for uploading the structured reports generated by third-party security tools, in areas like Static Application Security Testing (SAST), Software Composition Analysis (SCA), or Secret Leaks / IaC Flaws Detection.

In your CI/CD pipelines you may have a step where another SAST tool is launched to uncover vulnerabilities in your source code or configurations. The output of the tool could be ingested by Xygeni to normalize the findings, and then use the findings for prioritization and remediation.

The workflow accommodates findings from Xygeni scans and your preferred third-party tool, as long as its output format is supported.

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.

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.

Custom Funnels

You can create your own Custom Prioritization Funnels.

Then, you can either create a New Funnel, Clone the selected funnel or Delete the selected funnel.

Out-of-the-box funnels cannot be either modified or deleted.

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 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

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.

Is this vulnerability reachable? (see for further details)

Is this vulnerability exploitable ? (see for further details

Is this vulnerability fixable? (see for further details)

Any custom-defined property defined for a project (see )

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 .

See for further info.

The exit code from the scanner can be used to stop the build if the issues found are deemed critical enough, acting as a "".

See the for further details on how to install and run the scans.

See the section for full details.

Xygeni can automatically add a pipeline to run the scanner. Please visit for further information.

For full details, read .

To know how the sensors work and how to install them in the target systems, read .

Visit 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 .

Exploitability should be considered as a main criteria for vulnerability prioritization (see )

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 for further information)

Manual Fix Available : There exists a newer version of the dependency that fixes the vulnerability. In this case 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.

Click on the button next to the funnel selector and the Prioritization Funnel Configuration panel will open:

Out-of-the-box funnels are preceded with ** to differentiate to and cannot be modified.

Project Management
security guardrail
Xygeni Scanner
Integrate into CI/CD Systems
Managed Scans
Git Hooks with Xygeni
Integrate Xygeni Sensors
external scanners supported
Using the scanner command line
Integrate the scanner into a CI/CD pipeline
Running scanner as a gate in a git hook
Using Sensors for activity monitoring
Uploading findings from external security tools
Reachability
Exploitability
Fixable
Prioritization Funnels
Xygeni's Automatic Fix
Xygeni's Automatic Fix
Custom criteria
Custom Funnels

Trends

Trends Page

Trends page shows governance information about issues discovered, remediation, trends, etc.

It can be accessed through Governance >> Trends at the Navigation Bar.

Overall Metrics

Top panel shows different metrics by "period" (last month, last 3 months, last 6 months and last year)

  • Total Issues is the number of Total Open issues at present date.

  • New Issues is the number of New Issues (i.e. opened) at present date.

  • Exposure Window is the elapsed time between the creation of an issue and present date (this metric only applies to open issues). Mean Exposure Window is the arithmetic mean of all the open issues' exposure window.

  • Time to Resolve is the elapsed time between the creation and closing of an issue (this metric only applies to closed issues). Mean Time to Resolve is the arithmetic mean of all closed issues' time to resolve.

Every displayed metric shows comparison (in total and %) relative to previous period.

Cumulative Pending Issues

Cumulative Pending Issues chart shows information about evolution of issues.

Being X-axis the timeline of the select period, left Y-axis indicates the Number of New / Resolved issues and right Y-axis indicates the Number of Open issues.

You can hoover the mouse over a the chart to get detailed information of total, new and resolved issues at a certain time.

Impact of Anomalous Activities

Impact of Anomalous Activities chart displays information about frequency of anomalous activities (Critical File Changes and Suspicious Activity)

Issues Exposure Window

Issues Exposure Window chart displays information about the number of issues at a certain date falling into three Exposure Window thresholds (<15d, 15-30d and >30d)

Issues Time to Resolve

Issues Time to Resolve chart displays information about the number of issues at a certain date falling into three Time-To-Resolve thresholds (<15d, 15-30d and >30d)

Metrics by Group

Metrics By Group table displays metrics for a group of projects. Grouping is based on Projects' Properties. You can select the grouping property and it will display all the property's values with metrics of all the corresponding projects.

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.

Project Baseline

Project's Baseline

Every project in Xygeni has a Baseline.

A Baseline is a definitive analysis of the project used as a reference point for comparison with subsequent analyses, primarily to track the progression of issues within the project.

By default, a project's baseline is established by the initial scan. However, you have the option to designate a specific scan as the new baseline.

See , and for further information.

See for a description of every metric.

Visit for further information.

Go to for further information on how to mark a scan as the project baseline.

Anomaly Detection
Code Tampering Scanner
Xygeni Sensors
Xygeni GuardRails
Overall metrics

Generate a SBOM

Xygeni allows to generate a SBOM for a certain project.

Two SBOM formats are currently supported:

You have two options to generate an SBOM:

Generate a SBOM from the Web User Interface

Once you have selected a project, the Dashboard 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.

CycloneDX (JSON schema) .See for full details.

SPDX, in JSON serialization format, standard ISO/IEC 5962:2021. See for full details.

Please visit for further information.

https://cyclonedx.org/
https://spdx.dev/
Generate SBOM with the Xygeni CLI
From the Web User Interface
Using the Xygeni CLI
Scans page

Reports

Reports section can be reached from Report at the Menu Bar, and contains following pages

  • Governance information about issues discovered, remediation, trends, etc.

  • Historical information related to executed scans

Trends Page
Scans Page

Scan History

At Home >> Scan History, you can access all the historical information related to executed scans.

The Top panel shows a timeline of the frequency of the scans, splitted by:

  • 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.

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)

  • 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)

Scans Comparison

Most of Risk pages contain a functionality to compare scans. It can be accessed by selecting ChangeLog option.

You can either select All, a Project Group, or a specific Single Project at the

Successful scans (SUCCESS)

Scans with errors in analysis (WARNING)

Scans with processing errors (ERROR)

Clicking on the details icon of a scan will open a slide with more information of the scan:

Clicking on the save icon of a scan marks that scan as the baseline of the project.

See for further reference.

See for further information on how to compare scans

Project Baseline
Comparison between different scans
Projects Selector

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.

API

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.

Defining Custom Converters for 3rd-Party Tool Reports

Xygeni provides a framework for developing customized report converters and registering them so they are available in the report-upload scanner command.

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.

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.

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.

Users and Contributors Analysis

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:

Visit these pages for further info:

Advanced Dynamic Prioritization

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.

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.

Audit Trail of Security Events

Xygeni’s Application Security Posture Management platform includes a robust security audit trail feature that provides a comprehensive 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.

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.

Visit these pages for more information:

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:

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:

Git Hooks

Xygeni seamlessly integrates with Git Hooks.

Ticketing and 3rd Party Platforms

Xygeni allows to create tickets, issues and alerts in the following platforms:

Collaboration & Communication Tools

Xygeni allows to configure notifications in the following platforms:

Remediation (auto-fix)

Xygeni allows automatic fixing of certain types of issues in the following platforms:

ASPM User Interface Guide

Xygeni's ASPM section comprises of four primary tabs:

Projects

There is a public GitHub repository, , 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.

The 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.

See for further detail

For full information, read .

If you need to 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.

For further details, read .

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 for more details.

For a full description of ASPM in the Xygeni UI please go to

From source control management (SCM) systems to build tools, CI/CD workflows, and distribution mechanisms, Xygeni captures a detailed 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.

Visit the documentation page for further details

Xygeni enhances its Inventory capabilities by integrating a comprehensive feature.

: 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.

: The system registers all SCM groups, including any users with significant permissions, ensuring that all potential access points are monitored and controlled.

: 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.

.

.

Xygeni's provide extensive customization and precise filtering options.

Visit the page for further info.

Visit the page for further information.

Visit the page for further information.

.

.

For detailed reference, see . Xygeni supports integration with Git Hooks.

Xygeni Extensions
REST API
REST API
Developing and Deploying Custom Detectors
upload a report
Adding Support For Additional Report Formats
Exporting Reports from Third-Party Tools
Xygeni ASPM Web UI
inventory
Inventory
Group and User Tracking
Non-SCM Contributors
Inventory Collaborators
dynamic funnels
Prioritization Funnels
Uploading reports from 3rd party tools
Remediation Actions
Automatic Fix
Azure Pipelines
BitBucket
CircleCI
GitLab
GitHub
Jenkins
TravisCI
Azure Sensor
BitBucket Sensor
GitHub Sensor
GitLab Sensor
Jenkins Sensor
Git Hooks with Xygeni
Projects
All Risks
Governance
Inventory
Health Check
Detailed view of the dependency graph of a real project.
change status button located under project name header when inspecting an issue
Selecetion box to choose the issue status
The change status option showing under the actions tab once an issue is selected
You can also click on the filter icon to open the filter dialog.
As you can see in the above example image: After applying a prioritization criteria, only critical and high severity issues under the Xygeni General Prioritization funnel are shown.

All Risks

All Risks page

Regardless you have selected one single project or a group of projects, All Risks page presents three different views:

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...)

Governance

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:

  • Severity

  • Explanation

  • Issue Category (cicd, iac, secrets, etc...)

  • Issue Type

  • Project (pattern)

  • Issue Status (open, confirmed, muted, etc...)

  • Tag

Funnel Phase (see )

By clicking on the icon on any issue, a slide will open showing all the details for each issue.

Statistics
Prioritization Funnels
Issues Evolution
Prioritization Funnels
Findings and Audit Trail

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

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

A project or group must be selected to access the All Assets tab

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.

Double-clicking on any asset in this graph will show the pivot graph for the selected asset.

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.

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)

You can reach the CI/CD Assets Inventory page by selecting the CI/CD Assets tab at the top of any Inventory page.

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

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.

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

  • 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.

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 (Dependency Graph)

Accessing the Dependency 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.

You can reach the Inventory's Components page by selecting the Components tab at the top of any Inventory page.

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

An important filter is Dependency Type (direct or indirect). This filter allows you to see those dependencies explicitly declared and those that are transitive.

  • 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.

The inventory is compiled automatically by the (during runs of the inventory command) and the integration sensors.

The 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.

For more information, see .

Clicking on the icon will display the Pivot Graph for the selected asset.

Clicking on the icon of any asset will show the Findings and Audit Trail tabs as explained above.

Clicking on the icon will show the for the selected asset.

Clicking on the icon of any asset will show the for the selected asset.

Clicking on the 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 of that project.

In case you have selected a single project into the , the information displayed will be relative to the selected project:

See for further details.

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 for a full description.

Clicking on the icon of any component will open a Summary slide with details of the component:

Xygeni Scanner
Inventory Scan
Inventory Scanner
Component's Alert Type
Pivot Graph
Findings and Audit Trail
download the SBOM
Inventory (panel and slides)
Project Selector

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 (FROM) and the target (TO) scans

The source scan (FROM) allows to be selected among:

  • Pre last scan (the previous to the last executed scan)

  • First Scan (the first scan of the project, by default it's the project baseline)

  • A specific scan (selected by execution timestamp)

The target scan (TO) allows to be selected among:

  • Last Scan (the last executed scan of the project)

  • A specific scan (selected by execution timestamp)

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

You can filter the list by type of change (new and/or removed)

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.

You can reach the Delivery Assets Inventory page by selecting the Delivery Assets tab at the top of any Inventory page.

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

Baseline (the scan tagged as )

Clicking on the icon will show the for the selected asset.

Clicking on the icon of any asset will show the for the selected asset.

Project Baseline
Pivot Graph
Findings and Audit Trail

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

You can reach the Systems & Tools Inventory page by selecting the Systems & Tools tab at the top of any Inventory page.

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

Clicking on the icon will show the for the selected asset.

Clicking on the icon of any asset will show the for the selected asset.

Pivot Graph
Findings and Audit Trail
Collaborator Analysis
Comprehensive Permissions Review
Heath Check Collaborators

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

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:

  1. 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 that have a new version is available.

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:

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.

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:

  1. 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:

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:

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.

Inventory Scanner

Table of Contents

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.

Quick Start

The CLI command to run an inventory scan:

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.

--dir specifies the directory containing the software project to analyze, which may have been cloned from a Git repository.

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.

Running the inventory scan alone should be used for configuration and testing.

The CLI command produces the following output:

The command has the following options:

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.

By clicking on the icon you will be able to open a 3rd-party ticket on the integrated ticketing system

Visit the page for further details

By clicking on the icon, you will see all the details of the selected project.

By clicking on the icon, you will see all the details of the selected component:

To open a ticket using the integrated ticketing system, click on the ticketing icon(see for further details)

By clicking on the icon, you will see all the details of the inactive collaborator (latest activity, permissions and issues)

By clicking on the icon you can open a ticket on the integrated ticketing system (see for further details)

By clicking on the icon, you will see all the details of the over-privileged collaborator (latest activity, permissions, issues and audit trail)

By clicking on the you will be able to open a ticket on the integrated ticketing system (see for further details)

By clicking on the icon, , you'll find all details of the oversized project (including recent activities, file count, size, access level, and all associated assets).

For more details about the inventory please refer to the documentation.

Issues are linked to inventory assets ONLY when the scans are run together with the inventory step. It is recommended to run a full for inventory processing.

Ticketing systems
Findings by Category
Projects
Components
System and Tools
Collaborators
Pipelines
Coverage
xygeni inventory --dir DIR --upload
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
Usage:

xygeni inventory [-huV] [-n=<name>]
  [-d=<directory>] [-e=<excludePatterns>] [-i=<includePatterns>]
  [-repo=<repo>] [--repo-branch=<repoBranch>]
  [--image=<image>] [--image-platform=<platform>]
  [--image-sources=<sources>] [--image-scope=<scope>]
  [-o=<output>] [-f=<format>] [--report-columns=<reportColumns>]
  [-c=<config>] [--[no-]conf-download]
  [--detectors=<detectors>] [--skip-detectors=<skipDetectors>]
  [--never-fail] [@<filename>...]

Discover SDLC assets for a project.

Parameters:
      [@<filename>...]       One or more argument files containing options.
  -n, --name=<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=<directory>      The directory to analyze (default: current directory).
  -i, --include=<includePatterns>
                             Include patterns, comma-separated (optional).
  -e, --exclude=<excludePatterns>
                             Exclude patterns, comma-separated (optional).
                             Example: '**/test/**'

Repository options:
  -repo, --repository=<repo> The repository. Either a URL or scm:owner/repo,
                             like 'github:tensorflow/tensorflow'
  --repo-branch=<ref>        The repository branch or commit SHA to checkout for analysis.
                             HEAD if unspecified.

Container image options:
      --image=<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=<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=<scope>  How layers are analyzed. One of merged, mergedExceptBase, byLayer,
                             byLayerExceptBase. Default: merged.

Output options:
  -o, --output=<output>      Output file. Use 'stdout' or '-' for standard output, 'stderr' for standard error.
  -f, --format=<format>      Output format: none, text, json, csv.
      --report-columns=<reportColumns>
                             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=<config>        Configuration file (default: xygeni.inventory.yml).
      --[no-]conf-download   Download scanner config? (default: true}
      --detectors=<detectors>
                             Comma-separated list of IDs for detectors to run, or 'all'
      --skip-detectors=<skipDetectors>
                             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.

Ticketing systems
Ticketing systems
Ticketing systems
Configuration
Collaborators Scan
Inventory
Purpose
Quick Start
Usage

Collaborators

The Collaborators Inventory displays information about collaborators of your project(s), including:

  • SCM Organizations

  • Users

  • User Groups

You can reach the Collaborators Inventory page by selecting the Collaborators tab at the top of any Inventory page.

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

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.

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)

By default, only user activity from the past 12 months is considered.

Navigate to Collaborators activity

Collaborators analysis tab can be found in SLDC Inventory page:

How to run a Collaborators analysis

Example:

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.

Command line arguments have priority over configuration properties in this file.

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.

Clicking on the icon of any asset will show the details for the selected asset.

(Visit the page)

Collaborators: it is not active by default. See how can be run and what organization assets are gathered.

xygeni inventory --dir DIR --format json --output INVENTORY.json --include-collaborators
# 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: []
Collaborators Inventory
Inventory Collaborators Scan
report-upload reference

Importing reports from 3rd party tools

Report Upload

The report-upload command allows you to import findings from both third-party tools and Xygeni scans into the Xygeni platform.

Typically, results from Xygeni scans are uploaded right away. However, in some cases, you might perform scans and save the results in JSON format to upload later using the report-upload command. This can be useful if the build runner lacks a network connection.

The command validates reports, normalizes findings, and converts them to the Xygeni standard format. It processes findings from different tools for prioritization, filtering, workflow, and remediation. The converted output can be optionally sent to the standard output or saved to a file for validation or baseline generation.

The syntax is:

xygeni report-upload
  [--show-formats]
  [--directory=<path>] [--name=<name>]
  [--prop=name:value [--prop=name:value]...]
  [--never-fail] [--[no-]upload]
  --report=<file> [--format=<format>] [--log-file=<logFile>] [--output=<output> [--compact]] ...
   [@<filename>...]

Converts and uploads an external tool or xygeni scan reports into Xygeni platform.

Parameters:
      [@<filename>...]       One or more argument files containing options.
  -s, --show-formats         Show the formats supported.
  -n, --name=<name>          The software name. Inferred from directory when not provided.
  -d, --basedir=<path>       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:
  -r, --report=<file>        the report file to upload. Use '-' or 'stdin' for standard input.
  -f, --format=<format>      the format / type of the report to upload.
                             Use <tab> to get the available values, when autocomplete is active.
                             Optional. When not given, it will be inferred from the report.
  -o, --output=<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=<logFile>   The xygeni scan logfile to upload (optional).

This command replaces the deprecated xygeni util scan-upload command.

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 reports can be provided, so the -r|--report, -f|--format and -o|--output could be given in triples. Only -r|--report is required, the other flags are optional.

The -l|--log-file only will be used for xygeni scan results and will be ignored otherwise.

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.

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.

The command exits with 0 (OK) when the upload is successful, or with a non-zero exit code if an error occurs. After a successful upload, the command will output the scan code.

Please note that scan results are processed asynchronously so results may not be immediately available after the command concludes.

Examples:

  • List the supported formats:

xygeni report-upload --show-formats
  • Upload a Checkmarx SAST report (xml format):

xygeni report-upload --name=MyApp --format=sast-checkmarx --report=rep/checkmarx.SAST.xml
  • Upload two previously generated xygeni reports:

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 snyk report into xygeni, but do not upload. This could help to check the conversion performed before set in the CI/CD pipeline.

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 Checkmarx One report exported using cx results show command:

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

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 example before shows.

External Scanners Supported

The following is the list of third-party security scanners and report formats supported. Formats and tools are listed in alphabetical order. Xygeni does not endorse any vendor or tool.

SCA (Software Composition Analysis)

Format
Tool
Description

sca-sarif

<any>

Component vulnerabilities detected by a SCA tool, SARIF 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

SAST (Software Application Security Testing)

Format
Tool
Description

sast-sarif

<any>

Code vulnerabilities detected by a SAST tool, in SARIF 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

sca-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-sonarcloud

SonarCloud

SonarCloud SAST JSON report

sast-sonarserver

SonarServer

SonarServer SAST JSON report

IaC Flaws

Format
Tool
Description

iac-sarif

<any>

IaC vulnerabilities detected by a IaC tool, in SARIF format

iac-checkov

Checkov

Checkov IaC scanner, JSON format

iac-kics

KICS

IaC vulnerabilities detected by KICS, in 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'

Secret Leaks

Format
Tool
Description

secrets-sarif

<any>

Secrets detected by a secrets tool, in SARIF format

secrets-gitleaks

GitLeaks

Secrets detected by GitLeaks, in JSON format

Report upload for Kiuwan

About

Kiuwan is a powerful, end-to-end application security platform. Kiuwan Static Application Security Testing (SAST) product is the tool that detects security vulnerabilities in source code using static analysis.

The problem is that Xygeni does not provide a mechanism in the agent (Kiuwan Local Analyzer) for writing to a local file the findings from the tool.

How report extraction works

The Kiuwan scanner (Kiuwan Local Analyzer) by default uploads its findings to the Kiuwan platform.

Steps

1. Compile the extraction rule (optional)

As Kiuwan only allows one technology in a rule descriptor, it is necessary to generate a descriptor for each technology available. The OPT.CRITERIUM_VALUE.LANGUAGE_PARSER.<TECH> is set on each rule descriptor.

2. Install rules and jar file

Once rules and jar uploaded and added to the Kiuwan model, the local analyzer will execute the exporter rule when the output report is given, so it can be uploaded into Xygeni.

3. Run the scan

Run the Kiuwan Local Analyzer with the path to the report file provided in the KIUWAN_JSON_REPORT environment variable.

The export rule does nothing if the KIUWAN_JSON_REPORT is not given. The path for the report could be absolute or relative. When relative, the path is prefixed with $HOME (the OS user home directory)

4. Upload the Kiuwan report to Xygeni

Use the xygeni report-upload command for uploading the exported report, after normalization to the Xygeni SAST format.

The formats available are listed in the section.

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 () or GitLab’s .

Go to for further details.

For Kiuwan, exporting the findings to a local file needs special configuration, as documented in

For Sonar, json report can be downloaded from issues/search endpoint at , 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, …​

To export the findings to a local file for uploading into third-party tools like Xygeni, the approach used was to register the custom rule provided that registers a task to export the findings at the end of the analysis, using the standard-provided report formatter for the xml_issues report, the same format that the agent uses to send the findings to the Kiuwan on-cloud service.

The rule JAR and rule descriptors are already provided in the directory for your convenience. Anyway, the jar with the compile rule could be generated using Maven:

The compilation will copy the jar into dist and run the script to create a rule descriptor for each technology, which stores all rule descriptors into .

Next, follow the instructions to upload the and the to Kiuwan.

Read in Kiuwan documentation for full details on how to install rule definitions and their implementations, so the exporter rule may work at your installation. You need also to add the imported rules to an existing model, so the local analyzer will download them.

external scanners support
SARIF
Security Report Schemas
report-upload command reference
xygeni-extensions - Report upload for Kiuwan
SonarCloud Web API GET api/issues/search
$ cd extensions/report_upload/kiuwan
$ mvn package
$ KIUWAN_JSON_REPORT=/path/to/my/report.xml
$ agent.sh -s DIR -n NAME -c
...
Report file available at: /path/to/my/report.xml
xygeni report-upload --report=/path/to/my/report.xml --format sast-kiuwan

ExportRule (.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.
 * <p>
 * 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;
    }
  }

}
ExportRule
dist
generate_rules.sh
dist/rules
kiuwan-export-rule jar
rule descriptors
Installing custom rules created with Kiuwan Rule Developer

Code Security (SAST)

Code Security User Interface Guide
Risks (SAST)
Malicious Code
Malware Scanner
SAST Scanner

Code Security (SAST) User Interface Guide

Code Security (SAST) User Interface

Code Security User Interface can be accessed from the Navigation Bar under the Code Security Section.

The Code Security section includes the following content:

  • Risks (SAST):

: A summary of all SAST security issues.

: Details of any potentially malicious code identified in your source code.

Risks (SAST)
Malicious Code

Risks (SAST)

The Risks (SAST) page offers an in-depth overview of all SAST security issues, clearly presented for ease of assessment.

Xygeni provides two functionalities related to SAST scanning

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.

You can reach the Risks (SAST) results under Code Security >> Risks (SAST) section.

Xygeni provides a that can perform static analysis over your application code. Please visit for further information.

Xygeni also provides the functionality to . This way, you can integrate 3rd-party data into Xygeni and benefit from the functionalities. The supported SAST scanners are listed in the section.

In the issues table, by clicking on the icon of any issue, you will see the details of the issue.

SAST Scanner
Xygeni SAST Scanner
import scan results from 3rd-party tools
Xygeni ASPM
supported SAST scanners

Malicious Code

You can reach the Malicious Code tab by selecting the Malicious Code tab of the Code Security page.

The Malicious Code page offers a detailed overview of all the potentially malicious code detected within your source code by Xygeni's .

In the issues table, by clicking on the icon of any issue, you will see the details of the issue.

Malware Scanner

Malware Scanner

Table of Contents

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.

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.

The maliciousness score of the project depends on the total quantity and severity of the evidence identified.

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.

xygeni malware -n MyProject --upload

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] )

Export malware evidence with critical severity to CSV for review or to import findings into other tools:

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:

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.

Configuration options:
      --custom-detectors-dir=<customDetectorsDir>
                             Directory with custom detectors.
      --detectors=<detectors>
                             Comma-separated list of IDs for detectors to run, PRIORITY or 'all'
      --skip-detectors=<skipDetectors>
                             Comma-separated list of IDs for detectors to ignore, or PRIORITY
      --kinds=<kinds>        Resource kinds to scan (execution, file, network, _package, registry,
                               sensitive_data, system, all).
      --skip-kinds=<skipKinds>
                             Resource kinds to ignore (execution, file, network, _package, registry,
                               sensitive_data, system, all).

Malware Detectors

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 ()

Please refer to the documentation for information regarding this topic.

Common types of Malware found in Open Source Packages
Malware detectors
Purpose
Quick Start
Usage
Malware Detectors

Malware Detectors

Malware Detectors

Malware Scanner Configuration

Malware Scanner Configuration

# 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

Specify a directory for custom detectors with the --custom-detectors-dir command-line option to prevent scanner updates from overwriting your configurations.

SAST Scanner

Table of Contents

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:

xygeni sast -n MyProject --upload

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] )

Export code vulnerability with critical severity to CSV for review or to import findings into other tools:

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:

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.

Configuration options:
  -c, --conf=<config>        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. <list> 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. <list> is comma-separated list of detector IDs, or a severity.
      --custom-detectors-dir=<customDetectorsDir>
                             Directory with custom detectors.

You can find a comprehensive list of all the available malware detectors at .

The is configured in the YAML file conf/xygeni.malware.yml :

Detectors are configured with different YAML files located under the conf/malware directory of the .

There is a sample _template.yml_ file that can be used to create your own .

Please refer to the documentation for more information.

detectors.xygeni.io
Malware Scanner
Xygeni scanner
Malware detectors
custom detectors
Purpose
Quick Start
Usage

SAST Scanner Configuration

SAST Scanner Configuration

# 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: 1200

# Timeout, in seconds, for parsing a file. 0 or negative means no timeout.
parsingTimeout: 20

# 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

Specify a directory for custom detectors with the --custom-detectors-dir command-line option to prevent scanner updates from overwriting your configurations.

The is configured in the YAML file conf/xygeni.sast.yml.

Detectors are configured with different YAML files located under the conf/sast directory of the .

There is a sample _template.yml_ file that can be used to create your own .

SAST Scanner
Xygeni scanner
custom detectors

Open Source (SCA) User Interface Guide

Open Source (SCA) User Interface

The Open Source User Interface can be accessed from the Navigation Bar under the Open Source (SCA) Section.

The Open Source section is divided into the following

: A comprehensive view of all your dependencies

: A summary of all SCA security issues.

Open Source Components
Risks (SCA)

Open Source Components

The Open Source Components page provides a comprehensive view of all your project's dependencies :

You can reach the Open Source Components page by selecting Open Source(SCA) in the Navigation Bar

Component's Alert Type

The Alert filter field allows you to see those dependencies with License warnings, dependencies tagged as Malicious code or Obsolete dependencies.

Licensing Risks

Filtering by Licensing allows you to see those dependencies with some kind of License warning.

A Licensing Compliance Alert typically has to do with usage of Copyleft licenses.

Dependencies with Malware

Filtering by Malware allows you to see those dependencies that have been identified as malware.

Malware alerts may come from two possible sources:

This page is an Inventory view of your dependencies. Please refer to for a full description.

Components with License alerts can be identified by icon.

Clicking on the icon of a component with a License alert will open a Summary slide with details of the component.

Components with Malware alerts can be identified by the icon.

Clicking on the icon of a component with a Malware alert will open a Summary slide with details of the component.

For "known" malware: Xygeni gathers details from public sources (, and among others) to identify and document these components.

For "unknown" malware: Xygeni provides a functionality that conducts real-time scans to detect and block malware based on code behavior analysis.

Refer to the documentation for further details.

Inventory - Components
NIST's NVD
GitHub Advisory Database
OSV
Malware Early Warning (MEW)
Malware Early Warning

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.

Types of Suspect Dependency Detector

  • 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.

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.

Risks (SCA)

SCA Statistics

The Open Source Risks (SCA) provides a comprehensive view of all the security issues of the dependencies.

You can reach the Open Source SCA statistics either by selecting Risk selecting the top-right statistics tab of the SCA page.

Statistics

Secrets' Statistics view shows:

  • Charts for # of issues by severity, by type and by type & severity

  • A table with the issues (as well as a filter for the table)

You can use filters to select specific issues:

  • By severity

  • By issue type

  • By dependency type (direct or indirect)

  • By project (pattern)

  • By issue status (open, confirmed, muted, etc)

  • By tag

  • etc.

Public Vulnerabilities (CVEs)

The Reachability Analysis tab provides detailed information on the call paths leading to the component's vulnerable method(s).

Malware Early Warny details (MEW)

The Summary tab shows detailed information about the component:

  • Explanation

  • Component name

  • Location where defined

  • Description

The Malware Evidence tab provides detailed information about the detected code evidence.

OSS Prioritization Funnels

OSS Prioritization funnel

The Open Source's Prioritization funnel view shows default Open Source funnel.

Xygeni's Prioritization Funnels allow you to easily identify the most critical issues, enabling you to "fix what matters most".

OSS Auto-Remediation

Automatic Fix for Open Source Vulnerabilities

Xygeni can automatically fix vulnerabilities in your open source dependencies.

Actionable fixes for supported ecosystems appear in the scan results as shown in the following example:

Filtering by Auto fix available you will see which vulnerabilities can be automatically fixed by Xygeni.

The Fix vulnerability button will be enabled if the issue is tagged as Auto Fix

In this example, you can see that the vulnerability (CD-2019-10744) is related to lodash version 4.17.11 and resolved in version 4.17.12.

Clicking on Fix vulnerability button will open a dialog where you can view the manifest file changes to upgrade to the fixed version. You can also view the repository details and the Pull Request that will open with the proposed change.

Clicking on Open PR button will create the Pull Request.

Navigate to your source control management system (e.g., GitHub) to view the newly created branch.

The newly created branch will include a commit encompassing the proposed modifications.

You will receive notification of the newly created Pull Request, enabling you to review and approve it for merging into the protected branch.

Supported Package Managers for dependency resolution

Please visit for a full description of supported package managers.

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 for a complete list.

See and, more specifically, and for instructions on how to execute an Open Source scan.

See and, more specifically, and for instructions on how to execute an Open Source scan.

See and

Open Source Risks (SCA) page is the same as All Risks but filtered by Open Source category, so please go to for a full description.

By Funnel Phase (see )

By reachability (see )

by fixability (see )

Clicking on the icon of a component with public vulnerabilities will open a slide with detailed information about the CVE.

Vulnerabilities also show information about Fixability. Please see for further details.

Please visit the documentation for further information.

Clicking on the icon of a component with malware detected by Xygeni will open a slide with details.

See for further details

To enable this functionality, please configure as explained at the documentation.

Click on the icon of any issue in the table to view its details.

Please see for further information on how to configure auto-remediation

Package Manager
Language
Supported Dependency Files
Supported Package Managers for Dependency Resolution Analyzers
Open Source Analyzers
Scan with Xygeni CLI
Dependency Scanner
Suspect Dependencies Scanner
Scan with Xygeni CLI
Dependency Scanner
Suspect Dependencies Scanner
Malware Detection
Malware Early Warning Service
All Risks
Prioritization Funnels
reachability
fixability
Fixability
Reachability
Prioritization Funnels
Remediation Systems

How Malware Early Warning works

How MEW works

This service starts by continuously monitoring public registries to identify suspicious packages immediately upon publication. When a potential threat is detected, it is automatically isolated, preventing it from infiltrating your development environment or the wider software supply chain.

The quarantined package is then reviewed by Xygeni's security engineers to verify the threat. If the threat is confirmed, it is reported to the registry for further validation and public disclosure. This multi-layered verification process ensures that only verified threats are acted upon, minimizing false positives and ensuring accurate threat detection.

MEW Notifications

The Malware Early Warning service also includes immediate notifications to affected users. These notifications are sent through various channels such as email, messaging platforms, and webhooks, ensuring the customers are promptly informed of any threats. This rapid response capability allows you to mitigate risks immediately and protect your software projects from potential harm.

In addition to notification and quarantine, the Malware Early Warning service provides a detailed process for handling detected threats. This includes confirming the threat with the public registry, safely disposing of the malicious package and publicly disclosing the threat to inform the wider community.

How MEW protects you during CI/CD

Malware Early Warning provides robust mechanisms to protect the software development lifecycle from integrating malicious code into the application.

In this scenario, the build pipeline continues successfully with the safe component version. However, if a new malicious version of the component is released, Malware Early Warning kicks into action.

A real-time scan of public registries identifies new packages and updates to existing ones. Xygeni analyzes them for suspicious code and notifies the customer immediately about the detected malware evidence and advances in the process. Furthermore, it marks the component version as malware and puts it in quarantine to protect the SDLC infrastructure and build and delivery processes.

This technology can also be integrated with private registries to create a blacklist, blocking malicious components from entering your organization.

Continuous monitoring, real-time threat detection, and instant blocking mechanisms work together to safeguard the software supply chain's integrity and security, protecting both the organization's applications and end-user security.

Malware Early Warning (MEW)

Cybersecurity solutions primarily focus on detecting and addressing known vulnerabilities such as Common Vulnerabilities and Exposures (CVEs) to combat malware.

While this approach provides a foundational level of security, it has significant limitations that can expose organizations to sophisticated zero-day attacks among others.

Relying on CVEs means these solutions primarily respond to known threats. New and unknown vulnerabilities, can remain undetected until a CVE is published.

While organizations may believe they are protected by addressing all known CVEs, there is still a significant risk from unknown threats and advanced malware that exploit novel vulnerabilities. Comprehensive security measures are essential to safeguard against these sophisticated attacks.

According to the 2023 IBM X-Force Threat Intelligence Index, 29% of security incidents involved malware that exploited unknown or zero-day vulnerabilities, underscoring the limitations of a solely CVE-focused approach.

Key Benefits of the Early Warning Service:

  • Proactive Malware Blocking: Detect and block zero-day malware as soon as new packages are published, preventing malicious code from entering your development environment.

  • Immediate Notifications: Receive real-time alerts through standard Xygeni mechanisms, enabling rapid response to mitigate risks.

  • Comprehensive Threat Review: Security researchers review suspicious packages, and findings are confirmed with public registries to ensure accurate threat assessment. Our customers can review them in our Web UI.

  • Public Disclosure and Community Protection: Confirmed threats are publicly disclosed to inform the wider community and prevent re-entry into the ecosystem.

Java

pom.xml

Java, Kotlin

build.gradle, build.gradle.kts, gradle.lockfile, gradle.properties

JavaScript

package.json, package-lock.json

JavaScript

yarn.lock

JavaScript

pnpm-lock.yaml

JavaScript

bower.json

.NET, C#

.nuspec, packages.config, .csproj, project.assets.json, packages.lock.json

Python

requirements.txt, pipfile.toml, pipfile.lock, setup.py, setup.cfg, environment.yml

Python

requirements.txt, pyproject.toml, poetry.lock

Golang (Go)

go.mod, go.sum

PHP

composer.json, composer.lock

Ruby

Gemfile, Gemfile.lock

The process begins when a developer introduces a new dependency into the project. The risk appears if there is no version pinning to ensure that an exact dependency version is specified and used in the build process. Xygeni will raise an issue if the version is un-pinned (see ), indicating that any component update will be integrated immediately into the application, which might introduce vulnerabilities or malware.

The security checks (see ) in the CI/CD pipelines detect the component as malicious. They can implement mechanisms to block the build process to ensure only secure dependencies are used. Taking preemptive measures prevents the deployment of compromised dependencies, thus avoiding infections and eliminating the need to fix this later.

In addition to SCA features (see ), Xygeni offers a Malware Early Warning (MEW) Service designed to raise alerts for suspicious packages. This service proactively protects your software supply chain and supports the implementation of security gates to block malware threats before they infiltrate your application.

Xygeni CI/CD Scan
Guardrails
Open Source Security
Maven
Gradle
NPM
Yarn
PNPM
Bower
Nuget
Pip
Poetry
Go Modules
Composer
RubyGems

Common types of Malware found in open source packages

Common Types of Malware Found in OSS

Backdoor

A backdoor is a method of bypassing standard authentication procedures to gain access to a system. Attackers can install backdoors to maintain persistent access to compromised systems, allowing them to execute commands and control the system remotely. These are often used to launch further attacks or exfiltrate data over an extended period.

Dropper

A dropper is a malware designed to install other malicious software onto a target system. Droppers can be standalone programs or embedded within other legitimate software. Once executed, they "drop" additional payloads, including any form of malware such as trojans, ransomware, or spyware.

Evader

Evader malware is specifically designed to avoid detection by antivirus software and other security measures. It employs techniques such as code obfuscation, encryption, and polymorphism to hide its presence and actions from security systems, making it difficult to detect and remove.

Generic

Generic malware refers to a broad category of malicious software that doesn't fit into a specific subtype but shares common malicious characteristics. These can include unauthorized data access, system damage, and network disruption. Generic malware often serves as a catch-all term for unidentified or novel threats.

Phishing

Phishing involves tricking users into divulging sensitive information such as login credentials or financial data. This is typically done through fraudulent emails, websites, or legitimate messages. Phishing malware can include keyloggers or other tools to capture the user's input and relay it back to the attacker.

Spyware

Spyware is designed to gather information about a user or organization without their knowledge. It can include capturing keystrokes, screenshots, browsing habits, and accessing sensitive information stored on the system. Spyware often operates stealthily to avoid detection while continuously collecting data.

Banker

Banker malware explicitly targets banking and financial transactions. It aims to steal sensitive information such as login credentials, account numbers, and PINs. Banker malware often uses keylogging, screen capturing, and man-in-the-middle attacks to intercept data during online banking sessions.

Trojan

A Trojan, or Trojan horse, disguises itself as legitimate software to trick users into executing it. Once installed, it can perform various malicious activities, such as creating backdoors, stealing data, or downloading additional malware. Trojans rely on social engineering to spread, often through email attachments or software downloads.

Keylogger

Keyloggers record every keystroke on a computer, capturing sensitive information such as usernames, passwords, and credit card numbers. The attacker then receives this data. Keyloggers can be hardware or software-based and are often used with other malware to maximize data theft.

Stealer

Stealer malware is designed to extract specific types of information from a system, such as passwords, cookies, and browser history. It targets stored credentials and sensitive data to transmit back to the attacker. Stealers often focus on web browsers and email clients to harvest valuable information.

Bot

A bot is a type of malware that turns an infected computer into a "bot" or "zombie," which an attacker can control remotely. Bots are typically used to form botnets, networks of compromised computers used to conduct large-scale attacks, such as distributed denial-of-service (DDoS) attacks, spam campaigns, or data breaches.

Ransomware

Ransomware encrypts a victim's files and demands a ransom payment for the decryption key. It often spreads through phishing emails or exploit kits. The encryption used by ransomware is typically strong, making it nearly impossible to recover the files without the decryption key provided by the attacker upon payment.

Worm

Worms are self-replicating malware that spreads across networks by exploiting vulnerabilities. Unlike viruses, worms do not need to attach themselves to an existing program. They can cause significant damage by consuming bandwidth, overloading servers, and delivering payloads, such as ransomware or trojans, to other systems on the network.

Crypto-Miner

Miner malware uses the infected system's resources to mine cryptocurrencies, such as Bitcoin or Monero, without the user's consent. It can significantly slow down the system and increase power consumption. Miner malware often spreads through malicious websites, infected software downloads, and vulnerabilities in network security.

Dependency scanner configuration

Configuration

The scanner configuration file, named conf/xygeni.scan-deps.yml, specifies properties for:

  • Selecting Files to Include or Exclude. For example, in Node.js projects, it's common practice to exclude the node_modules directory to prevent issues with outdated or

  • SBOM Configuration and report output.

  • Configuration for each ecosystem analyzer.

  • Scan configuration properties like timeouts and mode = sequential or parallel.

Arguments from the command line have priority over properties in this file.

Dependencies Analyzers

Dependencies for each ecosystem are processed by a specific analyzer. The analyzer processes dependency's descriptors to extract direct and indirect dependencies, resolve their versions, and gather context information like licensing, provenance and other metadata.

Dependency Scanner

Table of Contents

Purpose

The Dependency Scanner (DS) is a useful tool to collect and analyze the dependencies of a software project. Aimed at identifying issues related to software supply-chain security. Dependencies are components or packages used in software that will be analyzed for known vulnerabilities or evidence of malware.

Quick Start

Use the following command to generate a list of both direct and indirect dependencies used within your project and identify potentially risky dependencies. Then upload them to the Xygeni Platform for review.

xygeni deps -n MyProject --format=text --upload
Running xygeni...

2022-11-15 11:11:25.914 [main] INFO  com.depsdoctor.cli.commands.ScanDepsCommand - Scan statistics:
{"elapsedTime":"00:00:39.632","files":150,"filesByKind":{"Jar Analyzer":150},
"dependencies":122,"depsByEcosystem":{"jar":121,"unknown":1}}

Dependencies found: 122
┌───┬──────────────────────────────────────────────────┬─────────┬────────┬────────────┬─────┐
│Id │Group:Name:Version                                │Ecosystem│Language│  License   │Flags│
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
│1  │org.apache.logging.log4j:log4j-slf4j-impl:2.19.0  │   jar   │  java  │ Apache-2.0 │     │
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
│2  │com.vdurmont:semver4j:3.1.0                       │   jar   │  java  │    MIT     │     │
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
│3  │org.slf4j:slf4j-api:1.7.36                        │   jar   │  java  │            │     │
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
│4  │org.apache.logging.log4j:log4j-core:2.19.0        │   jar   │  java  │ Apache-2.0 │     │
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
│5  │org.zeroturnaround:zt-exec:1.12                   │   jar   │  java  │ Apache-2.0 │     │
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
...
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
│140│com.fasterxml.jackson.datatype:jackson-datatype-js│   jar   │  java  │ Apache-2.0 │     │
│   │r310:2.13.3                                       │         │        │            │     │
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
│150│com.squareup.okhttp3:okhttp:4.10.0                │   jar   │  java  │ Apache-2.0 │     │
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
│157│com.diogonunes:JColor:5.2.0                       │   jar   │  java  │    MIT     │     │
├───┼──────────────────────────────────────────────────┼─────────┼────────┼────────────┼─────┤
│0  │:test:                                            │ unknown │        │            │ RV  │
└───┴──────────────────────────────────────────────────┴─────────┴────────┴────────────┴─────┘
Flags: R=top-level P=project V=virtual D=direct dependency

The Open Source Dependencies scanner can be launched in two different ways:

  • Running its own specific command ( xygeni deps [options] )

  • Running the general command ( xygeni scan --run="deps" [options] )

Usage

The Open Source Dependencies Scanner is launched using the xygeni deps [options] command.

To view all available options, use the --help flag:

xygeni deps --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.

How to generate SBOM for a software project

A Software Bill Of Materials (SBOM) is an inventory that details the components, including direct and indirect dependencies, along with their relationships and relevant metadata.

The xygeni deps can be used to generate the SBOM, in the following formats:

Dependency Analyzers

The result is the full dependencies graph, which may contain components in different ecosystems, where each component is resolved in terms of name, group/owner/scope and version, along with metadata (license, provenance, tags and more) that could be useful for assessment of the security risk.

Each major ecosystem is handled by a specific analyzer. The following sections describe each analyzer, how it works, and which are the inputs analyzed.

Maven Analyzer

This analyzer fetches the dependencies for maven projects. The analyzer executes mvn dependency:tree and processes the result.

The analyzer checks if pom.xml files exist in the source code. In this case, the analyzer executes the command:

If you have not the mvn command installed, this analyzer will be disabled, and the dependencies from the pom.xml files will not be resolved.

How to specify a different location of settings.xml ?

Xygeni allows to customize mvn command to suite your specific needs.

One of these usual needs is to specify an alternate location of settings.xml file (remember that by default mvn will search for it at $HOME/.m2 ).

If you need mvn to use a settings.xml located at a different location, you can define a env var named MVN_OPSand assign additional parameters (in this case --settings).

As an example, if you run the scanner as shown below, the dependency scanner will use the settings.xml specified by the env var.

Similarly , you can specify whatever other maven additional parameters you may need.

Gradle Analyzer

This analyzer fetches the dependencies for gradle projects. The analyzer executes gradlew -q dependencies or gradle -q dependencies if the gradlew does not exist and processes the result.

The analyzer checks if build.gradle or build.gradle.kts files exist in the source code. In this case, the analyzer executes the command:

If the project has no the gradlew file and you have not the gradle command installed, this analyzer will be disabled, and the dependencies from the build.gradle or build.gradle.kts files will not be resolved.

Npm Analyzer

This analyzer fetches the dependencies for Node projects using npm or yarn package managers. The analyzer uses yarn.lock, npm-shrinkwrap.json, package-lock.json or package.json ("lock" and "manifest") files.

These files are processed in the following order: yarn.lock > npm-shrinkwrap.json > package-lock.json > package.json. Package lock files are recommended for repeatable builds, as they have all packages and versions resolved in the dependency tree.

When no lock file is found, package.json is processed and the analyzer generates a yarn.lock file in a temporary directory by executing the command

If yarn command is not installed, the analyzer will try to install it in a temporary directory.

If no lock file is found and npm is not installed, then the analyzer will not be able to extract the dependencies. And node_modules directories are ignored by the analyzer.

With npm, it is important to have the lockfile in sync with the manifest. If not, an npm install from a user or the package may resolve a dependency to an unintended version. The npm clean-install (or npm ci for short) makes a clean install that also checks for consistency between the lockfile and the manifest.

Bower Analyzer

This analyzer fetches the dependencies for projects using bower package manager and bower.json manifests. The analyzer runs the command

If you have not installed bower, this analyzer will be disabled and the dependencies of the bower.json files will not be resolved.

All bower_components directories in the analyzed will be ignored.

Dotnet Analyzer

This analyzer fetches the dependencies for dotnet projects. To obtain this information, the analyzer uses project.assets.json manifests.

To generate these manifests, you should execute dotnet restore command. You can execute

The analyzed project will not have associated frameworks, but the rest of dependencies will have the associated framework. If a dependency is on two frameworks, it appears twice, once per framework. For example:

The Dependency Scanner does not execute dotnet restore command automatically.

Go Analyzer

Extract dependencies for Go modules, from go.mod files. The analyzer runs thego mod graph command.

If the go toolchain is not installed, the analyzer will be disabled and Go modules will not be analyzed.

Pip Analyzer

This analyzer fetches the dependencies for python projects. The analyzer uses the setup.py files to get information for the currently analyzed projects and its dependencies.

The analyzer executes thepipgrip library to get the dependencies tree, if the environment has not installed this library the analyzer tries to install pipgrip in a temporary directory to execute the command and after the directory will be deleted. The commands executed is:

As a prerequisite, the packages must be installed. And in the case that pipgrip and pip are not installed, then this analyzer will be disabled.

Composer Analyzer

This analyzer fetches the dependencies for PHP projects. The analyzer uses the composer.json files to get information for the currently analyzed project and his dependencies.

The analyzer executes the commands:

The analyzer needs that the composer command is installed and the components analyzed have been installed to resolve the dependencies correctly.

Gem Analyzer

This analyzer fetches the dependencies for Ruby gem projects. The analyzer uses Gemfile.lock file to get information about the dependencies.

The ruby gem name for the current project is the directory name that contains the Gemfile.lock file.

Suspect Deps Scanner Configuration

Suspect Deps Scanner Configuration

The Misconfigurations Scanner is configured in the YAML file conf/xygeni.suspectdeps.yml

Suspect Deps Detectors Configuration

The kind of detectors for this scanner report potential known attacks to software dependencies, like dependency confusion or typosquatting for the vulnerable ecosystems.

In addition, public components exhibiting certain traits like presence of certain installation scripts, anomalies in the commit patterns, the component’s project metadata, or the provenance of its maintainers could also hint on a potential malicious component. Private components with no scope / namespace are also reported as suspect.

External security advisories and security teams may also report known malware components.

Suspect Dependencies Scanner

Purpose

The Suspect Dependencies Scanner finds suspect dependencies (suspect deps for short) that may be the target of supply-chain attacks.

The aim is to detect potential flaws in the dependencies, direct or indirect, in the software project and DevOps tools around, so supply-chain attacks can be prevented.

Handling findings

Once a certain third-party component is known as malware, removing it for all software could be excruciating. Also, tracing what malicious code could have done in the exposure window between the component installation and its detection, often requires forensic analysis.

The detector documentation provides a Mitigation / Fix section that describes the recommended actions. Some reference practices that help to reduce the risk against dependencies-targeted attacks, like version pinning, using white-listed components from internal package registries, enforcing scoped internal components, or blocking installation scripts in package managers.

Quick Start

For detecting misconfigurations found in software project with sources in current directory, the command:

uploads the result to Xygeni platform.

Suspect Deps scanner can be launched in two different ways:

1.- By its own specific command ( xygeni suspectdeps [options] )

2.- By the general command ( xygeni scan --run="suspectdeps" [options] )

For exporting the most important suspect dependencies to CSV for review, or importing the findings into another tool:

Usage

The Suspects Deps Scanner is launched using the xygeni suspectdeps [options] command.

For a full reference of all the available option, you can issue :

The most important properties are:

  • Name of the project, -n or --name.

  • Input, either a directory (-d|--dir) or a repository (-repo|--repository). If none is given, the local current directory is assumed.

  • The JSON dependencies model generated from xygeni deps command could be used as input to the suspectdeps with the -r | --report option. If not provided, the dependencies model is extracted.

  • 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 (or stdout / - are used), the standard output is used. Use --format=none for no output.

  • The detectors to run could be tailored with the --detectors / --skip-detectors options. A common use-case is to consider only issues with high or critical severity with --detectors=high.

So, for example, setting --skip-detectors=steps_sbom,signed_commits will disable the two detectors.

Another use case is to disable issues with info / low severity (--skip-detectors=low) or equivalently enabling only high or critical issues (--detectors=high).

See for the list of supported package managers.

SBOM properties: output file --sbom and format --sbom-format. See for an example.

, a lightweight Software Bill of Materials (SBOM) standard designed for use in application security contexts and supply chain component analysis..

, The Software Package Data Exchange open standard (ISO/IEC 5962:2021).

The extracts the software's dependencies by analyzing the project descriptors that reference direct dependencies and getting their dependencies transitively.

You have more information .

You have more information about this .

to get help. You have more information about the dotnet restore command .

For further information about dependency management in the Go ecosystem, see .

Please read the documentation on .

The dependency graph (in fact, the result of the ) is analyzed to look for known issues with dependencies. The well-known typo-squatting, dependency confusion or dependencies with suspicious installation scripts are examples of suspect dependencies.

There could be certain detectors that should not be run for a certain project, or because the practice enforced by the detector does not fit with the organization policy. Disabling detectors could be done, in order of prevalence: - by disabling the intended detector(s), listing their IDs in the --skip-detectors option. - at the level, - by deactivating the detector at the central configuration level (e.g. by setting enabled: false in the detector YAML configuration).

Supported Package Managers for dependency resolution
Generate SBOM for a software project
CycloneDX
SPDX
Purpose
Quick Start
Usage
How to generate SBOM for a software project
mvn dependency:tree
export MVN_OPS="--settings /foo/bar/settings.xml"
xygeni scan [rest of flags]
gradle -q dependencies
yarn install --ignore-scripts --modules-folder ${TEMPDIR}/node_modules
bower list -j
dotnet restore -h|--help
.NETFramework 4.6:Microsoft.Build.Tasks.Git:1.0.0
.NETStandard 2.0:Microsoft.Build.Tasks.Git:1.0.0
pipgrip --tree --json
# To get all dependencies with resolved version
composer show -f json

# To get the dependency tree
composer show -t -f json
xygeni suspectdeps -n MyProject --upload
xygeni suspectdeps -n MyProject --detectors high \
       --format csv --output MyProject.suspectdeps.csv
xygeni suspectdeps --help
Dependency Scanner
here
here
here
managing dependencies in Go
Suspect Deps detectors available
Dependencies Scanner
policy

CI/CD Security

CI/CD Misconfigurations Detection

Overview

Xygeni’s Supply Chain Security protects your CI/CD pipelines by scanning configuration files, build scripts, and CI job definitions.

Supply Chain's CI/CD detectors identify deviations from security best practices and standards, providing immediate alerts on potential misconfigurations that could lead to unauthorized access or code or pipeline execution compromises.

With a robust set of rules based on the latest security advisories, Xygeni ensures every component of your pipeline adheres to the highest security protocols.

Detected issues may include improper settings in package managers, insecure build file or infrastructure configurations, or risky CI jobs or plugins, all of which are notified for rapid correction to maintain the integrity and safety of your software delivery processes.

Find and fix misconfigurations by scanning every tool in DevOps platform

Modern software pipelines integrate multiple tools ranging from SCM repositories and build tools to CI/CD systems and configuration management tools. Misconfigurations at these tools open the door to supply chain attacks.

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

Contextualized remediation procedures are provided, so DevOps engineers can quickly fix the misconfiguration and learn how to avoid similar issues in the future.

Protect continuously the pipelines to your cloud-native supply chain

Avoid data leakage and malicious code injection, hardening SCM repositories and CI/CD tool configurations.

The misconfigurations are detected across the tools in the cycle chain, from development items like code repositories, build tools, CI systems to operations at IaC templates, container images in registries, or cloud platforms.

Harden your runtime environment

Detects misconfigured resources in code and vulnerable images before deploying to your runtime environment.

Summary of Supply Chain CI/CD detectors

Here’s an integration of the supported systems into the summary of key misconfiguration detectors for Xygeni:

CI/CD Security Detectors:

  • Enforce appropriate permissions and secure configurations across CI/CD tools and workflows, specifically tailored for platforms like GitHub, GitLab, Azure DevOps, Bitbucket, CircleCI, and Jenkins.

  • Verify the integrity of build processes and prevent unauthorized code or pipeline changes, with specific checks for each platform to ensure compliance and security.

  • Monitor for unusual activities and ensure encrypted storage and handling of secrets across all supported CI/CD platforms.

Container and Dependency Management:

  • Apply best practices in container configurations, such as avoiding running as root and ensuring secure file operations across various CI environments, including Jenkins and CircleCI.

  • Maintain secure connections by enforcing HTTPS for remote repository access and ensuring proper version control on platforms like GitHub, GitLab, and Azure DevOps.

Compliance and SCM Detectors:

  • Support compliance with key standards like CIS, NIST, and OpenSSF, ensuring security policies are adhered to across all integrated platforms.

  • Secure source code management practices, including enforcing MFA, signed commits, and code review protocols, particularly on platforms like GitHub, GitLab, and Bitbucket.

General Security Practices:

  • Detect and prevent insecure webhook configurations, unprotected branches, and insecure dependencies across all supported systems. • Monitor and validate security policies, ensuring continuous compliance and signed releases within the integrated ecosystem.

To accomplish these functionalities, Xygeni provides a Scanner and a Web UI to view the results.

Build Security

The process of building and deploying modern software is complicated. The attack surface is wide: compilers, source code repositories and tools (build, package managers, artifact registries, testing, security scanners) can be affected to let code / configuration tampering pass undetected, or to implant malicious behavior.

Software artifacts are often opaque blobs that can’t easily be inspected for security. It is easier to reason about how they came to be (provenance), rather than what is in them. So what can be done to harden the build & deploy system? How can an organization attain tamper-proof builds?

Tamper-proof builds, where the focus is to prevent or detect tampering during the build is hard to achieve and needs a strong hardening of the build platform, which is not always possible. Having signed attestations generated by a hosted build platform is a previous stage, with focus on detecting tampering after the build. For software attestations the following is necessary:

(1) generating “attestations”, authenticated metadata about software artifacts produced by each build step, linked with the inputs (“materials”). Each step in the pipeline must conform with a pipeline layout, where an owner defines the steps and conditions to be fulfilled.

(2) storing the attestations in a kind of evidence repository or "ledger" that keeps evidence preserved.

(3) providing verification capabilities downstream so a client can verify the integrity of the artifact(s) from the ledger before installing / running the artifact(s).

Compliance Assessment

Xygeni checks compliance of your software with Software Supply-Chain Security Standards and Guidelines.

Each standard is composed of a set of checkpoints that are checked against the software project under analysis.A checkpoint belongs to a category, and could be required or optional.The result tells us if the project complies with the standard, with a compliance level.

TBD

Suspect Deps Detectors

Suspect Dependencies Detectors

See and

See and, more specifically, for instructions on how to execute an Open Source scan.

Xygeni provides the infrastructure for generating software attestations in the software pipelines and verifying them downstream when needed. See for further information.

See

Xygeni runs on software projects and DevOps tools for compliance assessment, under standards and guidelines like OpenSSF Scorecard or CIS Software Supply Chain Security or , among others.

See for more information.

Please read the documentation on the .

CI/CD Misconfigurations Detection
CI/CD Misconfigurations
CI/CD Misconfigurations Scanner
Scan with Xygeni CLI
Xygeni CI/CD Scanner
About Build Security
Build Security
automated audits
supported standards
available
Dependencies detectors

CI/CD Security User Interface Guide

CI/CD Security web UI

Supply Chains Security web UI can be accessed from the Navigation Bar under the Supply Chain Section.

Supply Chain section contains the following subsections:

Build Attestations

The Build Security page offers a thorough overview of your project's build process integrity.

You can reach the Build Security page by selecting Build Security in the Navigation Bar.

The top chart shows the timeline frequency for the number of Valid, Invalid, and Unverifiable

The table below displays attestations filtered by your selections.

In the detail slide you can view details about the running environment context of the build, details about the artifact produced in that build as well as a link to the build.

CI/CD Details

CI/CD Statistics

The CI/CD statistics view provides a comprehensive view of all your project(s) CI/CD risks.

You can reach the CI/CD statistics view selecting selecting the top-right statistics tab of the CI/CD Security page

Statistics

Secrets' Statistics view shows:

  • Charts for # of issues by severity, by type and by type & severity

  • A table with the issues (as well as a filter for the table)

You can use filters to select specific issues:

  • By severity

  • By issue type

  • By project (pattern)

  • By issue status (open, confirmed, muted, etc)

  • By tag

  • etc.

Prioritization funnel

The Prioritization funnel view shows default CI/CD funnel.

CI/CD Scanner

Table of Contents

Purpose

A CI/CD misconfiguration in any element of the software pipeline, like a package manager, a build file, or a CI job, might open the door to attacks targeted at the organization’s DevOps chain.

The CI/CD misconfigurations Scanner is a tool that checks the configuration of the software project under analysis, and reports any misconfiguration currently active for the policy assigned to the project. Detected misconfigurations could be uploaded to Xygeni platform for consolidation and for enabling response actions.

Handling findings

Fixing a misconfiguration issue often requires changes not only in a tool configuration, but also in the activities of the software development process. The detector documentation provides a Mitigation / Fix section that describes the recommended actions.

Quick Start

For detecting CI/CD misconfigurations found in software project with sources in current directory, the command:

uploads the result to Xygeni platform.

CI/CD Misconfigurations scanner can be launched in two different ways:

1.- By its own specific command ( xygeni iac[options] )

2.- By the general command ( xygeni scan --run="iac" [options] )

For exporting the most important misconfigurations to CSV for review, or importing the findings into another tool:

Usage

The CI/CD Misconfigurations Scanner is launched using the xygeni misconf [options] command.

For a full reference of all the available option, you can issue :

The most important properties are:

  • Name of the project, -n or --name.

  • Input, either a directory (-d|--dir) or a repository (-repo|--repository). If none is given, the local current directory is assumed.

  • 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.

  • The detectors to run could be tailored with the --detectors / --skip-detectors options. A common use-case is to consider only issues with high or critical severity with --detectors=high.

SCMs and CI/CD misconfigurations scanning

The CI/CD scanner performs checks against your SCM and CI/ CD systems to recover information about your repository and organization to validate if there are misconfigurations affecting them.

It is important to provide tokens with the corresponding permissions to allow the scanner to collect the data needed for analyses. If tokens are not provided, the scanner will not be able to assess your repository/organization.

: All the CI/CD security issues at a glance.

Please visit the documentation for further information.

Clicking on the icon of each attestation will allow you to download the attestation.

Clicking on the icon of every attestation will open a slide with detailed information of the attestation.

By Funnel Phase (see )

In the issues table, by clicking on the icon of any issue, you will see the details of the issue.

See for further details

Please see for further information.

Risks (CI/CD)
Build Security
xygeni misconf -n MyProject --upload
xygeni misconf -n MyProject --detectors critical \
            --format csv --output MyProject.misconfs.csv
xygeni misconf --help
Configuration options:
  -c, --conf=<config>        Configuration file (default: xygeni.
                               misconfigurations.yml).
      --[no-]conf-download   Download scanner config? (default: true}
      --detectors=<detectors>
                             Comma-separated list of IDs for detectors to run,
                               PRIORITY or 'all'
      --skip-detectors=<skipDetectors>
                             Comma-separated list of IDs for detectors to
                               ignore, or PRIORITY
      --custom-detectors-dir=<customDetectorsDir>
                             Directory with custom detectors.
Prioritization Funnels
Prioritization Funnels
Configuration
SCM, CI/ CD and Container Registry tokens
Purpose
Handling Results
Quick Start
Usage
Detectors

CI/CD Misconfigurations Scanner Configuration

CI/CD Misconfigurations Scanner Configuration

The CI/CD Misconfigurations Scanner is configured in the YAML file conf/xygeni.misconfigurations.yml.

CI/CD Detectors Configuration

Detectors are configured with different YAML files located under the conf/misconfigurations directory of the xygeni scanner. There is a sample _template.yml_ file that could be used for creating your own detectors.

To avoid scanner updates overwriting your configurations, you may define a directory where custom detectors could be loaded with the --custom-detectors-dir command-line argument.

CI/CD Misconfigurations Detectors

Please read the documentation on .

CI/CD misconfigurations detectors available
Security Standards and Guidelines

Compliance Scanner

Quick Start

Run a compliance assessment on the project in current directory, using Xygeni Scanner:

xygeni compliance -n MyProject

which produces an output similar to this:

Stop software supply-chain attacks!               xygeni.io

Running xygeni...
2022-11-09 11:52:09.815 [main] INFO  Xygeni - Start xygeni
2022-11-09 11:52:35.002 [main] INFO  ComplianceEngine - Checkpoints terminated. Duration = 0.000112221s
2022-11-09 11:52:35.008 [main] INFO  ComplianceEngine - Analysis complete in 24.180512222s

Compliance for cis_sscs standard: non-compliant (2.67)
Checkpoints run: 13
┌───────────────────────────────────────┬───────┬─────┬────────┬────────────────────────────────┬───┐
│Checkpoint                             │Status │Level│Severity│Category                        │Op?│
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/branch_deletions_denied       │ fail  │  0  │critical│source_code/code_changes        │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/code_in_vcs                   │ fail  │  0  │critical│source_code/code_changes        │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/force_push_denied             │ fail  │  0  │critical│source_code/code_changes        │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/identity_verified             │ fail  │  0  │critical│source_code/contribution_access │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/minimum_approvals             │ fail  │  0  │critical│source_code/code_changes        │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/anonymous_access              │  ok   │ 10  │critical│artifacts/access_to_artifacts   │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/contain_security_md           │  ok   │ 10  │critical│source_code/repository          │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/minimum_admins_org            │  ok   │ 10  │critical│source_code/contribution_access │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/package_hooks                 │  ok   │ 10  │critical│artifacts/package_hooks         │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/inactive_users                │  ok   │ 10  │  low   │source_code/inactive_users      │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/steps_as_code                 │  ok   │ 10  │  low   │build_pipelines/pipeline_instruc│   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/package_org_mfa               │  na   │  0  │critical│artifacts/package_org_mfa       │   │
├───────────────────────────────────────┼───────┼─────┼────────┼────────────────────────────────┼───┤
│cis_sscs/inactive_branches             │unknown│  0  │  low   │source_code/code_changes        │   │
└───────────────────────────────────────┴───────┴─────┴────────┴────────────────────────────────┴───┘

You may now log in the Xygeni Dashboard and view the Compliance Assessment results.

Purpose

Compliance Assessment checks compliance with Software Supply-Chain Security standards and guidelines.

A standard is a list of checkpoints, arranged in categories. A software project is compliant with a standard ("passes") only when all the standard’s required checkpoints passed.

Checkpoints could be optional. Optional checkpoints are reported, but they do not alter the compliance status. Non-optional checkpoints, on the other hand, are required for compliance with the standard.

The assessment report gives a status (PASS, PARTIAL, FAIL) and a compliance level between 0 (not compliant at all) and 10 (fully compliant).

Standards

Handling results

Remember that for a standard to pass, all its required checkpoints must pass.

A non-compliant checkpoint could be verified following its documented Verification section, and made compliant by following the recommended actions in the Remediation section.

Usage

A Compliance Assessment scan is launched using the compliance command of the xygeni executable.

With --help the usage is displayed:

xygeni compliance --help

Usage:

xygeni compliance [-huV] [-n=<name>]
  [-s=<standard>]
  [-d=<directory>] [-e=<excludePatterns>] [-i=<includePatterns>]
  [--[no-]all-files]
  [-repo=<repo>] [--repo-branch=<repoBranch>]
  [-o=<output>] [-f=<format>]... [--report-columns=<cols>]
  [-c=<config>]
  [--checkpoints=<checkpoints>] [--skip-checkpoints=<checkpoints>]
  [--custom-standards-dir=<customStandardsDir>] [--[no-] conf-download]]
  [--never-fail | --fail-on=<failOnInput>]
  [@<filename>...]


Check compliance with supply-chain standards.

Parameters:
      [@<filename>...]       One or more argument files containing options.
  -n, --name=<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=<directory>      The directory to analyze (default: current
                               directory).
  -i, --include=<includePatterns>
                             Include patterns, comma-separated (optional).
  -e, --exclude=<excludePatterns>
                             Exclude patterns, comma-separated (optional).
                               Example: '**/test/**'
      --[no-]all-files       Scan all files (the default). With --no-all-files,
                             scan tracked files under git only.

Repository options:
      -repo, --repository=<repo>
                             The repository. Either a URL or scm:owner/repo,
                             like 'github:tensorflow/tensorflow'
      --repo-branch=<ref>    The repository branch or commit SHA to checkout for analysis.
                             HEAD if unspecified.

Repository options:
  -repo, --repository=<repo> The repository. Either a URL or scm:owner/repo, like
                             'github:tensorflow/tensorflow'
  --repo-branch=<repoBranch> The repository branch or commit SHA to checkout for
                             analysis. HEAD if unspecified.

Output options:
  -o, --output=<output>      Output file. Use 'stdout' or '-' for standard
                               output, 'stderr' for standard error.
  -f, --format=<format>      Output formats: none, text, json, csv, sarif.
      --report-columns=<reportColumns>
                             Report columns, separated by commas (default:
                               config property report/columns)

Configuration options:
  -s, --standard=<standard>  ID of the standard to check (default from config file).
  -c, --conf=<config>        Configuration file (default: xygeni.compliance. yml).
      --checkpoints=<checkpoints>
                             Comma-separated list of IDs for checkpoints to run.
                             Alternatives: severity:SEV, category:CAT, tag:TAG or 'all'
      --skip-checkpoints=<checkpoints>
                             Comma-separated list of IDs for checkpoints to ignore.
                             Alternatives: severity:SEV, category:CAT or tag:TAG
      --custom-standards-dir=<customStandardsDir>
                             Directory with custom standards and checkpoints.
      --[no-]conf-download   Download scanner config? (default: true}

Exit options:
      --never-fail           Do not fail: always exit with code 0, even with
                               non-compliant checkpoints.
      --fail-on=<failOnInput>
                             Comma-separated list of detector IDs, SEVERITY or GUARDRAIL (expression, file or server reference) that will force a non-zero exit code.
                             Examples:
                               --fail-on 'critical'
                               --fail-on 'guardrail secret-policy on secrets when severity >= high then @exitcode(127)'
                               --fail-on 'file:path-to/my-guardrail.xyflow'
                               --fail-on '#my-guardrail'

Configuration

$XYGENI_HOME denotes here the path where the Xygeni scanner is installed.

The Compliance Assessment Scanner is configured in the YAML file $XYGENI_HOME/conf/xygeni.compliance.yml:

# Configuration for the xygeni compliance scanner

# This is the default standard to use. Overridden by -s/--standard command line argument.
standard: cis_sscs
#standard: openssf_scorecard

# List of checkpoint specs.
# A checkpoint spec is either a checkpoint ID, or a prop:value pair,
# where prop is one of severity, category or tag.
# Leave empty for no restriction (all checkpoints in requested standard and not disabled will be chosen).
# Examples:
#   runCheckpoints: ['openssf_scorecard/binary_artifacts']
#     will run that single checkpoint (when in the chosen standard).
#   runCheckpoints: ['check-01', 'check-02', 'category:branch-protection']
#     will run two explicit checkpoints, plus all in the 'branch-protection' category.
#   runCheckpoints: ['severity:critical', 'severity:high']
#     Will run all checkpoints in the chosen standard with critical or high severity.
# Command-line property --checkpoints overrides this.

# List of checkpoints to run: A list of individual checkpoint IDs, or groups of checkpoints
# given as 'severity:SEV', 'category:CAT' or 'tag:TAG' could be used.
# runCheckpoints: [ 'severity:high', 'category:' ] will run all checkpoints with severity 'high' or greater.
# runCheckpoints: ['openssf_scorecard/binary_artifacts'] will run just that one.
# Command-line property --checkpoints overrides this.
runCheckpoints: []

# Same format as runCheckpoints, but for skipping the selected checkpoints.
# Command-line property --skip-checkpoints overrides this.
skipCheckpoints: []

# The directory containing YAML files for custom standards and checkpoints.
# Leave it null for no default. The --custom-standards-dir command-line argument overwrites this.
customStandardsDir: null

# scanMode: sequential|parallel
mode: sequential

# Includes: list of glob patterns to include in analysis.
includes: []

# Excludes: list of glob patterns to exclude from analysis.
excludes:
  - ".git/**/*"
  # ...
  - "**/.xygeni.*.baseline.json"

report:
# ...

Standards are configured with different YAML files located under the $XYGENI_HOME/conf/compliance/standards directory of the xygeni scanner. Each standard provides some information and the list of checkpoints that are to be checked for compliance assessment.

Checkpoints are configured with different YAML files located under the $XYGENI_HOME/conf/compliance/checkpoints directory of the xygeni scanner.

A custom standard may include checkpoints taken from different standards, if desired.

To avoid scanner updates overwriting your configurations, you may define a directory where custom standards and checkpoints could be loaded with the --custom-standards-dir command-line argument.

How to…​

This section presents common use-cases for evaluating compliance against a given supply-chain security standard across the software lifecycle.

Exclude certain checkpoints from a standard assessment

A common use case is to disable issues with info / low severity (--skip-checkpoints=low) or equivalently enabling only high or critical issues (--checkpoints=high).

Add compliance assessment as a git hook

a) Direct registering script as a git hook

To run Xygeni scanner at client-side, before a commit is applied, you may add a simple pre-commit executable script like this (example for Linux and macOS):

#!/usr/bin/env bash

RED='\033[1;31m' # Bold red
GRAY='\033[1;90m' # Bold gray
NC='\033[0m' # No Color

# Add Xygeni scanner location to the PATH (if not in PATH already)
PATH=${PATH}:${XYGENI_HOME}

if ! [ -x "$(command -v xygeni)" ]
then
    echo -e "${RED}Xygeni scanner could not be found.${NC} Please make sure Xygeni is installed properly.\nDocumentation can be found here: https://docs.xygeni.io/scanner/xygeni_scanner.html#_installation"
    exit 1
fi

# Run secrets scan on the files changed in the commit ("staged") only
# "no new secrets of high+ severity":
xygeni -q secrets -d . --staged-files --fail-on=high --no-stdin --format text --output ./.secrets.txt
EXIT_CODE=$?

if [[ $EXIT_CODE -gt 127 ]]; then
  # Print secrets found if anu
  echo -e "${RED}Secrets found !${NC} Please remove them before committing changes."
  cat ./.secrets.txt
elif [[ $EXIT_CODE -ne 0 ]]; then
  echo -e "${RED}Xygeni scan failed.${NC} Please contact your Xygeni administrator."
  echo -e "Log files can be found in ${GRAY}logs/noproject/secrets_noproject.log${NC}"
fi

# Cleanup and tell the git commit to stop (not 0) or continue (0)
rm -f ./.secrets.txt >/dev/null 2>&1
exit $EXIT_CODE

The --fail-on option is configured to make the build fail when at least one issue with critical or high severity is found (so the scanner acts as a security gate).

For running the scan as an optional pipeline check, use --fail-on=never instead.

The --no-stdin option is recommended to avoid the scanner to get the files to process from the standard input. Under some environments, this could make the scanner to analyze no files at all.

This example is a similar security gatekeeper, but commits are allowed only when no scan of the given types has a critical issue (only the scanner execution is shown, for brevity):

#!/usr/bin/env bash

${XYGENI_HOME}/xygeni scan --fail-on=critical --no-upload --run=secrets,misconf,iac \
  --format=text --output=.report.txt

When a critical issue is detected in any of the scans for secrets, misconfigurations or IaC flaws, the commit will be aborted.

Use compliance command to limit the scope of the scan to compliance assessment.

b) Using pre-commit framework

There are some popular frameworks for improving the hook mechanism provided by Git, mainly aimed at sharing the scripts and simplifying the configuration when multiple actions need to be added for a git event.

Then add the following entry to you .pre-commit-config.yaml:

# ... Other configuration properties ...
repos:
  # ... more repos and hooks ...

  - repo: https://github.com/xygeni/xygeni-action
    rev: v2.1
    hooks:
    - id: xygeni
      stages: [commit]
      args: [
        '-q', 'scan', '--format=text',
        '--run=secrets,suspectdeps,misconf,iac,codetamper,compliance',
        '--fail-on=critical'] 

Scan configuration with the args property.

Or, for running the scanner Docker image:

- repo: git://github.com/xygeni/xygeni-action
  rev: v1.2
  hooks:
  - id: xygeni-docker
    stages: [commit]
    args: [
      '-q', 'scan', '--format=text',
      '--run=secrets,suspectdeps,misconf,iac,codetamper,compliance',
      '--fail-on=critical']

Then install the git hook scripts using

# You may test the hook configuration with
#   pre-commit try-repo or pre-commit run
pre-commit install

Xygeni scanner will run before each commit. The configuration given above works for setting Xygeni as a security gate to avoid commits having critical security issues. To avoid break the builds, --fail-on=never could be used instead.

git commit -m "this commit contains issues!"

  Running xygeni (script) scan ........Failed!
  ...

To disable the pre-commit hook, for example when after analysis the findings found were deemed as false positives or on inactive / no-risk issues, use SKIP=xygeni in front of the git command: ---

SKIP=xygeni git commit -m "this commit contains issues!"
    xygeni SKIPPED...

Use compliance command to limit the scope of the scan to compliance assessment.

Add compliance assessment to a CI step

You may use compliance results to block a commit.

jobs:
  xygeni-scan:
    runs-on: ubuntu-latest
    name: xygeni-github-action
    steps:
      # Checkout the repository sources (GITHUB_WORKSPACE)
      - name: Checkout
        uses: actions/checkout@vv3.1.0
        fetch-depth: 0

      # Other steps (not shown)

      # Security gate checking compliance with CIS SSCS standard
      # Build fails when any critical checkpoint in standard FAILs
      - name: Xygeni-Scanner
        uses: xygeni/xygeni-action@v1.0.0
        id: Xygeni-Scanner
        with:
          token: ${{ secrets.XYGENI_TOKEN }}
          run: compliance
          fail_on: 'severity:critical'
          standard: cis_sscs

The fail_on is configured to make the build fail when at least one critical checkpoint do not pass. For having the compliance check as optional, use fail_on: never instead.

Define a custom standard

# My Software Supply-Chain Security standard
id: my_new_standard

description: >-
  The XYZ standard provides prescriptive guidance for establishing
  a secure configuration posture for Software Development Platforms and Pipelines.

url: https://...

checkpoints:
  - ID_CHECKPOINT_1
  - ID_CHECKPOINT_2
  # ...

Where ID_CHECKPOINT_1, ID_CHECKPOINT_2…​ are the checkpoint identifier. The configuration for each checkpoint is loaded from <custom-standards-dir>/<ID_CHECKPOINT>.yml file, if available, or from a resource loaded from compliance/checkpoints/<ID_CHECKPOINT>.yml path.

Command-line example:

xygeni -q compliance -n NAME -d DIR --format=text --output=stdout --upload \
  --standard=my_standard --custom-standards-dir=$XYGENI_HOME/conf/compliance/my_standards

Secrets Security

Block Secrets Leakage at All Stages of Development

Robust defense against secret leakage within the software development lifecycle. Xygeni advanced solution scans, detects, and blocks the publication of sensitive information such as passwords, API keys, and tokens in real-time.

Xygeni Secrets Security acts as your reliable protector, designed to prevent the leakage of critical secrets like passwords, API keys, and tokens. As cyber threats constantly evolve, it’s vital to have a solution that not only detects but actively prevents leakages before they lead to a breach. Xygeni enables your teams to work with confidence, ensuring that your development secrets are kept secure. Adopt Xygeni’s proactive approach and transform your security strategy into a strong asset that builds trust and supports business continuity.

Comprehensive Secret Detection

Xygeni Secrets Security uses sophisticated scanning algorithms to identify over 100 types of secrets with unparalleled accuracy meticulously. Our integration with Git hooks allows for seamless detection and immediate remediation, embedding essential security practices directly into your developers’ workflows.

Real-Time Protection and Instant Feedback

By integrating with development processes via Git hooks, Xygeni Secrets Security offers an immediate line of defense. If secrets are detected before committing to repositories, the process is halted, and developers are guided to secure the exposed data. This proactive approach prevents secrets from entering version history, which can be challenging to fully remove.

Intelligent Validation and Alert Management

Our intelligent validation process effectively differentiates real threats from false positives, reducing ‘alert fatigue.’ This precision ensures that developers receive notifications only for genuine vulnerabilities, promoting a culture of swift and accurate security responses.

Tailored Secret Detection

Central to Xygeni’s strategy is the ability for customers to customize secret detectors, allowing the definition of specific secret patterns and their locations. This tailored approach ensures that the detection of secret leakage is perfectly aligned with your unique business requirements.

Empower Developers with Actionable Insights

Xygeni’s non-intrusive tools enhance the developer experience by providing actionable insights through an intuitive WebUI. Developers receive immediate guidance on handling and remediating identified secrets, fostering a secure development culture, and enabling real-time learning and adoption of best practices.

Unmatched Efficiency and Cost Effectiveness

Xygeni’s systematic risk assessment and prioritization of key vulnerabilities allows teams to focus only on the most critical secrets, reducing unnecessary remediation efforts. Early detection capabilities accelerate remediation, reducing time and costs and preventing expensive impacts of security breaches in production.

Comprehensive Protection Across Platforms

API Tokens and Keys

  • Detection of diverse API tokens and keys, including Amazon MWS Tokens, Alibaba Cloud Keys, Artifactory API Keys, and Azure Personal Access Tokens.

  • Coverage extends to service specific tokens such as GitHub tokens, GitLab Personal Access Tokens, and Google API Keys.

OAuth and 2 Access Tokens

  • Comprehensive scanning for OAuth tokens and other access tokens such as Facebook App Keys, Google OAuth2 Keys, and Slack Access Tokens.

  • Specialized detectors for platform-specific OAuth implementations like Atlassian OAuth2 Client Secrets and Bitbucket OAuth Access Tokens.

Cloud Provider Credentials

  • Detectors for credentials specific to major cloud providers like AWS, Azure, and Google Cloud, including Google Cloud Service Account Keys and Azure Storage Access Keys.

  • Includes detection for less common providers like IBM Cloud and Tencent Cloud.

Cryptographic Keys

  • Identification of cryptographic private keys, including general cryptographic keys and specific formats like Cryptographic Private Key Putty

Database and Data Storage Credentials

  • Scanning for credentials across various database systems such as MySQL, PostgreSQL, and Redis.

  • Detection of other data storage related secrets like RabbitMQ Passwords and LDAP Credentials

Miscellaneous Credentials

  • Detectors for credentials specific to major cloud providers like AWS, Azure, and Google Cloud, including Google Cloud Service Account Keys and Azure Storage Access Keys.

  • Includes detection for less common providers like IBM Cloud and Tencent Cloud.

  • Broad coverage for other types of secrets, such as SSH Passwords, SMTP assignments, and credentials embedded in configuration files like Maven pom.xml or .htpasswd

Supported compliance standards

CIS Software Supply Chain Security benchmark

CIS Benchmarks are best practices for the secure configuration of a target system. In this case, the target system is the software supply chain.

OWASP Software Component Verification Standard

The Software Component Verification Standard (SCVS) is a community-driven effort to establish a framework for identifying activities, controls, and best practices, which can help in identifying and reducing risk in a software supply chain.

OpenSSF FLOSS

The best practices criteria are divided into three levels, for an incremental adoption:

  • Passing focuses on best practices that well-run FLOSS projects typically already follow. Getting the passing badge is an achievement; at any one time only about 10% of projects pursuing a badge achieve the passing level.

  • Silver is a more stringent set of criteria than passing but is expected to be achievable by small and single-organization projects.

  • Gold is even more stringent than silver and includes criteria that are not achievable by small or single-organization projects.

OpenSSF Scorecard

ESF Securing the Software Supply Chain DEV

The set of recommended principles are framed in 5 top-level sections:

  • Secure product criteria and management

  • Develop Secure Code

  • Verify Third-Party Components

  • Harden the Build Environment

  • Deliver Code

By following these guidelines, software developers can reduce the risk of supply chain attacks and ensure the security and integrity of their software.

See for more details.

You might use the tool for editing standards to be enforced at the organization.

There could be certain checkpoints that should not be run for a certain project, or because the practice enforced by the checkpoint does not fit with the organization policy. The list of checkpoints that should be active for a standard to enforce, according to the organization policy, could be set in the in Xygeni Administration.

Disabling checkpoints could be done, in order of prevalence: - by disabling the intended checkpoint(s), listing their IDs in the --skip-checkpoints option. - with the runCheckpoints / skipCheckpoints properties in the scanner YAML. - at the level, - by deactivating the checkpoint at the central configuration level (e.g. by setting enabled: false in the checkpoint YAML configuration).

One of the most popular frameworks is . The list of actions required are listed in a YAML file, and `pre-commit manages the installation and execution of scripts written in any language.

Follow the instructions given in for installing the framework. Essentially you need python and pip, and run pip install pre-commit in the node where the git commit will be intercepted.

Under GitHub, you may use , running the compliance command only, and with fail_on argument configured to fail the build only when important checkpoints do not pass:

A new standard may be created from by simply listing the new standard’s checkpoints in `$XYGENI_HOME/conf/compliance/standards/<my_new_standard>.yml:

The easiest way to define your own standard is using the . This allows to mix-and-match checkpoints from different standards into a new one, possibly changing checkpoint severities and its _optional flag.

An alternative option is to create your standard’s my_standard.yml file, located in a specific $XYGENI_HOME/conf/compliance/custom_standards directory, testing it, and then upload the configuration using the .

See and for further information

The provides prescriptive guidance for establishing a secure configuration posture for Software Development Platforms and Pipelines.

Visit for further details on checkpoints evaluated by Xygeni.

Visit for further details on checkpoints evaluated by Xygeni.

The is a set of recommendations from the Open Source Security Foundation (OpenSSF) to help open source developers create and maintain more secure software.

Visit for further details on checkpoints evaluated by Xygeni.

is an automated tool that assesses a number of important heuristics ("checks") associated with software security and assigns each check a score of 0-10. You can use these scores to understand specific areas to improve in order to strengthen the security posture of your project. You can also assess the risks that dependencies introduce, and make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.

Visit for further details on checkpoints evaluated by Xygeni.

The is a set of guidelines aimed at improving the security of software development by reducing the risk of supply chain attacks.

Visit for further details on checkpoints evaluated by Xygeni.

supported standards and guidelines
Policy Administration
Policy page
policy
pre-commit
pre-commit quick start
Xygeni GitHub Action
existing standards
Policy Administration
Secrets Security Web UI
Secrets Scanner
CIS Software Supply Chain Security benchmark
CIS Software Supply Chain Security benchmark
OWASP Software Component Verification Standard
OpenSSF FLOSS Best Practices
Best Practices Working Group
OpenSSF FLOSS Best Practices Badge
OpenSSF Scorecards
OpenSSF Scorecards
ESF Securing the Software Supply Chain - Recommended Practices for Developers
ESF Securing the Software Supply Chain. Recommended Practices for Developers
Generate Token for Scanner and API client

Secrets Scanner

Purpose

A secret refers to any confidential and sensitive information that must remain secure. This encompasses passwords, API keys, cryptographic keys, tokens, and other credentials used for authentication or authorization. Additionally, secrets may include various forms of sensitive data, such as financial or medical records, personally identifiable information (PII), or intellectual property.

Leaked secrets in version-controlled software projects pose serious security risks to its owners and to projects depending on it.

Secrets gained by bad actors are the cause of major attacks to the software supply chain. Having hardcoded secrets in software source code or configurations, particularly when under source control, is an invitation for bad actors to gain access to organization’s sensitive resources.

Accidentally hard-coding a secret (imagine a JWT token, a production database password, or AWS credential) is easier than you may think. During development the secret is used for testing, but the secret is not removed and a bad .gitconfig makes the secret entering git: One git push, and it is too late.

If important secrets like credentials, API keys, access tokens or cryptographic keys are exposed, bad actors can use them to extract sensitive information, insert malware, move laterally into the victim organization, or even modify source code, binaries or DevOps configurations and scripts to launch supply-chain attacks. Attackers may use your cloud resources to run crypto miners and other nasty things. In short, a single commit with an unintended secret throws the key for the bad guys to come in.

Xygeni Secrets detects hardcoded secrets. Xygeni Secrets performs thorough scans of code, text files and docker images to identify exposed secrets (API keys, passwords, and other sensitive credentials). Such exposures can be exploited by malicious actors to leak data or gain unauthorized access to critical systems.

Xygeni Secrets allows you to determine:

  • What secrets have been committed to your repository.

  • Scan your repository's history thoroughly for hidden secrets. Enable continuous historical scanning to detect and identify valid secrets throughout your Git history effectively. Protect your repository from vulnerabilities by maintaining robust secret detection practices.

  • The validation status of the secret; for example, valid secrets are those that have been tested against a service and confirmed to successfully grant resources or authentication.

Xygeni Secrets saves security engineers time and effort by prioritizing valid leaked secrets and informs developers of valid secrets in their PRs and MRs by posting comments directly.

Once Xygeni Secrets detects a hardcoded secret, it obfuscates the secret before logging it or sending it to the Xygeni platform, ensuring the secret isn't exposed in its output.

Main Functionalities

  • Detection of Committed Secrets: Identify secrets already in your repositories, at both repository- and organization-level.

  • Pre-Commit Secret Blocking: Prevent secrets from being added to your repositories.

  • Comprehensive Git History Scanning: Examine your repository's entire git history for hidden secrets.

  • Secret Validation: Confirm the validation status of secrets to ensure they grant access or authentication.

  • Docker images scanning: Identify secrets in your docker images

Secrets scanner execution

Secrets scanner can be executed in two different ways:

1.- By its own specific command ( xygeni secrets [options] )

2.- By the general command ( xygeni scan --run="secrets" [options] )

xygeni secrets admites more configuration parameters than xygeni scan.

Although most of the functionalities of secrets scanning are available in either of those modes, advanced functionalities are only available by using the xygeni secrets

Xygeni secrets operation modes

Xygeni secrets has different operation modes depending on the scope of the scan.

Results upload

An important difference is that when using xygeni secrets the results will not be uploaded by default to Xygeni servers. Instead, using xygeni scan --run="secrets" the result will be uploaded by default.

If you want xygeni secrets to upload the results, use xygeni secrets --upload

If you don't want xygeni scan to upload the results, use xygeni scan --no-upload

Operations (--scan, --diff, --history)

xygeni secrets has three different modes of operation:

Operations available:
      --scan                 Scan for secrets (default operation).
      --diff                 Scan for secrets, reporting diffs from baseline.
      --history              Scan for secrets in git history.

--scan

The default operation mode is --scan (i.e. scan for secrets), you don't need to explicitly specify it.

By executing xygeni secrets , the scanner creates a "baseline", i.e. a file (.secrets.baseline.json) with the results of the secrets scanning.

--diff

Let's imagine now that, after running the scanner over a directory, you modify the contents of the source directory and want to know the differences between them. If this is your case, you may run xygeni secrets --diff to know it, i.e. this command will show to you the differences between them.

For example, imagine that we run xygeni secrets over a source directory. Such command will find the secrets and saves the baseline.

2024-07-31 08:59:08 INFO  Xygeni-Scanner - Secrets baseline saved to file: C:\LGV\src\Secrets\secrets_local\.xygeni.secrets.baseline.json

Secret leaks found: 9
┌────────┬────────────┬────────────────┬───────────────┬────────────┬────────────────┬────┬────────┐
│Severity│    Type    │Secret          │Key            │  Detector  │File            │Line│Tags    │
├────────┼────────────┼────────────────┼───────────────┼────────────┼────────────────┼────┼────────┤
│critical│github_token│ghp_PPAuLz***...│               │github_token│org_scan.bat    │4   │verified│
├────────┼────────────┼────────────────┼───────────────┼────────────┼────────────────┼────┼────────┤
│critical│gitlab_token│glpat-DNE_***...│valid1         │gitlab_token│src/AddPage.java│41  │verified│
├────────┼────────────┼────────────────┼───────────────┼────────────┼────────────────┼────┼────────┤
│  high  │gitlab_token│glpat-sPSs***...│invalid        │gitlab_token│src/AddPage.java│48  │inactive│
├────────┼────────────┼────────────────┼───────────────┼────────────┼────────────────┼────┼────────┤
│  high  │gitlab_token│glpat-EAs2***...│valid3_torevoke│gitlab_token│src/AddPage.java│51  │inactive│
├────────┼────────────┼────────────────┼───────────────┼────────────┼────────────────┼────┼────────┤
│  high  │    jwt     │xya_eyJhbG***...│valid3         │xygeni_token│src/test.py     │6   │verified│
├────────┼────────────┼────────────────┼───────────────┼────────────┼────────────────┼────┼────────┤
│  low   │    jwt     │eyJzdWIiOi***...│invalido       │    jwt     │src/test.py     │4   │inactive│
├────────┼────────────┼────────────────┼───────────────┼────────────┼────────────────┼────┼────────┤
│  low   │    jwt     │eyJzdWIiOi***...│valid3         │    jwt     │src/test.py     │6   │inactive│
├────────┼────────────┼────────────────┼───────────────┼────────────┼────────────────┼────┼────────┤
│  low   │    jwt     │xya_eyJhbG***...│valid4_toexpire│xygeni_token│src/test.py     │7   │inactive│
├────────┼────────────┼────────────────┼───────────────┼────────────┼────────────────┼────┼────────┤
│  low   │    jwt     │eyJzdWIiOi***...│valid4_toexpire│    jwt     │src/test.py     │7   │inactive│
└────────┴────────────┴────────────────┴───────────────┴────────────┴────────────────┴────┴────────┘

Next, we modify the source code introducing a new secret. If we execute xygeni secrets --diff , the scanner will show up the differences with the baseline (i.e. one new secret introduced)

Secret leaks found: 1
┌────────┬────────────┬────────────────┬───────┬────────────┬────────────────┬────┬────────┐
│Severity│    Type    │Secret          │Key    │  Detector  │File            │Line│Tags    │
├────────┼────────────┼────────────────┼───────┼────────────┼────────────────┼────┼────────┤
│critical│gitlab_token│glpat-PFdC***...│comment│gitlab_token│src/AddPage.java│45  │new     │
│        │            │                │       │            │                │    │verified│
└────────┴────────────┴────────────────┴───────┴────────────┴────────────────┴────┴────────┘

--history

Finally, the third operation mode is --history. By using history mode of operation, secrets scanner will search for secrets in the whole git history. This option allows you to discover secrets that are hidden into the git commit history and, being valid, could be discovered by anyone with access to the repository. Those secrets found in git history as tagged as history so you can easily differentiate them.

Searching secrets under Git (--history, --all-files, --staged-files)

There are certain parameters related to git that you should take in mind.

Below command only works with Git version control systems.

--history

By using history mode of operation, secrets scanner will search for secrets in the whole git history. This option allows you to discover secrets that are hidden into the git commit history and, being valid, could be discovered by anyone with access to the repository. Those secrets found in git history as tagged as history so you can easily differentiate them.

To detect secrets leaked in any branch, for each commit in the project history, you may use the --history operation. This will analyze all the changes, for identifying when the secret was leaked for investigation of an incident related to a secret leakage.

xygeni secrets --history -n "TEST"

As the history log could be huge for large projects, you may filter by branch or by commit range, if you know approximately where the secret could be located.

--all-files

By default, if the source directory is under git, secrets scanner will search for secrets only in files tracked under git. Those untracked will not be scanned.

      --all-files            Scan ALL files. The default is to scan tracked
                               files only if under git.

By using --all-files, the scanner will search for secrets in all the files, regardless are tracked or untracked.

--staged-files

If you want to scan only the stagged files (i.e. only those modified but not committed yet) you can use the --staged-files and the scanner will only search for secrets in tracked but uncommitted files.

      --staged-files         Scan staged files (marked for commit), if under
                               git. Exits with error if not under git.

Preventing introduction of secrets (git hooks)

Git hooks can be used to prevent secrets to be committed to a git repository.

Secrets Verification

After scanning your codebase, Xygeni Secrets uses a proprietary verifier to determine if a secret is reachable, i.e. if it's valid.

All verifications, such as API calls, are done locally in your environment. No tokens or secrets are sent to Xygeni servers.

  1. The verifier detects the service, such as Slack or AWS, that the secret is used for.

  2. Xygeni Secrets makes an HTTP request using the secret.

  3. If the HTTP request returns an HTTP status code of 200 or similar and some indication of valid access, the issue is flagged as verified.

The verification status is a key point into the severity of the secret. One verified secret logically cannot have the same severity as a not-verified.

A verified secret is a true statement (it's a certainty), Xygeni was able to use the secret to access the resource.

Instead, a not verified secret does not mean that it is not valid, it just states that Xygeni could not verify it by any reason. So be cautious about not-verified secrets.

There are some xygeni secrets parameters that are related to secrets verification :

      --no-verify            Ignore verifications that call to external
                               services.
      --only-verified        Report only verified secrets when there is a
                               verifier available.

Xygeni contains a directory ( conf/secrets ) where every secret detector has a yaml configuration file.

Into every detector config file, there is a section called verifier where its' specified the verifier class, some properties as well as the action.

Below is a sample with a generic verifier (ApiVerifier) that takes as parameters the API host and the authHeaderName to populate with the secret when validating it. Also, you can indicate the action to be done based on verification status.

verifier:
  className: com.depsdoctor.secrets.scanner.detector.verifier.ApiVerifier
  # action: do_nothing | increase_severity_when_verified | 
  #         decrease_severity_when_not_verified | ignore_when_not_verified
  action: decrease_severity_when_not_verified
  properties:
    host: gitlab.com/api/v4/projects
    authHeaderName: PRIVATE-TOKEN

Secrets Remediation

You should consider any sensitive data in commits with secrets as compromised, and the best option is to revoke or invalidate the secret, and remove it from the source code file. Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories.

To remediate the exposure of sensitive data, take the following steps depending on the nature of the secret identified:

  1. False Positive or Expired Secret: If the secret is identified as a false positive or it has no impact, mark it as suppressed in the secret details.

  2. Active Secret: If the secret is valid and active:

    • Revoke/Invalidate: Revoke or invalidate the secret, and remove it from the source code.

    • Check Logs: Inspect logs for any unauthorized, suspicious or unexpected activities from the time the secret was exposed.

Secrets Auto-Remediation

Xygeni provides mechanisms for automatic remediation of hardcoded secrets.

Secrets User Interface Guide

The Secrets page provides a comprehensive view of all your project(s) hidden secrets:

You can reach the Secrets page by selecting the Secrets tab in the Navigation Bar

Statistics

Secrets' Statistics view shows:

  • Charts for # of issues by severity, by type and by type & severity

  • A table with the issues (as well as a filter for the table)

You can use filters to select specific issues:

  • By severity

  • By issue type

  • By project (pattern)

  • By issue status (open, confirmed, muted, etc)

  • By tag

  • etc.

Please note that any detected secret will never be sent to Xygeni servers. Any found secret will be obfuscated previously to be sent to Xygeni.

Prioritization funnel

Secrets' Prioritization funnel view shows default Secrets funnel.

Secrets scanner configuration

Detectors

Configuration

The Secrets Scanner is configured in the YAML file config/xygeni.secrets.yml:

Detectors are configured with different YAML files located under the conf/secrets directory of the xygeni scanner. There is a sample _template.yml_ file that could be used for creating your own detectors.

To avoid scanner updates overwriting your configurations, you may define a directory where custom detectors could be loaded with the --custom-detectors-dir command-line argument.

Secrets Detectors

: a single scan unit (it will correspond to a single Xygeni project)

: multiple scan units (it will correspond to multiple Xygeni projects)

: a whole scm organization's repos (it will correspond to multiple Xygeni projects)

: to scan a docker image

See for furhter information.

See for further info.

A is a custom action that is launched when certain events occur in the Git version control system.

See for further help.

Remove from History: If it cannot be revoked, remove it from the repository history using tools like git filter-repo or BFG Repo-Cleaner. You may follow the procedure listed here for .

Please visit for further information.

By Funnel Phase (see )

In the issues table, by clicking on the icon of any issue, you will see the details of the issue.

See for further details

Please read the documentation on .

Please read the documentation on .

scan
multi-scan
org-scan
docker image scan
Xygeni CLI operation modes
git hook
Git Hooks with Xygeni
GitHub
Secrets Auto-Remediation
Prioritization Funnels
Prioritization Funnels
secret detectors available
Secrets detectors available
Purpose
Main Functionalities
Secrets scanner execution
Xygeni secrets operation modes
Results upload
Operations (--scan, --diff, --history)
Searching secrets under Git (--history, --all-files, --staged-files)
Preventing introduction of secrets (git hooks)
Secrets Verification
Secrets Remediation
Secrets Auto-Remediation
Searching secrets under Git
Project Custom Properties
central configuration
Slack
scan command
Jira
GitHub Issues
GitHub
GitLab
Open Source Remediation Systems
GitHub Alerts
GitHub Status
GitLab Alerts