dep-scan is a fully open-source security audit tool for project dependencies based on known vulnerabilities, advisories and license limitations. Both local repositories and container images are supported as input. The tool is ideal for CI environments with built-in build breaker logic.

If you have just come across this repo, probably the best place to start is to checkout the parent project slscan which include depscan along with a number of other tools.


  • Local repos and container image based scanning with CVE insights [1]
  • Package vulnerability scanning is performed locally and is quite fast. No server is used!
  • Suggest optimal fix version by package group (See suggest mode)
  • Perform deep packages risk audit for dependency confusion attacks and maintenance risks (See risk audit)


  • [1] Only application related packages in container images are included in scanning. OS packages are not included yet.
Depscan insights

Vulnerability Data sources

  • OSV
  • NVD
  • GitHub
  • NPM


dep-scan is ideal for use during continuous integration (CI) and also as a tool for local development.

Use with ShiftLeft Scan

dep-scan is integrated with scan, a free and open-source SAST tool. To enable this feature simply pass depscan to the --type argument. Refer to the scan documentation for more information.

–type python,depscan,credscan

This approach should work for all CI environments supported by scan.

Scanning projects locally (Python version)

sudo npm install -g @appthreat/cdxgen
pip install appthreat-depscan

This would install two commands called cdxgen and scan.

You can invoke the scan command directly with the various options.

depscan –src $PWD –report_file $PWD/reports/depscan.json

Full list of options are below:

usage: depscan [-h] [–no-banner] [–cache] [–sync] [–suggest] [–risk-audit] [–private-ns PRIVATE_NS] [-t PROJECT_TYPE] [–bom BOM] -i SRC_DIR [-o REPORT_FILE]
-h, –help show this help message and exit
–no-banner Do not display banner
–cache Cache vulnerability information in platform specific user_data_dir
–sync Sync to receive the latest vulnerability data. Should have invoked cache first.
–suggest Suggest appropriate fix version for each identified vulnerability.
–risk-audit Perform package risk audit (slow operation). Npm only.
–private-ns PRIVATE_NS
Private namespace to use while performing oss risk audit. Private packages should not be available in public registries by default. Comma
separated values accepted.
Override project type if auto-detection is incorrect
–bom BOM Examine using the given Software Bill-of-Materials (SBoM) file in CycloneDX format. Use cdxgen command to produce one.
-i SRC_DIR, –src SRC_DIR
Source directory
-o REPORT_FILE, –report_file REPORT_FILE
Report filename with directory
Continue on error to prevent build from breaking

Scanning containers locally (Python version)

Scan latest tag of the container shiftleft/scan-slim

depscan –no-error –cache –src shiftleft/scan-slim -o containertests/depscan-scan.json -t docker

Include license to the type to perform license audit.

depscan –no-error-cache –src shiftleft/scan-slim -o containertests/depscan-scan.json -t docker,license

You can also save container images using docker or podman save command and pass the archive to depscan for scanning.

docker save -o /tmp/scanslim.tar shiftleft/scan-slim:latest
podman save –format oci-archive -o /tmp/scanslim.tar shiftleft/scan-slim:latest
depscan –no-error –src /tmp/scanslim.tar -o reports/depscan-scan.json -t docker

Supported languages and package format

dep-scan uses cdxgen command internally to create Software Bill-of-Materials (SBoM) file for the project. This is then used for performing the scans.

The following projects and package-dependency format is supported by cdxgen.

LanguagePackage format
node.jspackage-lock.json, pnpm-lock.yaml, yarn.lock, rush.js
javamaven (pom.xml [1]), gradle (build.gradle, .kts), scala (sbt)
phpcomposer.lock, requirements.txt [2], Pipfile.lock, poetry.lock, bdist_wheel, .whl
gobinary, go.mod, go.sum, Gopkg.lock
rubyGemfile.lock, gemspec
rustCargo.toml, Cargo.lock
.Net.csproj, packages.config, project.assets.json, packages.lock.json
docker / oci imageAll supported languages excluding OS packages


The docker image for dep-scan currently doesn’t bundle suitable java and maven commands required for bom generation. To workaround this limitation, you can –

  • Use python-based execution from a VM containing the correct versions for java, maven and gradle.
  • Generate the bom file by invoking cdxgen command locally and subsequently passing this to dep-scan via the --bom argument.

Integration with CI environments

Integration with Azure DevOps

Refer to this example yaml configuration for integrating dep-scan with Azure Pipelines. The build step would perform the scan and display the report inline as shown below:

Integration with GitHub Actions

This tool can be used with GitHub Actions using this action.

This repo self-tests itself with both sast-scan and dep-scan! Check the GitHub workflow file of this repo.

  • name: Self dep-scan
    uses: AppThreat/dep-scan-action@master
    VDB_HOME: ${{ github.workspace }}/db
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Customisation through environment variables

The following environment variables can be used to customise the behaviour.

  • VDB_HOME – Directory to use for caching database. For docker based execution, this directory should get mounted as a volume from the host
  • NVD_START_YEAR – Default: 2018. Supports upto 2002
  • GITHUB_PAGE_COUNT – Default: 2. Supports upto 20

GitHub Security Advisory

To download security advisories from GitHub, a personal access token with the following scope is necessary.

  • read:packages

export GITHUB_TOKEN=””

Package Risk Audit

--risk-audit argument enables package risk audit. Currently, only npm and pypi packages are supported in this mode. A number of risk factors are identified and assigned weights to compute a final risk score. Packages that then exceed a maximum risk score (config.pkg_max_risk_score) are presented in a table.

Use --private-ns to specify the private package namespace that should be checked for dependency confusion type issues where a private package is available on public npm/pypi registry.

Example to check if private packages with namespaces @appthreat and @shiftleft are not accidentally made public use the below argument.

--private-ns appthreat,shiftleft
Risk categoryDefault WeightReason
pkg_private_on_public_registry4Private package is available on a public registry
pkg_min_versions2Packages with less than 3 versions represent an extreme where they could be either super stable or quite recent. Special heuristics are applied to ignore older stable packages
mod_create_min_seconds1Less than 12 hours difference between modified and creation time. This indicates that the upload had a defect that had to be rectified immediately. Sometimes, such a rapid update could also be malicious
latest_now_min_seconds0.5Less than 12 hours difference between the latest version and the current time. Depending on the package such a latest version may or may not be desirable
latest_now_max_seconds0.5Package versions that are over 6 years old are in use. Such packages might have vulnerable dependencies that are known or yet to be found
pkg_min_maintainers2Package has less than 2 maintainers. Many opensource projects have only 1 or 2 maintainers so special heuristics are used to ignore older stable packages
pkg_min_users0.25Package has less than 2 npm users
pkg_install_scripts2Package runs a custom pre or post installation scripts. This is often malicious and a downside of npm.
pkg_node_version0.5Package supports outdated version of node such as 0.8, 0.10, 4 or 6.x. Such projects might have prototype pollution or closure related vulnerabilities
pkg_scope4 or 0.5Packages that are used directly in the application (required scope) gets a score with a weight of 4. Optional packages get a score of 0.25
deprecated1Latest version is deprecated

Refer to method for the risk formula.

Automatic adjustment

A parameter called created_now_quarantine_seconds is used to identify packages that are safely past the quarantine period (1 year). Certain risks such as pkg_min_versions and pkg_min_maintainers are suppressed for packages past the quarantine period. This adjustment helps reduce noise since it is unlikely that a malicious package can exist in a registry unnoticed for over a year.

Configuring weights

All parameters can be customized by using environment variables. For eg:

export PKG_MIN_VERSIONS=4 to increase and set the minimum versions category to 4.