# Examples

## Know what you deploy

Imagine that you download and run a Python application in your cluster. Which one do you prefer and why given the following `Dockerfile`:

```Dockerfile
FROM python:latest
RUN pip install redis
RUN pip install requests
COPY worker.py /
CMD ["python", "worker.py"]
```

```Dockerfile
FROM python:alpine
RUN pip install redis
RUN pip install requests
COPY worker.py /
CMD ["python", "worker.py"]
```

---

## The only difference is the base image

But the end result is quite different:

| Base image | Image size | CVE's |
|---|---|---|
| python:latest | 888 Mb | 1114 |
| python:alpine | 73,5 Mb | 3 |

(Scanning was done with `grype` and since the writing of this presentation the numbers have increased)

---

## Using SBOMs to obtain foreknowledge of CVE's

Knowing upfront which CVE's could be deployed is a check that can be done easily if the SBOM file is available.

This can be a local file created inside a pipeline or an external file pulled during a build run.


```bash
❯ grype python.json
 ✔ Vulnerability DB                [no update available]
 ✔ Scanned for vulnerabilities     [1644 vulnerability matches]
   ├── by severity: 19 critical, 335 high, 473 medium, 74 low, 721 negligible (22 unknown)
   └── by status:   261 fixed, 1383 not-fixed, 0 ignored
NAME            INSTALLED        FIXED-IN     TYPE     VULNERABILITY        SEVERITY
apt             2.2.4                         deb      CVE-2011-3374        Negligible
bash            5.1-2+deb11u1    (won't fix)  deb      CVE-2022-3715        High
binutils        2.35.2-2                      deb      CVE-2023-25588       Negligible
```

(This SBOM was created with the following command: `syft --output  spdx-json  python-latest:latest > python.json`)

---

## Analyzing SBOMS in registries

```bash
$ cosign verify-attestation --key /path/to/cosign.pub --type cyclonedx <IMAGE> > sbom.cdx.intoto.jsonl
$ trivy sbom ./sbom.cdx.intoto.jsonl

sbom.cdx.intoto.jsonl (alpine 3.7.3)
=========================
Total: 2 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 2)

┌────────────┬────────────────┬──────────┬───────────────────┬───────────────┬──────────────────────────────────────────────────────────┐
│  Library   │ Vulnerability  │ Severity │ Installed Version │ Fixed Version │                          Title                           │
├────────────┼────────────────┼──────────┼───────────────────┼───────────────┼──────────────────────────────────────────────────────────┤
│ musl       │ CVE-2019-14697 │ CRITICAL │ 1.1.18-r3         │ 1.1.18-r4     │ musl libc through 1.1.23 has an x87 floating-point stack │
│            │                │          │                   │               │ adjustment im ......                                     │
│            │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2019-14697               │
├────────────┤                │          │                   │               │                                                          │
│ musl-utils │                │          │                   │               │                                                          │
│            │                │          │                   │               │                                                          │
│            │                │          │                   │               │                                                          │
└────────────┴────────────────┴──────────┴───────────────────┴───────────────┴──────────────────────────────────────────────────────────┘
```

`cosign` is used to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more.

???
Example taken from: https://aquasecurity.github.io/trivy/v0.33/docs/attestation/sbom/

---

## Deployment prevention in pipeline

Inspecting SBOMs is best done before deploying containers and friends. Prevention is always best.

The OCI standard allows storing SBOM information in container registries which could be nice for future use.

The docker buildkit has builtin functionallity, eg: `docker buildx build --sbom=true -t <myorg>/<myimage> --push .` will automaticcaly create a SBOM and push it to the registry.

SBOMs can be generated by other commands as well and stored in other places.

Consider analyzing the information of the SBOM in a deployment pipeline and take action if necessary.

---

## Storing SBOM information

Often CVE's are discovered after deployment.

Scanning a collection of SBOMs to see if the new CVE's affect the deployments is a relative cheap and quick process which can be done automaticcaly at regular intervals.

Depending on the tools or application the SBOM info is stored in a container registry (e.g. docker buildx), filesystem (e.g. syft), configmap (e.g. kubeclarity) or a database (e.g. dependency track)

---
class: pic

## CVE's increase over time

.center[![sbom](images/sbom/Dependency-Track_-_Dashboard.png)]

---

## Stored SBOM's

Imagine that we store SBOM information in Dependency Track, or any other suitable application.

Today a new zero day exploit is detected. How cool would it be to identify which host, devices, images etc. are affected without rescanning?

The zero day is reported as `CVE-2023-49568`

---
class: pic

## Search for `CVE-2023-49568`

.center[![sbom](images/sbom/DT-CVE-search.png)]

---
class: pic

## Obtain info about CVE

.center[![sbom](images/sbom/DT-CVE-info.png)]

---
class: pic

## Identify related projects

.center[![sbom](images/sbom/DT-CVE-projects.png)]
