"dependencies": {
- "express": "4.17.1"
+ "express": "4.17.3"
}
```
Rebuild the image with a new tag and push it to your Docker Hub repository:
```console
$ docker build --push -t <ORG_NAME>/scout-demo:v2 .
```
Run the `docker scout` command again and verify that HIGH CVE-2022-24999 is no longer present:
```console
$ docker scout cves --only-package express
✓ Provenance obtained from attestation
✓ Image stored for indexing
✓ Indexed 79 packages
✓ No vulnerable package detected
## Overview
│ Analyzed Image
────────────────────┼───────────────────────────────────────────────────
Target │ mobywhale/scout-demo:v2
digest │ ef68417b2866
platform │ linux/arm64
provenance │ https://github.com/docker/scout-demo-service.git
│ 7c3a06793fc8f97961b4a40c73e0f7ed85501857
vulnerabilities │ 0C 0H 0M 0L
size │ 19 MB
packages │ 1
## Packages and Vulnerabilities
No vulnerable packages detected
```
## Step 5: Evaluate policy compliance
While inspecting vulnerabilities based on specific packages can be useful,
it isn't the most effective way to improve your supply chain conduct.
Docker Scout also supports policy evaluation,
a higher-level concept for detecting and fixing issues in your images.
Policies are a set of customizable rules that let organizations track whether
images are compliant with their supply chain requirements.
Because policy rules are specific to each organization,
you must specify which organization's policy you're evaluating against.
Use the `docker scout config` command to configure your Docker organization.
```console
$ docker scout config organization <ORG_NAME>
✓ Successfully set organization to <ORG_NAME>
```
Now you can run the `quickview` command to get an overview
of the compliance status for the image you just built.
The image is evaluated against the default policy configurations. You'll see output similar to the following:
```console
$ docker scout quickview
...
Policy status FAILED (2/6 policies met, 2 missing data)
Status │ Policy │ Results
─────────┼──────────────────────────────────────────────┼──────────────────────────────
✓ │ No copyleft licenses │ 0 packages
! │ Default non-root user │
! │ No fixable critical or high vulnerabilities │ 2C 16H 0M 0L
✓ │ No high-profile vulnerabilities │ 0C 0H 0M 0L
? │ No outdated base images │ No data
? │ Supply chain attestations │ No data
```
Exclamation marks in the status column indicate a violated policy.
Question marks indicate that there isn't enough metadata to complete the evaluation.
A check mark indicates compliance.
## Step 6: Improve compliance
The output of the `quickview` command shows that there's room for improvement.
Some of the policies couldn't evaluate successfully (`No data`)
because the image lacks provenance and SBOM attestations.
The image also failed the check on a few of the evaluations.
Policy evaluation does more than just check for vulnerabilities.
Take the `Default non-root user` policy for example.
This policy helps improve runtime security by ensuring that
images aren't set to run as the `root` superuser by default.
To address this policy violation, edit the Dockerfile by adding a `USER`