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

Intro to Xygeni

Xygeni Configuration and Administration

You need a Xygeni account to use Xygeni functionalities.

Create a Free Trial account

Xygeni trial provides a wide set of features to test the platform during 14 days. The sign up process does not gather any payment information and after the trial period no automatic subscription is executed. If the customer does not subscribe, the account is blocked after the period.

2. Choose your preferred signup method.

If you are new at Xygeni and you want to see its capabilities in the easiest way, please follow these steps.

Execute a scan from the Xygeni Web UI (easiest method)

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.

I don't want to scan; only see preloaded results

If you only want to see preloaded results, you can load into your account pre-built results of a demo project that will show you representative examples of issues (this option will not scan any source code).

First Login to Xygeni

• If you were the first user in the organization, you are the main administrator (owner) for your Xygeni organization, with full permissions to create new user accounts, edit projects and setup policies. After creation of Xygeni account, the owner of the account will receive a notification email to setup a new password.

• If you are a new user of an already created Xygeni account, you should have received the same notification email.

Clicking on Set a new password button will redirect you to Reset Password dialog.

The following sections describe the key elements in the Xygeni platform.

After signing up, you will be presented with three options.

"Try out a Demo Project" option allows you to see Xygeni issues with preloaded data, with no need to scan a real repository.

Click on "Try out a Demo Project" and a background process will be started to load demo data.

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

Creating an Integration with your SCM

First, go to Settings >> Managed Scans

Click on New Integration 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, 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!!

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

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

1. Install the Scanner CLI

An installation script is provided for automated installation.

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

The Xygeni installation script is 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 the one of the following which better matches your preferences:

2. Fetch your Xygeni account credentials or API token

An Access Token (also known as 'api token' or 'api key') is used by clients, like the Xygeni Scanner or integrations to access the Xygeni platform 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 enables the client to invoke certain api endpoints. The scanner typically need permissions to upload the scan results.

The token is generated, as shown:

3. Run the installation script

In what follows, XYGENI_TOKEN names an environment variable holding the Xygeni API token that will be registered in the scanner configuration file for authentication with the service.

To get the options available, run ./install.sh --help or PS .\install.ps1 --help.

4. Run your first scan

In its simplest way, you need a file system folder with your project contents (this folder can be a clone of your repo or just a directory with the source code of your project).

Use cd /my/project to change the current directory and run xygeni scan command over the contents your project directory. All vulnerabilities identified are listed, including their path and fix guidance.

You can also use below commands:

5. View the scan results

Subscribe to Xygeni

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

Purchase of your desired plan and daily scans is at Settings > Subscription

Access to Subscribe section

Expand the Settings section of the Menú and click on the Subscription section. The following screen will appear

Subscribe

After selecting your desired subscription information, you will be redirected to an external secure payment platform. Xygeni does not store or manage any payment or private information related to your payments and invoicing.

Once the successful payment is confirmed, the license is updated in our platform and you can use Xygeni as planned.

Introduction to Xygeni

Risk Level

The Risk Level (RL for short) is a quantitative measure of the current risk with software supply chain attacks, and models the security posture of the DevOps system, according to the scans performed by the Xygeni platform.

In the Xygeni Dashboard, Risk Level is shown, along with the variation with respect to projects' current baseline.

RL is a function of the issues found for the project, with range the interval [0, 100], computed at the project level. When a project has no (detected) issues, its RL is zero. Higher values for RL are worse.

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 physically has a set of source files, often grouped as a repository in a Source Code Management (SCM) System.

Remediation Actions

Xygeni detectors' documentation will help you with examples of how to remedy each security issue, and the recommended steps to follow for determining the impact of a security issue and fixing it.

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/fix certain kind of issues.

Steps to address a security incident or vulnerability

Xygeni detectors' documentation will help you with examples of how to remedy each security issue, and the recommended steps to follow for determining the impact of a security issue and fixing it.

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.

Handling Actions in Xygeni Dashboard

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

• Manage Issue: A basic handling workflow, for setting a status

• Create ticket: Opens a new ticket in the configured ticketing tool. Full information for the issue is rendered so the ticket could be created with minimal edition 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 could be added to the branch, for automation, so after review the pull request could 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

