CI/CD Misconfigurations Detection

Overview

Xygeni’s Supply Chain Security protect 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).

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

Compliance Assessment

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

See supported standards for more information.

TBD

Supply Chain 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:

• Risks (CI/CD) : All the CI/CD security issues at a glance.

• Build Attestations : All your project(s) integrity build processes

• Compliance : Your project(s) compliance with compliance standards.

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

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 Funnel Phase (see Prioritization Funnels )

• By severity

• By issue type

• By project (pattern)

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

• By tag

• etc.

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

Prioritization funnel

Secrets' Prioritization funnel view shows default CI/CD funnel.

The Compliance page provides a comprehensive view of all your project(s) compliance with Supported compliance standards.

Project Group View

If you have selected All projects or a subset of projects, you will see this general view.

You can see the compliance level of all the supported standards for the selected projects group. This charts will provide you with a high level view of the general coverage of checkpoints per standard.

Furthermore, you can see a list with all the projects together with it's respective compliance level for every standard.

Single Project View

Opening the Compliance page for a selected single project will display as below image.

This page will show statistics for every standard that the selected project has been assessed:

• Overall view of passed/failed checkpoints

• Checkpoints by result

• A list of all the checkpoints together with its pass status

Clicking on icon of any checkpoint will open a slide with the details

Table of Contents

1. Purpose

2. Handling Results

3. Quick Start

4. Usage

5. Configuration

6. Detectors

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

xygeni misconf -n MyProject --upload

uploads the result to Xygeni platform.

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

xygeni misconf -n MyProject --detectors critical \
            --format csv --output MyProject.misconfs.csv

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 :

xygeni misconf --help

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

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.

SCMs and CI/CD misconfigurations scanning

CI/CD scanner performs checks against your SCM and CI/ CD systems recover information about your repository and organization, as part of the scanning process to validate if there are misconfigurations affecting them.

For that, it is important to provide tokens with the permissions allowing 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.

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.

CI/CD Misconfigurations Detectors

Please read the documentation on CI/CD misconfigurations detectors available.

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.

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

Standards

See supported standards and guidelines for more details.

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.

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

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

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 Policy page 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 policy level, - by deactivating the checkpoint at the central configuration level (e.g. by setting enabled: false in the checkpoint YAML configuration).

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.

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.

One of the most popular frameworks is pre-commit. 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 pre-commit quick start 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.

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

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

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.

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

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

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

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

The easiest way to define your own standard is using the Policy Administration. 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 central configuration.

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

CIS Software Supply Chain Security benchmark

The CIS Software Supply Chain Security benchmark provides prescriptive guidance for establishing a secure configuration posture for Software Development Platforms and Pipelines.

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 OpenSSF FLOSS Best Practices is a set of recommendations from the Open Source Security Foundation (OpenSSF) Best Practices Working Group to help open source developers create and maintain more secure software.

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

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

ESF Securing the Software Supply Chain DEV

The ESF Securing the Software Supply Chain - Recommended Practices for Developers is a set of guidelines aimed at improving the security of software development by reducing the risk of supply chain attacks.

The set of recommend 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.