Search code examples
javaspringspring-bootgopaketo

Golang build packs using spring boot 3 bootBuildImage?

I am using spring boot v3.1.5, and I build my image using bootBuildImage. I find a lot of CVEs regarding golang after scanning my image. From my understanding there are multiple golang build packs being used in the process of image building.

Is there a way to tackle this? Can I configure spring to avoid using those packs?

I tried configuring the used build packs with no luck. I would like to have zero golang related files in my created image.

Solution

  • I am using spring boot v3.1.5, and I build my image using bootBuildImage.

    Excellent!

    I find a lot of CVEs regarding golang after scanning my image. From my understanding there are multiple golang build packs being used in the process of image building.

    No, that's not correct. When you build a Java app, it only uses the Java-related buildpacks. It does not use any Go buildpacks. You can see in the output of your build the list of buildpacks it utilizes. It'll look something like this. The buildpacks listed in DETECTING are the only buildpacks that get invoked.

    ===> DETECTING
6 of 26 buildpacks participating
paketo-buildpacks/ca-certificates   3.6.6
paketo-buildpacks/bellsoft-liberica 10.4.2
paketo-buildpacks/syft              1.39.0
paketo-buildpacks/executable-jar    6.8.2
paketo-buildpacks/dist-zip          5.6.7
paketo-buildpacks/spring-boot       5.27.5

    What you might be confusing here is that all of the Paketo buildpacks themselves are written in Golang. So if you were to pick a buildpack image, like gcr.io/paketo-buildpacks/bellsoft-liberica, you would see that there is a Go binary at /cnb/buildpacks/paketo-buildpacks_bellsoft-liberica/10.4.2/bin/main. This is what gets invoked during detect and build, and what actually performs the operations of the buildpack.

    In addition, there are actions that the buildpack executes before your application starts at runtime, for example configuring JVM settings, and these are performed by a separate binary called helper (same directory of the buildpack image). This binary, unlike main, is copied into the final image, so your scanner is correct that there is a Go binary in the image. It is the helper binary. If you look at your app image with dive, you can see the layer that adds the helper binary and confirm this.

    Your scanner will see this binary and scan it like everything else. It is able to tell from the binary what version of Golang created the binary, and from there it will tell you that the binary file is potentially vulnerable to any known CVEs for that version of Go or greater.

    The scanner has zero context on what the binary does or whether it's actually vulnerable to any of the CVEs though. I do not know what CVEs you're referring to, but I can tell you that given the context of Paketo buildpack helper binaries, most CVEs will not be applicable. For example, anything that's related to a server, networking, or HTTP is not relevant. The helper binary is a CLI that runs and typically reads arguments/environment variables and then prints out some structured text. That's it, typically no servers, networking, or HTTP.

    If you have specific questions about a CVE and its impact, you can ask on the Paketo Slack but do not just dump the list of CVEs from your scanner there and expect someone to go through them all for you. Please realize that the project is an OSS project, folks respond out of the goodness of their heart and will respond as time permits. If you need more help than that or want guaranteed response times then you'll want to look at contracting with a commercial buildpacks vendor.

    Is there a way to tackle this? Can I configure spring to avoid using those packs? I tried configuring the used build packs with no luck. I would like to have zero golang related files in my created image.

    It is not possible to remove the Golang files, they are essentially the buildpack.

    What you can do:

    1. Keep your builder and buildpacks updated. The Paketo project cuts new releases weekly and we aggressively keep Go up-to-date so that new releases have all of the latest fixes.

    2. Examine the reported CVEs, there should not be many if you are keeping up-to-date. They will most likely be irrelevant given the context of the buildpack binaries (see above), and then you can tell your scanner to ignore them. They should go away shortly, because of 1.)

    3. Because you're using Spring Boot build tools, please make sure that you've seen this announcement and have applied the required changes. If you do not do this, you will absolutely get a lot of CVEs, because you'll have very old buildpacks.