One of Riscosity's goals is to discover and provide visibility of third party vendors that organizations use. In this spirit, we strive to make sure that the dependencies related to Riscosity aren’t inherently risky or have security vulnerabilities that would increase the risk of a data breach.
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.
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.
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.
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!