I’m working on getting a self-hosted penpot up and running behind a corporate firewall. Our policy for having services up and running requires that we mitigate risks where possible. I have all of the containers building, then I am conducting a scan with syft to produce an SBOM, and grype to produce a list of vulnerabilities from that SBOM. This generates a list for each container with several Critical and High library vulnerabilities and dozens of other vulnerabilities for each container. Several dependencies contain a “fixed in” version that I would like to use.
I am NOT a Clojure developer in any way, shape, or form. That said, I’ve tried every way I can find to override, replace, or include newer versions of libraries included. As an example, grype returns dozens of CVEs for jackson-databind in exporter (here is an example CVE: NVD - CVE-2020-9547 (nist.gov)). Since this is a transitive dependency, I thought I could add :override-deps for a newer version of jackson-databind to the :build alias in deps.edn for exporter. However, this did not make any difference in a subsequent scan - the dependency did not get replaced or overridden.
How can I override multiple transitive dependencies to use an existing “fixed in” version to negate these CVEs?
Overriding transitive dependency has its trade-offs, I mean, you are changing a dependency that may changed the behavior (breaking the promise of not break changes on patch versions, or no patch version available and you need to update to the next minor, that evidently can introduce not evident changes).
But independently of this, for override dependency, it depends on the package. For example frontend and exporter, you need to rebuild the app modifying the deps.edn accordingly, including a new version of library and excluding it from the library which includes it transitively.
Now, speaking on the concrete case of jackson-databind in exporter. That is a JVM library, and exporter is written on CLJS (which uses JVM only for compilation). In this concrete case, the jackson-databind is only included at compile time and has no effect on runtime (no way to use it because that is JVM library, which can’t execute on nodejs). Also, there are no use of jackson-databind on exporter at compile time at all, so this library is probably included transitively by some library that in reality not used. So the vulnerability is completely irrelevant.
If you are concerned by some transitive dependency on backend, in this case, consider opening an issue for upgrading them. We can release patch versions with dependencies updated.
But independently of this, for override dependency, it depends on the package. For example frontend and exporter, you need to rebuild the app modifying the deps.edn accordingly, including a new version of library and excluding it from the library which includes it transitively.
What does this look like in terms of code? Just a quick, arbitrary example of an exclusion and an override would help me understand so much.
Also, there are no use of jackson-databind on exporter at compile time at all, so this library is probably included transitively by some library that in reality not used. So the vulnerability is completely irrelevant.
That’s great news, but maybe my next question is, then why is it showing up in the SBOM for the container? Could the container definition be updated to incorporate a multi-stage build? This would likely not only clean up the SBOM, but also make the image smaller.
If you are concerned by some transitive dependency on backend, in this case, consider opening an issue for upgrading them. We can release patch versions with dependencies updated.
Okay. I can do that as necessary for backend. Thanks!
