Suspect Dependencies Scanner

Purpose

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

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

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

Handling findings

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

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

Quick Start

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

xygeni suspectdeps -n MyProject --upload

uploads the result to Xygeni platform.

Suspect Deps scanner can be launched in two different ways:

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

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

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

xygeni suspectdeps -n MyProject --detectors high \
       --format csv --output MyProject.suspectdeps.csv

Usage

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

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

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

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

• Upload results to the service, --upload. By default, results are not uploaded.

• Output file (-o or --output) and format (-f or --format). If 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.

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

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

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