Xygeni User Guides
  • Welcome to Xygeni
  • Getting Started
    • Create a Free Trial Account
    • Quick start with your code repository
    • Quick start with Xygeni CLI
    • Quick start with a preloaded project
    • Log in to Xygeni
    • Subscribe to Xygeni
  • Introduction to Xygeni
    • Key Concepts
      • Projects in Xygeni
      • Project Baseline
      • Detected Issues
      • Remediation Actions
      • Policies
      • Risk Level
      • SDLC Inventory
      • Standards Compliance
      • GuardRails
    • Xygeni Products
    • How Xygeni works
    • Xygeni Web UI Overview
      • Projects Screen
        • Risk Level
    • Integrating Xygeni into your Workflow
    • Prioritization Funnels
      • Custom Funnels
      • Prioritization Criteria (Stages)
        • Reachability
        • Exploitability
        • Fixable
    • Guardrails
    • Generate a SBOM
    • Reports
      • Trends
      • Scan History
    • Supported Integrations
    • Customizations
  • Xygeni Products
    • Application Security Posture Management (ASPM)
      • ASPM User Interface Guide
      • All Risks
        • Statistics
        • Issues Evolution
        • Issue Comparison Between Different Scans
      • Governance
      • Inventory
        • All Assets
        • Repositories
        • Components
        • CI/CD Assets
        • Delivery Assets
        • Systems & Tools
        • Collaborators
      • Health Check
      • Inventory Scanner
        • Inventory Scanner Configuration
        • Inventory Collaborators Scan
      • Importing reports from 3rd party tools
        • External Scanners Supported
          • Report upload for Kiuwan
            • ExportRule (.java)
    • Code Security (SAST)
      • Code Security (SAST) User Interface Guide
        • Risks (SAST)
        • Malicious Code
      • Malware Scanner
        • Malware Scanner Configuration
        • Malware Detectors
      • SAST Scanner
        • SAST Scanner Configuration
    • Open Source (SCA)
      • Open Source (SCA) User Interface Guide
      • Open Source Components
      • Supported Package Managers for dependency resolution
      • Risks (SCA)
      • OSS Prioritization Funnels
      • OSS Auto-Remediation
      • Malware Early Warning (MEW)
        • How Malware Early Warning works
        • Common types of Malware found in open source packages
      • Dependency Scanner
        • Dependency scanner configuration
        • Dependency Analyzers
      • Suspect Dependencies Scanner
        • Suspect Deps Scanner Configuration
        • Suspect Deps Detectors
    • CI/CD Security
      • CI/CD Security User Interface Guide
      • CI/CD Details
      • Build Attestations
      • CI/CD Scanner
        • CI/CD Misconfigurations Scanner Configuration
      • Compliance Scanner
        • Supported compliance standards
    • Secrets Security
      • Secrets User Interface Guide
      • Secrets Scanner
        • Secrets scanner configuration
      • Secret Leaks Handling
        • Secret Leaks Handling
        • How to Prevent Hard-Coded Secrets
        • Secret Leaks Handling CheatSheet
      • Secrets Auto-Remediation
    • IaC Security
      • IaC User Interface Guide
      • IaC Scanner
        • IaC Scanner Configuration
    • Malware
    • Build Security
      • Build Security Concepts
      • Build Attestations
      • Attestation format
      • How SALT works
      • Installing Salt CLI
      • Salt Command-Line Reference
      • SALT Architecture
      • SALT How To…​
    • Anomalous Activity Detection
      • Anomalous Activity Detection User Interface Guide
      • Xygeni Sensors
        • Xygeni Sensor for Azure
        • Xygeni Sensor for BitBucket
        • Xygeni Sensor for GitHub
          • GitHub Audit Log Processing
        • Xygeni Sensor for GitLab
        • Xygeni Sensor for Jenkins
        • Anomaly Detection's Detectors
      • Code Tampering Scanner
        • Code Tampering Scanner Configuration
    • Compliance & Malware Insights
      • SSCS Compliance
      • Malicious Packages DB
  • Scan Management
    • Manage Scans
    • Scan History
  • Xygeni Scanner CLI
    • Xygeni Scanners
    • Xygeni CLI Overview
      • Xygeni CLI Prerequisites
      • Xygeni CLI Installation
      • Xygeni CLI Docker Image
      • Xygeni CLI Authentication
        • CLI Authentication with Xygeni
      • SCM, CI/ CD and Container Registry tokens
      • Xygeni CLI Operation Modes
        • Single scan
          • Scanning a docker image
        • Multi Scan
        • Organization scan
      • Xygeni CLI Configuration options
      • Xygeni CLI Output Formats
      • Exporting Xygeni results to 3rd party tools
      • Automatic Remediation
      • Generate SBOM with the Xygeni CLI
      • CLI utils
        • Credentials Encryption
        • Central Configuration
      • Xygeni Guardrails
        • CI/CD Audit Analysis
      • Xygeni CLI Error Codes
      • Xygeni Scanner Reference
  • Xygeni Administration
    • Platform Administration
      • Profile
      • Subscription
      • Users Management
      • Projects Management
      • Groups Management
      • Policies
      • Integrations
        • Xygeni Single Sign-On (SSO) Authentication
          • SSO - OKTA
          • SSO - Microsoft Entra ID
        • Integrate Scanner CLI into CI/CD Systems
          • Azure Pipelines Integration
          • BitBucket Integration
          • CircleCI Integration
          • GitHub Actions Integration
          • GitLab Runner Integration
          • Jenkins Integration
          • Travis CI Integration
        • Git Hooks with Xygeni
        • Collaboration & communication Tools
        • Ticketing Systems
        • Remediation systems
      • Notifications
    • Rest API
  • Support
  • Changelog
    • Version 5.11 - April 11, 2025
    • Version 5.9 – March 26, 2025
