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.

Installation

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

Linux

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

./debricked

Mac

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

./debricked

Windows

1. Download zip
2. Unpack zip

.\debricked

Docker

docker pull debricked/cli:2-resolution-debian

Scan

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.

Docker

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>

CI/CD integration

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

Contributing

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

Releasing

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.