Xygeni platform provides a basic handling workflow that helps to trace each issue.

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 real. If you feel that this is a bug, the checkbox "Create false positive ticket for Xygeni" can be enabled, which opens a bug ticket into Xygeni Support.

• 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 by other reasons (to be documented in the notes).

The remediation actions could be invoked from the Remediation Actions popup in the Xygeni Dashboard.

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), just select some issues and click on "Change Status" (please note that Change Status action will only appear when some issue(s) are selected)

Project's Baseline

Every project in Xygeni has a Baseline.

A Baseline is a specific scan of the project considered as the basis for comparison with other scans and mainly used to see evolution of issues in the project.

By default, the baseline of a project is the First scan of the project. Anyway, you can specify a concrete scan as the project baseline.

Standards Compliance

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

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

Each standard is composed of a set of checkpoints that are 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.

SDLC Inventory

Modern software is complex, and the build and deployment infrastructure is accordingly complex.

Software is typically built and deployed into production environments using pipelines of 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 assets involved in build/deploy pipeline are named SDLC assets, and in the Xygeni platform an inventory of SDLC assets, for the pipelines used in an organization, is discovered automatically.

Security issues and unusual activity events, as captured by the Xygeni platform, are then mapped to the target SDLC assets.

An SDLC Asset may present misconfigurations, leaked secrets, vulnerabilities and other security issues, and could be abused in software supply chain attacks. Common assets are code repositories, dependencies graphs, package managers, build files, security tools, CI/CD workflows, or IaC templates and provisioning scripts, along with the infrastructure, tools and extensions (like "plugins") used in the build / deploy pipelines.

Security issues and unusual activity events, as captured by the Xygeni platform, 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.

The scan findings or security issues represent misconfigurations, flaws or anomalies that increase the risk of the software platform being the target of a successful software supply chain attack.

Each issue could be found by a detector, which can be thought as the unit of analysis. Running a set of detectors over the target software project is a scan. Scans for each issue kind can be analyzed separately or in a single run.

The following are the issue kinds 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 uses 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: Source code managers, build tools, package managers and 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 comprises indicators of malicious software (malware) that are discovered analyzing statically the target software. Analyzing software for potential supply chain breach complement software security reviews with automation. And as the adversaries try to hide their changes from human review they use obfuscation techniques that in fact could serve as additional evidence of wrongdoing.

From evidence collected, a maliciousness score for the software under analysis is computed. 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 "evidences" according to malware detectors currently active for the policy assigned to the project. Detected evidences could be uploaded to 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.

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.

Other type 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 the 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.

Checkpoint has further metadata, like the severity (which is the impact of a non-compliant checkpoint on the risk for supply chain security), what is the meaning of the checked condition, and what needs to be done for attaining full compliance.

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 provides a compliance level in the 0 …​ 10 range, with 0 = not compliant, 10 = fully compliant, and 1 …​ 9 the level of partial compliance attained.

The global compliance status is derived from the checkpoints evaluated, with this scheme:

• Optional and n/a checkpoints do not influence in 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 …​ 10 range, telling us how far is the current status from full compliance for the target software project.

Unusual Activity Events and Anomaly Detection

