Add instructions for running grype locally

docs/infra/vulnerability-management.md

@@ -1,12 +1,14 @@
 # Vulnerability Management for Docker Images
+
 This repository contains a GitHub workflow that allows you to scan Docker images for vulnerabilities. The workflow, named `ci-vulnerability-scans` is located in the directory `.github/workflows`. The goal in scanning the image before pushing it to the repository is so that you can catch any vulnerabilities before deploying the image, ECR scanning takes time and the image can still be used even with vulnerabilities found by Inspector. Also, if you use `scratch` as a base image, ECR is unable to scan the image when it is pushed, which is a known issue.
 
 A way to ensure that there are smaller surface areas for vulnerabilities, follow this method of building images
+
 - Build base image with required packages, name it something like `build`
 - Configure app build from the image in the previous step, name it something like `app-build`
 - Create a final image from `scratch` named `release` (ie `from scratch as release`), and copy any needed directories from the `app-build` image
 
-```
+```dockerfile
 FROM ... AS build
 # Do base installs for dev and app-build here
 FROM build AS dev
@@ -22,18 +24,33 @@ FROM scratch AS release
 By following this method, your deployment image will have the minimum required directories and files, it will shrink the overall image size, and reduce findings
 
 ## How to use Workflow
+
 The workflow will run whenever there is a push to a PR or when merged to `main` if there are changes in the `app` directory. It is scanning in both cases to ensure there are no issues if a PR is approved on a Friday, but isn't merged till Monday - a CVE could have been found in the time between the last run and the merge.
 
 ## Notes about Scanners
 
 ### Hadolint
+
 The hadolint scanner allows you to ignore or safelist certain findings, which can be specified in the [.hadolint.yaml](../../.hadolint.yaml) file. There is a template file here that you can use in your repo.
 
 ### Trivy
+
 The trivy scanner allows you to ignore or safelist certain findings, which can be specified in the [.trivyignore](../../.trivyignore) file. There is a template file here that you can use in your repo.
 
-### Anchore
-The anchore scanner allows you to ignore or safelist certain findings, which can be specified in the [.grype.yml](../../.grype.yml) file. There is a template file here that you can use in your repo. There are flags set to ignore findings that are in the state `not-fixed`, `wont-fix`, and `unknown`.
+### Anchore (Grype)
+
+The Grype scanner is a Docker image scanner made by the company Anchore. It allows you to ignore or safelist certain findings, which can be specified in the [.grype.yml](../../.grype.yml) file. There are flags set to ignore findings that are in the state `not-fixed`, `wont-fix`, and `unknown`.
+
+To debug a vulnerable system-level dependency of unknown origin, [download the CI-built image](/docs/app/runbooks/running-built-images-locally.md) and run:
+
+```bash
+# Set the image_name variable to the name or URL of an image
+# it can be set to a locally built docker image or an image published to a container image repository such as ECR e.g.
+# [account_id].dkr.ecr.us-east-1.amazonaws.com/[image_name]:[image_tag]
+grype --config .grype.yml -o json --fail-on medium "$image_name" |
+  jq '.matches | map(.artifact | { name, version, "location": .locations[0].path })'
+```
 
 ### Dockle
+
 The dockle scanner action does not have the ability to use an ignore or safelist findings file, but is able to by specifying an allow file, or `DOCKLE_ACCEPT_FILES`, environmental variable. To get around this, before the dockle scan runs, a prior step checks for a file named [.dockleconfig](../../.dockleconfig) and pipes it to the environmental variable if it exists. Note that this will not ignore finding types like the other scanner's ignore file, but ignore the file specified in the list.