@kushal
Software Bill of Materials became one of the latest buzzword. A lot of people and companies talking about it like a magical thing, if you use it then all of your security problems will be solved, just like what happened with Blockchain!!.
Though a hand full of projects (or companies building those projects) focused on the actual tooling part. Things we can use and see some useful output than blogposts/presentations with fancy graphics.
In this post we will try to see how can we use these tools today (2023/09/20).
SBOM currently comes in two major flavors, SPDX aka Software Package Data Index and CycloneDX. There are existing tooling to convert in between.
Syft
We will use syft from Anchore to generate our SBOM(s).
This tool can generate from various sources, starting from container images to Python projects, RPM/Debian dbs, Rust or Go projects.
Let us generate the SBOM for a Debian 12 VM.
$ syft /var/lib/dpkg -o spdx-json=server.spdx.json --source-name debian12
✔ Indexed file system /var/lib/dpkg
✔ Cataloged packages [395 packages]
For for a Rust project:
$ syft /home/kdas/code/johnnycanencrypt/Cargo.lock -o spdx-json=jce.spdx.json
✔ Indexed file system /home/kdas/code/johnnycanencrypt
✔ Cataloged packages [203 packages]
We generated the SBOMs. Now this should solve the security issues, isn't?
I found the above in Matthew Martin's timeline.
Grype
This is where Grype comes handy, it is a vulnerability scanner for container images and filesystems and works with the SBOM(s) generated by syft.
$ grype jce.spdx.json
✔ Vulnerability DB [updated]
✔ Scanned for vulnerabilities [1 vulnerability matches]
├── by severity: 0 critical, 0 high, 1 medium, 0 low, 0 negligible
└── by status: 1 fixed, 0 not-fixed, 0 ignored
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
time 0.1.45 0.2.23 rust-crate GHSA-wcg3-cvx6-7396 Medium
And:
grype server.spdx.json
✔ Vulnerability DB [no update available]
✔ Scanned for vulnerabilities [178 vulnerability matches]
├── by severity: 6 critical, 136 high, 34 medium, 2 low, 0 negligible
└── by status: 0 fixed, 178 not-fixed, 0 ignored
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
file 1:5.44-3 CVE-2007-1536 High
git 1:2.39.2-1.1 CVE-2020-5260 High
gnupg 2.2.40-1.1 CVE-2022-3515 Critical
gnupg 2.2.40-1.1 CVE-2022-34903 Medium
gnupg 2.2.40-1.1 CVE-2022-3219 Low
openssl 3.0.9-1 CVE-2023-4807 High
openssl 3.0.9-1 CVE-2023-3817 Medium
openssl 3.0.9-1 CVE-2023-2975 Medium
openssl 3.0.9-1 CVE-2023-1255 Medium
perl 5.36.0-7 CVE-2023-31486 High
perl 5.36.0-7 CVE-2023-31484 High
vim 2:9.0.1378-2 CVE-2022-3520 Critical
vim 2:9.0.1378-2 CVE-2022-0318 Critical
vim 2:9.0.1378-2 CVE-2017-6350 Critical
vim 2:9.0.1378-2 CVE-2017-6349 Critical
vim 2:9.0.1378-2 CVE-2017-5953 Critical
vim 2:9.0.1378-2 CVE-2023-4781 High
vim 2:9.0.1378-2 CVE-2023-4752 High
<snipped>
Now it is on your team members to decide how to react to information we gather from these tools. The tools themselves will not solve the problems at hand. You have to decide the update steps and if that is at all required or not.
Also please remember, there is and will be a lot of false positives (not in Grype output yet, but other tools in the SBOM ecosystem). The projects (I am talking about in general most of the tooling in this field) are trying hard to reduce these, but not possible always to remove every such edge case.
...