Unusual activity events represent user actions in the tools or over the critical files that are out of the typical pattern of actions learned 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 Modifications (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.

Policies

A Xygeni policy lays out the set of rules, practices, checks and processes aimed at hardening your software infrastructure for controlling the risk of supply chain attacks. Each policy defines acceptable and unacceptable behaviors, which detectors should be in place, and what is the impact (based on risk scoring) when security issues are introduced.

A software project under analysis has a policy assigned, which could be more or less strict according to organizational 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.

Xygeni Web UI

Xygeni Web UI pages are composed of three elements:

3. The 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 to select a project subset among the available ones in the Xygeni organization. Almost every UI page’s data is related to 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.

When specific rules or special exit codes are required by pipelines or security policies, complex conditions can be defined using guardrail expressions.

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

This screen enables users to:

• View some basic statistics regarding the number of projects and issues of the organization

• 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

As usually in all the screens showing any list, the user can customize the list of projects shown in the table applying filters. Here we consider the following criteria:

• 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 the customer apply any custom criteria, the option ´Clear All´ over the filter boxes becomes red to remark that the filtering criteria is customized. Clicking on that option the filter will be reset to its default options.

Risk Score and Risk Level

The Risk Score (or Risk Level, RL for short) is a quantitative measure of the current risk with software supply chain attacks, and models the security posture of the DevOps system, according to the scans performed by the Xygeni platform.

In the Xygeni Screens we can access to Risk Score of all assets in the SDLC such as Projects but also for components, pipelines, collaborators, etc.

RL is a function of the issues found for the asset, with range the interval [0, 100], computed at the project level. When a project has no (detected) issues, its RL is zero. Higher values for RL are worse.

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.

List of projects

In the section of the list the user finds a table with several details

• Last scan date: The date of the latest scan of the information shown in the table

• Number of projects from the total items complying with the criteria of the filter. The table uses infinite scroll, so the user only has to scroll on the table to automatically load the next block.

• Bulk actions button: It will enable when one or more projects are selected clicking on the check box of the rows and based on the selection will enable applicable operations

User can interact with the rows in different ways

• Clicking on a white space of the row, the slide with details about the project will be opened

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

Although the operations are self descriptive, below you can find a quick description:

• Scan Now: equivalente to click the blue button to launch an on-demand scan if the project is integrated in the managed scan system

• View All Issues: equivalente to click on a white space of the row. It opens a slide with additional information as described below

• View Dependency Graph: If the user has the inventory license, the system shows the graphical representation of the project that shows all assets with its 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 of the project without need of going to the settings section.

• Go to Repository: If detected, it opens a new window and shows the repository of the project in the corresponding SCM

The project details (Slide)

When customer clicks on the row, or select the option of view details a slide with several sections opens:

The Actions button on the top right area shows the same actions that the menú in each row described above.

Summary

The summary view of the projects shows meta information related to the project date, size and location. Second section shows information about the team and most active users. Finally, some statistics from the languages contained in the project are also available.

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

Findings

Second section of the slide of information 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) appears before the name of the section, if the system detects malware there. Visiting the specific list of issues will show the malware on top of the vulnerabilities detected.

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

In the section below the statistics, User can directly see the first 5 issues of the category selected in the selector. For each issue the ´View Details´ option open another slide with details for the issue as in the specific risks screen

Xygeni’s Prioritization Funnels helps you to easily filter and identify those issues most relevant, helping you to concentrate on “fixing what matters”.

Given a full set of security issues, Prioritization Funnels allows you to specify “prioritization criteria” that will be automatically applied to the full set of issues, discarding those issues that don’t meet the criteria. The resulting set after applying the criteria 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 Risks sections and clicking on the Prioritization funnel button .

As you can see in the above example image, after applying some prioritization criteria, the initial 8,450 issues are reduced to 329.

The principal 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 (Risks (SAST), Risks (SCA), Risks (CI/CD), Secrets and Infrastructure as code) .

Out-of the-box Funnels

Xygeni comes with some out-of-the-box predefined Funnels

At the top filters of any funnel, click on “Funnel” filter and the available funnels are displayed:

• ** Xygeni General Prioritization

• ** Xygeni CI/CD Prioritization

• ** Xygeni IaC Prioritization

• ** Xygeni SAST Prioritization

• ** Xygeni Secrets Prioritization

Select anyone and the funnel will be refreshed with the new criteria.

By default, the funnel will be displayed based on “Severity”, i.e. it will show data grouped by severity (Critical, High, etc.). But (by clicking on “Split by” filter), you can switch the graphics to be based on Category (Malicious Code, IaC, Secrets, CI/CD, Open Source, etc)

You can even further filter by selecting specific Categories

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.

One of them is Funnel Phase, which 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 one of the funnel phases, the table will list the issues contained into the selected phase. Then, you can further refine your search by selecting additional filters.

Properties of the Risk Level

The RL has the following properties:

• Issues with info severity are ignored in the computation of the RL. They are just informative, and have no effect on the risk.

