Riscosity’s Approach to Managing Dependencies

According to Security Score Card in 2024 35.5% of breaches were related to third party access. Our software is primarily written in Go and we wanted to share our strategy for managing dependencies.

The Power of Go

At Riscosity, we keep our third party dependencies low by keeping up to date with the Go standard library as we release new versions of our product. Go has a robust standard library which allows us to avoid reliance on third party libraries and keep our risk factors low. If there’s functionality that isn’t directly available in the Go standard library, we prefer to build functionality ourselves rather than introduce new third party libraries. For example, prior to Go 1.21, we had built our own version of the slices package that Go later introduced into the standard native library. Once it was introduced, we replaced our custom slices functionality with Go’s native slices functionality.

We take simple steps to keep our dependency risk low by taking advantage of Go’s built-in dependency management and updating dependencies with the following commands:

go get -u

go mod tidy

Go get -u will grab all the available updates for the modules in go.mod and go mod tidy will clean up any mismatch between the go.mod file and the source code. So when we do use 3rd party libraries, we stay up to date with the latest updates. And when we reduce dependencies, we get the benefit right away as well, as we don’t include unused dependencies.

Security Through Dogfooding

At Riscosity we use our own software, and that includes our code scanner. While our code scanner is primarily designed for discovering API usage and data types, it will also pick up any CVEs present in the scanned code base. Where it’s appropriate to introduce 3rd party libraries, we want to fully understand exposure introduced by 3rd party libraries. Beyond using our code scanner to find CVEs, we look at the release history, commits, and code base. We especially want to make sure that the software we pick won’t be abandoned after putting in the time to integrate it with our platform. A project we’ve had success with is go-chi which we feel serves as a great example of properly maintaining and supporting open source code, and was a suitable replacement for mux (github.com/gorilla/mux), as mux was not being actively maintained anymore.

Vendor Transparency

The Riscosity team believes in transparency. One reason we feel comfortable sharing details on how we’ve built our platform is that we’re happy to share our own Software Bill of Materials (SBOM) with any customers, partners, or prospective customers who place high importance on the dependencies used in our applications as a metric of the quality of applications

If you want to learn more about how you can use Riscosity for vendor discovery and visibility, data flow to those vendors, and securing those data flows, book-a-demo!