debricked/cli

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

cli's Issues

CLI is built with go 1.20, but apk add go install go 1.19 in Dockerfile

In the multistage Dockerfile that is used to build the official release of the image there is a problem with go versions:

Under the first scope (FROM golang:1.20-alpine AS dev) go 1.20 is used, but under the second scope:

FROM alpine:latest AS cli
...
RUN apk --no-cache --update add go

Alpine will resolve to go version 1.19 today.

It is probably good to be explicit about what version of go to install, rather than rely on whatever is distributed through Alpine right now.

This affects the resolution-cmd branch.

Add test of building Docker images

To avoid issues like addressed in #120 from sneaking into main

• Utilise docker cache https://docs.docker.com/build/ci/github-actions/cache/
• Upgrade docker build action to v5.0.0 https://github.com/docker/build-push-action

Add --no-install command to resolve command

Add the ability to resolve dependency trees and generate lock-files without installing dependencies. This is relevant because I already have all my dependencies installed in a private image that I'm using as a base to perform the Debricked scan in my CI, therefore I would just like to resolve my (pip) lock files and scan them, without installing stuff.

Distribute images for different distros

Package installation can be complex sometimes and depend on the underlying OS. For pip, installing some c-compiled packages may require re-compilation of that package during installation on Alpine distros. But, pip can simply download the relevant files on Debian without compilation.

It would be great if I could choose what distro my debricked/cli image was so that I can pick the distro best suited to my needs (and not re-compile pandas 100 times a day 🛩️ )

Python virtual env not removed if resolve fails

When running debricked resolve on a python project, if the command is successful, the generated requirements.txt.venv folder is removed. But if the command fails for some reason, the requirements.txt.venv folder remains in the project root.

Add support for configuring exclusions through environment variables

As title, in addition to the existing --exclusion flag.

Ideally the exclusions are comma separated when using the environment flag.

E.g.

-e "*/**.lock" -e "**/node_modules/**" -e "*\**.ex

becomes

DEBRICKED_EXCLUSIONS="*/**.lock,**/node_modules/**,*\**.ex"