• In addition, muted issues are also ignored, 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. This is the "a chain is as strong as its weakest link" property. This is true for issues on a single 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 a issue changes to a higher severity, the RL should increase: more severe issues implies higher risk.

• No issue, no risk: RL(∅) = 0. When no issues found but analyses were run, risk level is zero. Note: When no analysis available for project, then RL is undefined, NOT zero.

• Averaged risk across projects is meaningful: 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.

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 could be edited in the xygeni.risk-level.yml configuration file.

The cutoff values for each risk category could be configured as well:

Xygeni platform is a cloud-based service, accessible via REST API, that keeps findings and metadata from different sources.

The Xygeni platform can be depicted by the following chart:

Scanner

Dashboard

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.

Integration scenarios

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

The following are the most common scenarios:

Using the scanner command line

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

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

In a snap, the Xygeni scanner, once installed, could be invoked from the command line like this:

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

# Scan a software repository
xygeni scan --repository URL

# Scan a container image
xugeni scan --image IMAGE

Integrate the scanner into a CI/CD pipeline

The build pipeline is a good point for running the Xygeni scanner, as it can check early in the build cycle if there are issues that should be resolved before advancing to the next step.

Under Continuous Integration / Continuous Delivery, an event on the source code repository often triggers a pipeline or workflow that builds, tests and perform different checks on the sources and the artifacts built. A Xygeni scan could be one of these checks. This ensures a continuos monitoring on security issues that may compromise the software supply chain.

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

Running scanner as a gate in a git hook

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

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

Two examples of common use cases for such hooks are (1) avoiding secret leaks committed to sources, and (2) critical file modifications not following a required change protocol.

Using Sensors for activity monitoring

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

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

Uploading findings from external security tools

Xygeni prioritization and response can be also used with security findings reported by third-party security tools (namely external scanners), both open-source and commercial. The scanner provides a report-upload command for uploading the structured reports generated by third-party security tools, in areas like Static Application Security Testing (SAST), Software Composition Analysis (SCA), or Secret Leaks / IaC Flaws Detection.

Imagine that your organization selected tool X for SAST. In your CI/CD pipelines you may have a step where the SAST tool is launched to uncover vulnerabilities in your source code or configurations. The output of the tool could be ingested by Xygeni to normalize the findings, and then use the findings for prioritization and remediation. The workflow can operate both on findings reported by Xygeni scans or by your third-party tool of choice, at least when its output format is supported.

Custom Funnels

With Xygeni, 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 a name to that funnel.

You can also use this new funnel as a “default” funnel for whatever type of risk.

After naming the new funnel, you add the criteria by selecting among the available ones in “Select a stage to add” .

Once you select one , clock on the plus sign (+) to add it to the funnel.

You will see some values for the criteria (true and false in the example). You decide which value must be met by any issue to “pass” the criteria. For example, if I select Reachability: true means that any reachable issue will pass this stage of the funnel.

You can add as many criteria (or stage) as you want, but remember that order is important. Criteria are applied from top to bottom. You can drag-and-drop the criteria to change the order.

For those multivalued criteria, selecting several options works as an “OR”

When done, click on Save button and your new funnel will be displayed and among the available ones.

Prioritization Criteria (Stages)

Any funnel is composed of criteria that produce the different stages of the funnel.

Out-of-the-box criteria

Xygeni provides some out-of-the-box criteria, although you can add your own custom criteria.

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.

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.

Exploitability

Given we found an issue with a CVE, we should first know if it is reachable (as seen above). But even being 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 add a more reliable criteria to the funnel, thus filtering out those issue with low exploitability likelihood.

You can view the EPSS Score associated to a vulnerability in the Vulnerability Details section.

Reachability

When a dependency has some 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 will not) 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 works 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 can exploit in the real deployed software.

But most of those findings are NOT actually reachable, because although the dependency with the vulnerability V is “imported” (in the component descriptors of the target software S and transitively on its dependencies), it only uses a small portion of those components, not invoking the vulnerable code for V.

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.

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.

Xygeni allows to generate SBOM for a certain project.

Two SBOM formats are currently supported:

To generate it, you have two options:

Generate SBOM from the Web User Interface

Once you have selected a project, the Dashboard will present you the Download SBOM option.

