How to help development teams to fix vulnerable packages identified by Syft?

Syft
1

Hello, I am currently using a combination of Syft (for generating SBOMs) + Dependency-Track as our SCA solution. This combination works fine but I am having trouble helping the development teams to fix vulnerabilities because from time to time, Dependency-Track will find a vulnerable package and the development team will try to update the package.json or pom.xml file to load the version of the package without vulnerabilities but a lot of the time the vulnerable package is still appearing on Dependency-Track.

Most of this application are docker and my guess is that the development team just don’t have the knowledge to find where the vulnerable package is and to fix it. Example: We had a case where our tools were accused of being wrong, just for me to note that they were using an old image of Node that had the vulnerability. They tried to fix by updating the package.json and it (obviously) didn’t work because the vulnerability was on the Node image.

My question is, is there a way, a process or another tool that I can use to help them identify where the vulnerable package is so the can fix it?

Is there a way to, using syft, to generate something of a dependency tree of something that help us identify where the vulnerable package is (or if it is a transitive package)? Are there other tool that can help with that by being integrated in this process along with Syft?

Any recommendations?

1 Like
2

Have you tried grype explain?

For example, let’s take an old node image:

Make the SBOM

$ syft node:20.16.0-bullseye -o syft-json=sbom_node20.16.0-bullseye.json
 ✔ Loaded image node:20.16.0-bullseye
 ✔ Parsed image sha256:b68d497309d66f8e2a23c53b5e01f88fa22a3e0031ea445ea7cb7a42492ccb08
 ✔ Cataloged contents b1932f3cdcea2604f37e65697557135380ff28032da4bbf2db15126b20f2d4f0
   ├── ✔ Packages                        [618 packages]
   ├── ✔ File digests                    [19,240 files]
   ├── ✔ File metadata                   [19,240 locations]
   └── ✔ Executables                     [1,309 executables]

Build a vulnerability report

Write to a json file and a table to the screen.

$ grype sbom_node20.16.0-bullseye.json -o json=vuln_node20.16.0-bullseye.json -o table | grep Critical | head -n 5
 ✔ Scanned for vulnerabilities     [1203 vulnerability matches]
   ├── by severity: 28 critical, 447 high, 864 medium, 69 low, 845 negligible (385 unknown)
   └── by status:   408 fixed, 2230 not-fixed, 1435 ignored
curl.   7.74.0-1.3+deb11u12    (won't fix)              deb CVE-2023-23914 Critical
git.    1:2.30.2-1+deb11u2      1:2.30.2-1+deb11u3      deb CVE-2024-32002 Critical
git-man 1:2.30.2-1+deb11u2      1:2.30.2-1+deb11u3      deb CVE-2024-32002 Critical
libaom0 1.0.0.errata1-3+deb11u1 1.0.0.errata1-3+deb11u2 deb CVE-2024-5171 
 Critical
libaom0 1.0.0.errata1-3+deb11u1 (won't fix)             deb CVE-2023-6879  Critical

Use Grype Explain on one of the issues

$ grype sbom_node20.16.0-bullseye.json -o json | grype explain --id=CVE-2024-32002
[0000]  WARN grype explain is a prototype feature and is subject to change
 ✔ Scanned for vulnerabilities     [1203 vulnerability matches]
   ├── by severity: 28 critical, 447 high, 864 medium, 69 low, 845 negligible (385 unknown)
   └── by status:   408 fixed, 2230 not-fixed, 1435 ignored
CVE-2024-32002 from nvd:cpe (Critical)
Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule's worktree but into a `.git/` directory. This allows writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. If symbolic link support is disabled in Git (e.g. via `git config --global core.symlinks false`), the described attack won't work. As always, it is best to avoid cloning repositories from untrusted sources.
Related vulnerabilities:
    - debian:distro:debian:11 CVE-2024-32002 (Critical)
Matched packages:
    - Package: git, version: 1:2.30.2-1+deb11u2
      PURL: pkg:deb/debian/git@1%3A2.30.2-1%2Bdeb11u2?arch=arm64&distro=debian-11
      Match explanation(s):
          - debian:distro:debian:11:CVE-2024-32002 Direct match (package name, version, and ecosystem) against git (version 1:2.30.2-1+deb11u2).
      Locations:
          - /usr/share/doc/git/copyright
          - /var/lib/dpkg/info/git.conffiles
          - /var/lib/dpkg/info/git.list
          - /var/lib/dpkg/info/git.md5sums
          - /var/lib/dpkg/info/git.postinst
          - /var/lib/dpkg/info/git.postrm
          - /var/lib/dpkg/info/git.preinst
          - /var/lib/dpkg/info/git.prerm
          - /var/lib/dpkg/status
    - Package: git-man, version: 1:2.30.2-1+deb11u2
      PURL: pkg:deb/debian/git-man@1%3A2.30.2-1%2Bdeb11u2?arch=all&distro=debian-11&upstream=git
      Match explanation(s):
          - debian:distro:debian:11:CVE-2024-32002 Indirect match; this CVE is reported against git (version 1:2.30.2-1+deb11u2), the origin of this deb package.
      Locations:
          - /usr/share/doc/git-man/copyright
          - /var/lib/dpkg/info/git-man.list
          - /var/lib/dpkg/info/git-man.md5sums
          - /var/lib/dpkg/status
URLs:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-32002
    - https://security-tracker.debian.org/tracker/CVE-2024-32002

Is that what you’re after?

3

Hello Popey, sorry for the delayed answer and thanks for the answer!

I don’t think this is quite the answer that I need. I see that grype shows the locations that this package has been detected and syft works well for this information on some archetypes, like node.js, that installs the packages in the node_modules folder and by following the path we can easily detect transitive dependencies. Is this path generated by grype itself or syft’s sbom? I am not that familiar with grype.

But in languages like java, the syft sbom just report the lib path as being in the .jar file, which doesn’t help the devs on detecting which direct dependency (usually detected in the manifest) is using the transitive vulnerable package.

The challenge that I am facing is identifying how to fix transitive vulnerabilities on java, for example. From time to time, syft will detect packages that are not actually declared in the manifest and the devs are finding it hard to discover which direct dependency they have to update to fix it.

I know that exists some plugins on maven for example like mvn dependency:tree but I am more of a cybersecurity guy and I don’t have a background in development so this is proving kind of difficult for me.

I tried using trivy to compare with the Syft results but I don’t think that trivy is as thorough as syft, but trivy can provide the dependency-tree. Also there results as usually not that comparable.

PS: I mentioned JAVA but i am looking for a solution for all archetypes that syft supports. I mentioned java because we have lot projects on maven here and problem arises from time to time.