defenseunicorns / uds-software-factory

🏭 UDS Software Factory Integration / Wayfinding Repo
GNU Affero General Public License v3.0
9 stars 1 forks source link

Add Continuous CVE and License Scanning to repository CI #28

Open Racer159 opened 8 months ago

Racer159 commented 8 months ago

Describe what should be investigated or refactored

We should add continuous scanning of image dependencies in UDS Software Factory package repositories to check for both CVEs and license changes.

Links to any relevant code

https://github.com/defenseunicorns/zarf/blob/main/.github/workflows/dependency-review.yml https://github.com/defenseunicorns/zarf/blob/main/.github/workflows/scan-cves.yml

Additional context

We will have to setup a system in uds-common that parses a zarf.yaml to get the correct references. This should be tested on GitLab first, and once approved can be pushed across the SWF repositories.

### Tasks
- [ ] gitlab
- [ ] gitlabrunner
- [ ] mattermost
- [ ] sonarqube
- [ ] uds-software-factory
naveensrinivasan commented 8 months ago

License and Vulnerabilities

GitHub becomes the central place for all vulnerabilities and license issues. We want to track all the issues in GitHub. We want all the results to be in SARIF format so that they can be integrated into GitHub.

Anchore

I've researched Anchore Grype and Grant for vulnerability scanning and license scanning. They are two different tools for these purposes.

Grype has a GitHub action that can publish the results to GitHub in SARIF format, making it easier to track and address issues. https://github.com/anchore/scan-action?tab=readme-ov-file#example-workflows

On the other hand, Grant, which is a license scanner, doesn't have the option to export to GitHub in SARIF format.

Aquasec

Aquasec Trivy has a single tool for both vulnerability and license scanning. Trivy GitHub Action can export vulnerability and license issues to GitHub with the support of SARIF.

Container Images

The container images https://raw.githubusercontent.com/defenseunicorns/uds-package-gitlab/main/values/upstream-values.yaml are defined here in our custom format, and we would have to parse this file and extract every image:tag to pass to the scanner to scan for Vuln and License issues.

The goal is to create a parser to take this file and return images and tags. The parser should be generic so that it can be used across repositories.

Scan

The scan should run on a cron (once daily) and whenever there is a PR. The daily cron job is required to identify new vulnerabilities for the existing images.

SBOM

These tools also allow us to generate SBOM, which helps in tracking all its deps for Vulnerabilities and License changes using something like guac

References

  1. https://github.com/aquasecurity/trivy
  2. https://github.com/aquasecurity/trivy-action
  3. https://github.com/anchore/scan-action
  4. https://github.com/anchore/grype
  5. https://github.com/anchore/grant
zachariahmiller commented 8 months ago

A few fairly fragmented thoughts... Not sure if we need a custom parser, that should maybe be a last resort, particularly if it is some standalone thing rather than in the code base of one of our already established tools.

fwiw. Zarf is already parsing the images and using that for the sbom generation. https://github.com/defenseunicorns/zarf/blob/9277bdcbd63bcc7b5da6ecaf055603f9aa7e05cd/src/internal/packager/sbom/catalog.go#L74

Not sure if we could or would want to bring grype into zarf (probably not), but if we could something similar could be done to generate a cve report for the images. Regardless of whether we took an approach like that, surely somewhere in here we could provide an option to output a more easily machine readable version of the current list of images to pass into grype or another tool. It honestly might be a better fit to do in uds-cli... idk.

I think you can also get license information for all the included tools out of the sboms that are already being generated but that might be gross. @Racer159 any thoughts on the above since you have much more context on our tools?

Also not sure that we want to lean into these specific github actions, while these particular ones are probably well maintained, it ties these processes to github and we are developing a solution based around gitlab so whatever we can make generic to reuse is better.

That might mean just running the commands from uds tasks, it might mean a combination of that and the upload action.

zachariahmiller commented 8 months ago

just to add another note. If we took a less invasive approach and just wanted to do less pleasant things in uds tasks/bash. The images are outputted by the sbom generator with the filename being the image ref with : and - replaced by _... would be pretty easy to get that back to what would be needed for a scanning tool. Not my favorite approach, but minimally invasive to other projects and would get the job done. image

Racer159 commented 8 months ago

Just putting it here so it is visible in the issue, but product security releases will also need to be scraped since grype won't find the main package sometimes - GitLab has a few ways to get after this (potentially parsing the website, rss, or looking for other files they may have): https://about.gitlab.com/releases/categories/releases/

zachariahmiller commented 7 months ago

I started playing around with a way to query that github cve repo from Mitre and get some output. didnt get very far but able to get new/updated cves based on product https://github.com/zachariahmiller/ubiquitous-spoon

oates commented 2 weeks ago

@dekkagaijin or @partkyle do you know if License Scanning will be a feature in Security Hub? That will help us understand how we will proceed with this.