Generate SBOM with the Xygeni CLI

You can also generate a SBOM with xygeni CLI. This is useful if you need the SBOM during a build/deploy CI/CD process.

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

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

Trends Page

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

It can be accessed through Reports >> Trends at the Menu 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.

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.

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.

By Fixable (at least in OS depedendencies) it's meant that, for a certain vulnerability in a version of a dependency, there exists a further version that fixes the vulnerability.

Because not always there exists a fix, Fixable can take different values:

• No Fix Available : There does not exist any version that fix the vulnerability

SCM CI/CD Systems

Xygeni allows to be integrated into most of SCMs and CI/CD systems.

The following are examples on how to integrate Xygeni into several SCMs and CI/CD systems:

Sensor Plugins

Xygeni allows to actively monitoring and addressing vulnerabilities and risks as they are detected in the SCM or CI/CD systems.

The following are the provided sensors for SCM and CI/CD systems:

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:

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 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 another software too. Xygeni provides a rich set of predefined, off-the-self detectors used in scans, but you may add your own custom detectors.

Xygeni provides a comprehensive development framework for custom detectors, and such custom detectors can be easily integrated into scans using the --custom-detectors-dir option.

Defining custom converters for third-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.

Scans

At Reports >> Scans you can access all the historical information related to executed scans.

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

In case of error or warning, the slide will display the reason(s).

The list of scans also shows (and filter) the scope of the scan: complete (Full Scan) or partial (Partial Scan)

Scans Comparison

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

Xygeni’s Application Security Posture Management (ASPM) enhances how your teams visualize, prioritize, and remediate risks. 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 automates the identification and cataloging of every asset within your software supply chain, enhancing visibility and control over your development and deployment processes.

Furthermore, Xygeni automatically identifies and continuously monitors all assets, assessing their interdependencies and the individual and overall security posture of each asset, application, and customer defined group or category.

Users and Contributors Analysis

This analysis is crucial for managing administrative users, contributors, and collaborators associated with software repositories. By scanning and assessing the roles and activities of individuals involved in the development process, Xygeni supports organizations in achieving the least privilege approach by identifying and mitigating risks related to inactive or overprivileged users.

Some key features are:

Advanced Dynamic Prioritization

Customers can define up to eight stages in their prioritization funnel, tailored not only by severity but also by 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 refine their security focus further and manage vulnerabilities more effectively based on unique criteria important to their environment.

By utilizing Xygeni’s dynamic funnels, teams can optimize their security efforts, ensuring that critical issues are quickly identified and addressed.

Integration of Third-Party Security Reports

Xygeni’s Application Security Posture Management (ASPM) platform enhances its capabilities by easily integrating reports from third-party security tools, including Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools.

This integration allows organizations to leverage their existing technology stack, providing a comprehensive view of security threats across different tools and platforms.

By consolidating and correlating these reports, Xygeni helps teams understand their security posture in a unified context, 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, comprehensive dashboard for easy 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 providing centralized management of vulnerabilities.

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. The most relevant capabilities of our security audit trail are:

• Event Login: Every modification, update, or security event related to an asset is meticulously 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.

• Easy Access and Visualization: Users can easily access and visualize the audit trails through Xygeni’s intuitive interface to quickly find specific events or patterns.

• Enhanced Security and Compliance: By maintaining a detailed record of all actions taken on each asset, organizations can enhance their security posture and compliance with regulatory requirements, making it easier to verify that proper processes are followed and to detect potential security breaches early.

Quick and Efficient Remediation Process

Xygeni’s ASPM platform optimizes the remediation process by providing detailed guidelines and automated actions for addressing risks and vulnerabilities. It offers clear, actionable steps tailored to each specific issue, enabling quick and effective resolutions. Integration with ticketing and tracking tools facilitates easy updates to workflows, ensuring vulnerabilities are promptly managed.

ASPM set of options lets you access:

All Risks page

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

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:

Statistics

All Risks' 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 see issues of a specific type by clicking on the type

You can use filters to select specific issues:

• By severity

• By explanation

• By issue category (cicd, iac, secrets, etc)

• By issue type

