Debricked CLI

Safety through commandline.
debricked.com »

debricked is Debricked's command line interface. It brings open source security, compliance and health to your project via the command prompt.

Check out the releases page. Choose the asset that is applicable for your system. Below follow some common ways to install the CLI.

curl -LsS https://github.com/debricked/cli/releases/download/release-v2/cli_linux_x86_64.tar.gz | tar -xz debricked

./debricked

curl -LsS https://github.com/debricked/cli/releases/download/release-v2/cli_macOS_arm64.tar.gz | tar -xz debricked

./debricked

1. Download zip
2. Unpack zip

.\debricked

docker pull debricked/cli:2-resolution-debian

Once you've installed the CLI, you're ready to scan your project. You can scan a local project, or integrate a scanning mechanism in your CI/CD pipeline.

1. Sign up to Debricked
2. Create an access token
3. debricked scan -t <access-token>

When the scan is complete, you will see the total number of vulnerabilities found and a list of automation rules that have been evaluated. Read more about automations here.

Failed resolution of dependency files affects the scan and its exit code according to --resolution-strictness (default 1):

A resolution failure typically means the relevant package manager is not installed or not on the PATH (for example mvn or composer).

If Debricked's scan queue is long, the CLI stops polling for progress and exits with code 1, having printed a link to the results. Pass --pass-on-timeout to exit 0 in that case instead.

To make a scan directly through Docker based on your current working directory, you can use the following command:

docker run -v $(pwd):/root debricked/cli:2-resolution-debian debricked scan -t <access-token>

If you would rather use debricked in your CI/CD pipelines, check out the templates.

debricked mcp start runs a Model Context Protocol server over stdio, letting AI coding assistants (Claude, Copilot, Cursor, etc.) check whether a dependency is allowed by your Fortify SCA policies before it's installed.

1. Authenticate once with debricked auth login, or have a Debricked access token ready to pass via --access-token/DEBRICKED_TOKEN.
2. Point your MCP client at the debricked binary with the mcp start arguments. Examples below assume debricked is on your PATH; otherwise use the full path to the binary.

{
  "servers": {
    "debricked": {
      "type": "stdio",
      "command": "debricked",
      "args": ["mcp", "start"]
    }
  }
}

{
  "mcpServers": {
    "debricked": {
      "type": "stdio",
      "command": "debricked",
      "args": ["mcp", "start"]
    }
  }
}

{
  "mcpServers": {
    "debricked": {
      "type": "stdio",
      "command": "debricked",
      "args": ["mcp", "start"]
    }
  }
}

If you haven't run debricked auth login, pass the token explicitly instead:

{
  "command": "debricked",
  "args": ["mcp", "start"],
  "env": {
    "DEBRICKED_TOKEN": "<access-token>"
  }
}

Validate your debricked_policy.json against Debricked's policy schema before you scan, so that a broken policy file is caught locally instead of in your pipeline.

debricked policy validate                                  # validates ./debricked_policy.json
debricked policy validate .debricked/debricked_policy.json # validates a specific file
debricked policy validate .debricked                       # validates debricked_policy.json in that directory

Each validation error is printed on its own line, prefixed with the property it concerns:

⨯ debricked_policy.json has 2 validation errors
policies[0].name: The property name is required
policies[0].rules: Array must have at least 1 item

Pass --output json (-o json) to emit the result as JSON for CI integrations. Validation results are written to stdout, other failures to stderr, which keeps the JSON output parseable:

{
  "file": "debricked_policy.json",
  "valid": false,
  "errors": [
    {
      "propertyPath": "policies[0].name",
      "message": "The property name is required",
      "context": {"constraint": "required"}
    }
  ]
}

Thank you for your interest in making Debricked CLI even better! Read more about contributing to the project here.

1. Go to the releases page, press Draft a new release.

2. Create a new tag. We loosely use semantic versioning for our versions.

• Major releases should only be used for major breaking changes.
• Minor releases should be used for minor breaking changes and new major features.
• Patch releases should be used for smaller improvements, bug fixes etc. No breaking changes are allowed in these.

2a. IF you released a major version. The following needs to be done:

• For a major, a upgrade document needs to be provided like we did for the 2.0 release.
• Our GitHub actions need to be updated accordingly. Like was done in this commit for the v1 -> v2 upgrade.
• Users need to be informed that a new major version is available and that they should upgrade.
• All integration templates needs to be updated to use the new major version.
• Our documentation needs to be updated to use the new major version.

3. After having created a new tag in the New release dialogue. Press Generate release notes to get some sane default notes. Adjust if necessary. It will look something like this:

4. When satisfied, press Publish release.

5. Artifacts should be automatically built in the Release workflow, please monitor it to make sure that the release are done correctly. Also make sure that the Docker workflow is triggered and successful for the given tag.