nexus

Leveraging Nexus when Building a Golang Application

For this example, I’m creating a very simple Golang app

package main

import (
        "github.com/beego/beego/v2/server/web"
)

func main() {
        web.Router("/", &MainController{})
        web.Run()
}

type MainController struct {
        web.Controller
}

func (c *MainController) Get() {
        response := map[string]string{
                "message": "Hello World Beego",
                "status":  "success",
        }
        c.Data["json"] = response
        c.ServeJSON()
}

And here’s the required go.mod file:

module hello-beego

go 1.24.7

require github.com/beego/beego/v2 v2.3.8

Next, we’ll set up our Nexus to store the required Golang libraries. First, we start by creating a repository named go-proxy. The remote storage location for this repository will be proxy.golang.org.

We also need to point our Golang build proxy to the Nexus repository by exporting the GOPROXY variable.

$ export GOPROXY= http://localhost:8081/repository/go-proxy/

For more detailed logs, we can pull all our libraries using the following command:

$ GODEBUG=mod=1,gocacheverify=1 go mod tidy -v -x

This will show whether we’re able to pull libraries from the Nexus repository. We can also see the libraries that are being pulled in our Nexus repository.

By following above steps, we can successfully leverage Nexus to manage our Golang dependencies, ensuring a more efficient and controlled build environment.

Using Containerized Nexus as Image Registry for Storing Docker Images

There are alot of image registries when we are talking about docker images, such as Quay, Docker Hub, or Nexus. And on this writing, we are trying to create a docker image repository by using Nexus.

Lets start by installing Nexus to our system,

docker run -d -p 8081:8081 -p 7000:7000 --name nexus sonatype/nexus3

After logging in by using admin credentials, and yes we need to read the generated password which is located at /nexus-data/admin.password, we need to update our admin password and after that we can create a new docker image repository.

and create a new repository by using a docker (hosted) recipe. Open port 7000 for http connection

we can test login to our Nexus image repository by using below docker command,

$ docker login localhost:7000

try pulling a new image from external, and push it into our newly created Nexus

$ docker pull alpine
Using default tag: latest
latest: Pulling from library/alpine
59bf1c3509f3: Pull complete
Digest: sha256:21a3deaa0d32a8057914f36584b5288d2e5ecc984380bc0118285c70fa8c9300
Status: Downloaded newer image for alpine:latest

tag it, and push into Nexus image repository,

$ docker tag alpine localhost:7000/dev/alpine

$ docker push localhost:7000/dev/alpine

and finally we can see our images in Nexus.

Do A Maven Owasp Library Scan from A Restricted Network

When we talk about DevSecOps, we are talking about a continous integration and delivery but embedded with a security scanning along the way. And one of the best tool for doing a security scanning for your application library is OWASP dependency-check, and thankfully we can embed it to our application and run it thru pipeline by using a Maven plugin.

There is a downside tho, Owasp Maven plugin need to update its vulnerability database regularly online from NVD database which is perhaps not convenient for most enterprise environment where online network access is very-very limited.

But there is one workaround, we can use our repository such as Nexus or JFrog to host our NVD vulnerability database. The concept is pretty much we can see on below diagram,

There are two repository needed to build for fulfilling Maven Owasp requirement. One for java library, and another one for javascript.

Once done, we can check our Maven Owasp scan by using this command,

mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=8 \
 -DcveUrlModified=http://nexus.example.com/repository/nvd/feeds/json/cve/1.1/nvdcve-1.1-modified.json.gz \
 -DcveUrlBase=http://nexus.example.com/repository/nvd/feeds/json/cve/1.1/nvdcve-1.1-%d.json.gz \
 -DretireJsUrl=http://nexus.example.com/repository/retireJsUrl/jsrepository.json -DretireJsAnalyzerEnabled=false \ 
 -DossindexAnalyzerEnabled=false

If build is success, we can see that both our newly-created repository folder is now have multiple files there,

And if failed, we can see this error happen

And if you want to ignore Owasp scan result, you can change failBuildOnCVSS parameter to 11.