• By project (pattern)

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

• By tag

All Assets

All Assets page shows the full list of assets for a given project of for a set of projects.

Given the high number of different asset types, the Navigation Bar offers several groups for related assets:

• Projects

• Components

• CI/CD Assets

• Delivery Assets

• System & Tools

• Collaborators

This page display the following information:

• Number of Assets

• Number of Assets at Risk (i.e. with security issues)

• Number of systems and tools

• Charts for number of issues by severity, category and category & severity (with links to specific assets types)

• A table with all the assets (as well as filters)

For every asset, it shows information about:

• Risk level of the asset

• Variation of the Risk Level from the project baseline

• Name of the Asset

• System of the Asset

• Category of the Asset

• 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-click on any asset to show the pivot graph for the selected asset.

Those assets with a red circle surrounding a number (the risk level for that asset) indicates that there are security risks associated to that asset. Clicking on them it displays the details of the asset together with its issues (Findings tab).

You can also select the Audit Trail tab to see a timeline of all the security issues introduction.

Findings and Audit Trail

Most of Risk pages contain a functionality to compare scans. It can be accessed by selecting ChangeLog option in the 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)

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

Assets in SDLC build and deploy infrastructure

Modern software is complex, and the build and deployment infrastructure is accordingly complex.

Software is typically built and deployed into production environments using pipelines of 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 assets involved in build/deploy pipeline are named SDLC assets, and in the Xygeni platform an inventory of SDLC assets, for the pipelines used in an organization, is discovered automatically.

Security issues and unusual activity events, as captured by the Xygeni platform, are then mapped to the target SDLC assets.

An SDLC Asset may present misconfigurations, leaked secrets, vulnerabilities and other security issues, and could be abused in software supply chain attacks. Common assets are code repositories, dependencies graphs, package managers, build files, security tools, CI/CD workflows, or IaC templates and provisioning scripts, along with the infrastructure, tools and extensions (like "plugins") used in the build / deploy pipelines.

Security issues and unusual activity events, as captured by the Xygeni platform, 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.

The SDLC inventory allows:

• To know which elements are involved during software build & deploy operations.

• To understand which pipelines are secure and which are vulnerable or flawed.

• To have an insight of how risk propagates across systems, and how an attack might break through systems to affect other parties.

The Asset Graph

In the SDLC inventory there are relations between assets, so it is important to understand the different kind of assets 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 with its own CI/CD tool enforce this pattern, and other external CI/CD tools like CircleCI also do, but others like Jenkins do not.

• The CI granularity has also 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 could present fully 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.

• A CD pipeline, on the contrary, is built from IaC configuration (a set of IaC template files under a given framework like Terraform, Azure ARM or Bicep, AWS CloudFormation…​) which launches 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, in the end, 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.

Assets discovery

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

The inventory scan processes configuration and source files for gathering information about the pipeline and resolving the relationship between the assets, including common assets like CI/CD systems and other shared tools.

You can reach the Inventory Projects page either by selecting Projects in the Navigation Bar or selecting the Project tab of the All Issues 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:

• the total number of projects in the group

• the number of files and total size of the group

• total number of commits and daily rate

• a table with all the projects (as well as filter fields)

For every project, it also display information about the number of issues by Asset Category (coloured by highest priority with issues)

The Summary tab shows general information as well as the possiblity ot download the SBOM for that project. The other tabs (SCM, Package Manager, CI/CD, AppSec and Deploy) show the project's assect by category. Selectin 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

• Creatin date, last code change, etc

• Team and Contributors of the project

• Programming languages

Inventory (panel and slides)

Bottom panel of Dashboard for a single project shows data about 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, # of pipelines, # of plugins, issues by severity)

• AppSec (appsec tools used, etc)

