Building Golang packages using Spring Boot 3 bootBuildImage?

I am using spring boot v3.1.5 and using bootBuildImage to build my image. After scanning my images, I found a lot of CVEs related to golang. As far as I understand, multiple golang build packages are used during the image building process.

Is there a way to solve this problem? Can I configure spring to avoid using these packages?

I tried configuring the used buildpack without success. I want to have zero golang related files in the image I create.

Correct answer

Very good!

No, that's incorrect. When you build a Java application, it uses only Java-related build packages. It doesn't use any Go buildpacks. You can see the list of build packages it uses in the build's output. It looks like this. The buildpacks listed in the instrumentation are the only ones called.

===> 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 may confuse you is that All Paketo buildpacks themselves are written in Golang. So if you were to select a buildpack image such as gcr.io/paketo-buildpacks/bellsoft-liberica, you would see /cnb/buildpacks/paketo-buildpacks_bellsoft-liberica/10.4. There is a Go binary at 2/bin /main. This is what is called during instrumentation and building, and what actually does the work of building the package.

Additionally, the buildpack performs some operations before the application runtime is started, such as configuring JVM settings, which are performed by a separate binary named helper (in the same directory as the buildpack image). Unlike main, this binary is copied into the final image, so your scanner correctly thinks that the Go binary is present in the image. It is the helper binary. If you view the application image using dive you can see the layer adding the helper binary and confirm this.

Your scanner will see this binary and scan it like anything else. It's able to tell from a binary which version of Golang created that binary, and from there it tells you that the binary may be vulnerable to any known CVEs for that version of Go or higher. The scanner has zero knowledge about the purpose of the binary or whether it is actually vulnerable to any CVEs. I don't know what CVEs you are referring to, but I can tell you that given the context of the Paketo buildpack

helper binary, most of the CVEs will not apply. For example, anything related to servers, networking, or HTTP is irrelevant. helper The binary is a CLI that runs and usually reads arguments/environment variables and then prints out some structured text. That's it, usually no server, network, or HTTP required.

specific questions about CVEs and their impact, you can ask on the Paketo Slack, but don't just dump the CVE list in the scanner there and expect someone to double check everything. you. Please note that this project is an OSS project and people respond in good faith and as time permits. If you need more help or want a guaranteed response time, then you'll want to consider contracting with a commercial build package provider.

1. Keep your builders and buildpacks updated. The Paketo project cuts new releases every week, and we actively keep Go up to date so that new releases contain all the latest fixes.

2. Check for reported CVEs, if you keep up to date there shouldn't be many. Given the context in which the package binaries are built (see above), they are most likely irrelevant, and you can then tell the scanner to ignore them. They should be leaving soon because 1. )

3. Since you are using the Spring Boot build tools, please make sure you have seen

   this announcement and have applied the required changes. If you don't do this, you will definitely get a lot of CVEs because you will have very old build packages.

The above is the detailed content of Building Golang packages using Spring Boot 3 bootBuildImage?. For more information, please follow other related articles on the PHP Chinese website!