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 how our engineering team approaches managing dependencies.

The Power of Go

At Riscosity we keep our dependencies low by keeping up to date with the Go standard library as we cut new releases. 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 library themselves. Once it was introduced we were able to replace the custom functionality we had built.

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. When they reduce their dependencies we get the benefit right away as well.

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 is appropriate to introduce 3rd party libraries, we want to fully understand the additional 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.

Wrapping Up

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.

If you want to learn more about how you can use Riscosity to discover your vendors, data flow to those vendors, and secure those data flows, feel free to book time with our team!