• Deploy and provisioning (cloud platforms, # of cloud resources defined in IaC files, issues by severity)

By clicking on this panel you can access further details on every group of assets.

By clicking on a specific asset you will see the details of that asset (general data, associated issues, etc)

Inventory (dependency graph)

In you click on the "Dependency Graph", you will see a full graph containing all the assets and relationships of the selected project. You can use the filters to reduce the graph as you need.

Clicking on any asset will open a slide with full information of the selected asset (properties and associated risks)

Download the SBOM

Selecting "Download SBOM" allows to generate and download the project SBOM in Cyclon DX or SPDX formats.

Issues Evolution

By selecting Issues Evolution on the All Risks page, you will see the evolution of the issues by issue type. You can also select different timeframes (last month, last 3 months, etc.)

The Inventory's Delivery Assets displays information about cloud assets of your project(s):

• Cloud configurations (dockerfiles, kubernetes deployments, etc)

• Cloud resources (any kind of cloud resource)

Comprehensive Support for Major Frameworks

• Terraform: We provide detectors for a wide range of resources across major cloud providers such as AWS, Azure, and Google Cloud, making it ideal for cloud-agnostic infrastructure setups.

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

The Inventory's Delivery Assets page displays the following information:

• Total number of Delivery assets (and number of assets with security issues)

• Distribution by type

• Cloud Frameworks and Providers detected

• A table with a full listing of all the Delivery Assets (as well as filter fields)

The Inventory's Components displays information about components (3rd party dependencies) of your project(s).

The Inventory's Components 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 some security risk

• Charts about distribution of components by repository, ecosystem and language

• A table with a full listing of all the components (as well as filter fields)

• Ecosystem (npm, maven, etc)

• Provenance (the parent component in case of a transitive dependency)

• Data about the Publisher of the component

• Latest available version and publication date

• License detected and type

The Issues tab shows information about vulnerabilities of the component.

The Inventory's CI/CD Assets displays information about CI/CD assets of your project(s):

• Pipelines

• Jobs

• Build Scripts (makefiles, pom.xml, etc)

• Scripts (shell scripts)

The Inventory's CI/CD Assets 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 listing of all the CI/CD Assets (as well as filter fields)

The Inventory's Systems & Tools displays information about systems and tools of your project(s):

• Security tools used in your pipelines (bandit, checkov, Checkmarx, Sonarqube, etc)

• SCMs (GitHub, Bitbucket, etc)

• SCMs plugins

• CI/CD systems (GitHub, Jenkins, Tekton, etc)

• CI/CD plugins

The Inventory's Systems & Tools page displays the following information:

• Total number of Systems & Tools assets (and number of assets with security issues)

• Distribution Systems & Tools by type

• Distribution of security tools by type

• A table with a full listing of all the Systems & Tools (as well as filter fields)

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

• SCM Organizations

• Users

• User Groups

The Inventory's Collaborators 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 (as well as filter fields)

In the Findings tab, you will find detailed information about the collaborator as well as a summary of all the issues introduced by the selected collaborator.

In the Audit Trail tab, you will find a timeline of all the security issues introduced by the selected collaborator.

Health Check

Health Check page displays useful metrics and details about your Xygeni projects.

There are several sections in this page:

• Findings by Category

• Projects

• Components

• System and Tools

• Collaborators

• Pipelines

• Coverage

Findings by Category

Findings by Category chart shows a 5-axis spider chart where there is an score about every axis.

Projects

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

Components section displays several types of information related to components.

Licensing Issues is the number of components with some kind of issues related to the component's license (mainly, use of a copyleft license).

With different versions is the number of components that are used in 2 or more different versions.

Out of date Versions is the number of components that a newer version is available.

Obsolete components is 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 to use another component.

If you click on any of the View >> links, you will see the components as well as the applied filters:

Collaborators

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. repo users whose performed actions 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

Pipelines section displays information about 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

Coverage section displays information about total number of projects without Inventory information (i.e. Inventory scanner not executed on those projects)

If you click on the View >> link, you will see the non-inventoried projects as well as the applied filters:

Projects by Size

Projects by Size section displays information about average size of projects as well as the number of projects above the average. This information is useful to detect the reasons (most often those over-sized projects include some kind of binary artifacts that should not be stored into the SCM).

If you click on the View >> link, you will see the over-sized projects as well as the applied filters:

Inventory Scanner Configuration

The Inventory Scanner is configured in the YAML file conf/xygeni.inventory.yml.

The scanner configuration file, conf/xygeni.inventory.xml contains properties for:

• Selecting the 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 use threads to run the scan in parallel across files and detectors.

# Configuration for xygeni Assets Inventory scanner.
# Arguments from command line have priority over properties in this file.

# Includes: list of glob patterns to include in analysis.
#
# A pattern could use ** (to match zero or more directories), * (zero or more characters
# in a directory or file name), and ? (one character).
# Examples: **/*.txt matches all files with 'txt' extension. **/test/** matches all files under any test directory.
#
# If empty, ALL files will be matched.
# The command-line argument -i or --include will be used when specified.
#
# A file is analyzed when matched by 'includes' AND NOT matched by 'excludes'.
includes: []

# Excludes: list of glob patterns to exclude from analysis.
# If empty, NO file will be excluded.
# The command-line argument -e or --exclude will be used when specified.
excludes:
  - ".git/**/*"
  - ".vscode/**/*"
  - "build/**/*"
  - "dev/**/*"
  - "**/__pycache__/**/*"
  - "**/.eggs/**/*"
  - "**/locales/**/*"
  - "**/spec/**/*"
  - "**/specs/**/*"
  - "**/test/**/*"
  - "**/tests/**/*"
  - "**/mock/**/*"
  - "**/mocks/**/*"
  - "**/integration/**/*"
  - "**/node_modules/**/*"
  - "**/bower_components/**/*"
  - "**/.xygeni.*.json"
  
# mode=sequential runs analyzers sequentially;
# mode=parallel runs analyzers in multiple threads, when analyzer is capable of parallel runs.
mode: parallel

# Timeout, in seconds, for the analysis to complete. 0 or negative means no timeout.
timeout: 600

# Config for reporters
report:
  - format: json
    prettyPrint: true

  - format: csv

    # Allowed values: "id", "kind", "scope", "name", "qualifiedName", "belongsTo", "fullyResolved", "path", "createdAt", "updatedAt", "tags", "properties"
    columns: [ "kind", "name", "qualifiedName", "belongsTo", "fullyResolved", "path", "createdAt", "updatedAt", "tags", "properties"]

    # Order specification. 'default' lists by kind first, then by name.
    # One of 'default' or 'id'.
    sort: default

  - format: text

    # Allowed values: "id", "kind", "scope", "name", "qualifiedName", "belongsTo", "fullyResolved", "path", "createdAt", "updatedAt", "tags", "properties"
    columns: [ "kind", "name", "belongsTo", "tags" ]

    # Order specification. 'default' lists by kind first, then by name.
    # One of 'default' or 'id'.
    sort: default

    # The style for table borders.
    # One of 'full', 'none', 'outside', 'inside', 'horizontal', 'vertical', 'topbottom'.
    # Use 'default' for border that works well for the underlying OS.
    borders: full

    # The block characters to use: 'ascii' (use '+', '|', '-' and '=')
    # or 'utf8' for UTF-8 block characters.
    # Use 'default' for the encoding that works best for the underlying OS.
    bordersEncoding: utf8

# The detectors to use for discovering SDLC assets
# are configured in resource files under inventory/*.yml

# List of detectors to run: IDs.
# Leave empty for no restriction (all detectors not disabled will be chosen).
# Command-line property --detectors overrides this.
runDetectors: []

# Same format as runDetectors, but for skipping the selected detectors.
# Leave empty for no restriction (all detectors not disabled will be chosen).
# Command-line property --skip-detectors overrides this.
skipDetectors: []

Inventory Assets Detectors Configuration

Assets for different ecosystems are processed by specific detectors. Each detector process matching files and other sources, and may invoke a tool API, when available, for gathering additional information for 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 facility included by the SCM systems listed above, plus specialized CI/CD systems like Jenkins, CircleCI or Travis CI.

• Security tools: Many kinds of security tools, as configured in the xygeni.security_tools.yml configuration file.

• Cloud assets, like containers, container orchestrators, Infrastructure-as-Code (IaC) frameworks and provisioning tools, like Dockerfiles, docker-compose, Kubernetes, Terraform, Bicep, Azure Resource Manager, CloudFormation, Ansible, etc.

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

SCA (Software Composition Analysis)

SAST (Software Application Security Testing)