Implement uds scan in our release processes

[Racer159]

Describe what should be investigated or refactored

We should start to test out the new uds scan command as a part of our release process for each application package.

Links to any relevant code

https://uds.defenseunicorns.com/cli/quickstart-and-usage/#scan

Additional context

Needed for @naveensrinivasan and @eddiezane to get feedback on the tool.

Tasks

Beta Give feedback

1. GitLab
2. GitLab Runner
3. SonarQube
4. Mattermost
5. Postgres Operator
6. Valkey

[Racer159]

This will require new uds - defenseunicorns/uds-common#148

[Racer159]

We should probably just upload this as a release artifact when the release is created - I would advocate not including the vuln information in a package (or bundle) because it will get stale and people inspecting it later (out of context of the GitHub action / release that generated it) may get a false sense of their vulnerability posture.

[austenbryan]

That is a good point @Racer159 . Do you have a better idea on how to share/give to users?

People in the air gap will likely have limited data sets and work this way right now. There is likely a blend between a known state with a timestamp to notifying how long it has been since a new scan with an updated DB

[Racer159]

The thought was to just place the csv in the release in GitHub and then for now we could aggregate them per customer (if that was desired by that customer) - right now the only bundle we make is for uds-prod and given it is an automated deployment the inclusion of these artifacts would not really get a chance to review.

[ericwyles]

Couple of questions:

1. Am I correct that the uds scan command can only scan packages that it can fetch from a registry?
   If so then 2) what do you think for an "on release" workflow?

I was expecting to be able to scan a package from local filesystem as part of build/release, but it looks like I might need to publish the package first and then let uds scan pull it back down to scan it. Is that the intended sequence?

I think it would be nice to be able to scan a package without publishing it, especially for a dev workflow where a package maintainer is trying to get quick feedback on resolution of CVEs.

@naveensrinivasan @eddiezane @Racer159

[naveensrinivasan]

Couple of questions:

1. Am I correct that the uds scan command can only scan packages that it can fetch from a registry?
   If so then 2) what do you think for an "on release" workflow?

I was expecting to be able to scan a package from local filesystem as part of build/release, but it looks like I might need to publish the package first and then let uds scan pull it back down to scan it. Is that the intended sequence?

I think it would be nice to be able to scan a package without publishing it, especially for a dev workflow where a package maintainer is trying to get quick feedback on resolution of CVEs.

@naveensrinivasan @eddiezane @Racer159

@ericwyles
ATM, uds scan can only scan packages in the registry.
I agree that scanning the local filesystem without going through the registry will be helpful.

I would appreciate it if you could create that as an issue in https://github.com/defenseunicorns/uds-security-hub

[ericwyles]

@naveensrinivasan Added that here: defenseunicorns/uds-security-hub#61

Thanks!

[marshall007]

@naveensrinivasan FYI the changes in defenseunicorns/uds-cli#622 for adding uds scan broke go install, see: defenseunicorns/uds-cli#718

[naveensrinivasan]

We now have an option to pass local zarf packages.

Also please use ghcr.io/defenseunicorns/uds-security-hub:v0.0.8 docker image as we are iterating fast we aren't updating the UDS-CLI with the changes

docker run ghcr.io/defenseunicorns/uds-security-hub:v0.0.8 --help
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Scan is a tool for scanning zarf packages for vulnerabilities and generating a report with Trivy

Usage:
  scan [flags]

Flags:
  -h, --help                     help for scan
  -o, --org string               Organization name (default "defenseunicorns")
  -f, --output-file string       Output file for CSV results
  -n, --package-name string      Package Name: packages/uds/gitlab-runner
  -p, --package-path string      Path to the local zarf package.
                                 This is for local scanning and not fetching from a remote registry.
  -r, --registry-creds strings   List of registry credentials in the format 'registry:username:password'.
                                 Example: 'registry1.dso.mil:myuser:mypassword'
  -g, --tag string               Tag name (e.g.  16.10.0-uds.0-upstream)

docker run -v $(pwd)/pkg/scan/testdata:/app/testdata ghcr.io/defenseunicorns/uds-security-hub:v0.0.8  -p /app/testdata/zarf-package-mattermost-arm64-9.9.1-uds.0.tar.zst --registry-creds ghcr.io:naveensrinivasan:password --registry-creds registry1.dso.mil:naveensrinivasan:password --registry-creds docker.io:naveensrini:password -f output.csv

[ericwyles]

@naveensrinivasan A couple things we ran into implementing this, let me know if you want me to make issues for them:

1. The scanner seems to be pulling images from registries instead of using the images that are in the local package. We caught this because we have some packages that have images inside them that only exist locally and are not published to a registry. BUT even if the images were in a registry, we want to scan the ones that are in the package because the tag in the registry could have been updated to an image with a different CVE posture. So we need to scan the images from the package to make sure we have the correct CVE information for the specific package. This will also be important if we need to scan in an airgap environment.

2. In our workflows, we are already logging into the relevant docker registries, but it doesn't look like there is a way to use our existing docker config for the authorization. Does it always use the --registry-creds flags to make a new docker config? If so can we can an option to skip that and pass in our own docker config (we can volume mount it if the app can back off on trying to make it's own config).

Issue 2 above is actually less important if Issue 1 is fixed because it won't be trying to pull images anyway then.

Thanks!

[naveensrinivasan]

@ericwyles With the change that @partkyle is making, we would address both. Thanks

defenseunicorns/uds-security-hub#138
defenseunicorns/uds-security-hub#149