Powered by GitBook
On this page
  • Xygeni Policies
  • Policies Management
  • Custom Policies
Export as PDF
  1. Xygeni Administration
  2. Platform Administration

Policies

PreviousGroups ManagementNextIntegrations

Last updated 28 days ago

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

Policies Management

To access this section you must go to Settings >> Policies.

Xygeni provides three initial policies that could be used directly or as a starting point for defining custom organization policies:

  • strict, where most of the security controls available are enabled. At the cost of forcing teams to follow rigorous procedures for certain assets in the software infrastructure, it offers the highest level of protection, typically for highly sensitive software projects.

  • default, a good trade-off between security and ease-of-use. Many controls are enabled, with only the most stringent but not essential controls disabled. Recommended for important software projects that are used by customers and other third-parties.

  • loose, with only the most critical controls enabled. Best for ease-of-use, typically relevant for internal projects with no external users.

Any Xygeni project has an associated Policy. If not explicitly associated, a new project will be associated with the policy tagged as Default policy.

You can choose which policy will be the default among the existing ones (initial or custom policies). To do it, just select a policy and click on Set as default button.

Please note, that changing the default policy to another will not change the association for already existing projects, that will only apply to new projects.

Initial policies may change according to Xygeni decission. Thus, take in mind that associating an initial policy to a project can vary the results upon modification by Xygeni.

Custom Policies

Your organization may have different software supply chain security (SSCS) requirements, according to the importance of the assets to protect, like software projects and their underlying build & deploy infrastructure. Before configuring a custom Xygeni policy, you must first determine which is the depth of the security controls you want to implement and enforce:

  • How changes in source repositories should be done to limit the risk of code tampering? This implies how commits should be done, how changes or branch merges are reviewed or approved, and how modification on critical files should be performed.

  • How third-party software (components, container images, binaries…​) and extensions/plugins in tools of the software infrastructure should be verified.

  • How the build systems and their incarnations (CI/CD systems) and tools (build, packaging, testing, linting, security analyzers, code & documentation generation) should be protected to avoid breaches.

  • How to document the results of the build/deploy processes, via bill-of-materials and attestations, and the process of delivering them to the end users for validation.

  • How the software delivery should ensure that produced software artifacts are placed in the distribution hubs so tampering in between could be avoided or at least integrity violations could be detected by end-users before executing the software.

Creating a Custom Policy follows the approach "save as..".

This means that once you have selected a policy , after modifying any aspect of the policy the Save button will be enabled, so you can either save the current policy or create a new one (providing a new policy name).

Clicking on Statistics will show to you detailed information about ;

  • Active detectors

  • Compliance standards

  • Associated projects to the selected policy

A policy is just a set of configured detectors. So for any selected detector you can :

  • modify the severity (critical, high, low info)

  • activate /deactivate the detector

Available detectors are grouped by type in several tabs (secrets, CI/CD, IaC, etc.) . Go to the appropriate tab to find all associated detectors.

After modifying any detector of a policy the Save button will be enabled, so you can either save the current policy or create a new one (providing a new policy name).

If you want to keep a stable policy, create a

Which is the SSCS framework your organization adopted? Examples like the CISA/ESF

Securing the Software Supply Chain - Recommended Practices Guide for Developers
Custom Policy