Kusari Open-Sources Spector

With the recent release of SLSA v1.0, we’re excited to announce the open-sourcing of Spector, a brand-new tool and library designed to generate, validate, and verify supply chain metadata documents. With Kusari’s committed involvement in SLSA as a contributor and on the steering committee we want to ensure its success through secure and reliable tooling. We’re committed to improving the security and reliability of software, and Spector is our latest contribution to that mission.

Spector’s focus is on enforcing strict compliance to metadata document specifications both in the generation of those documents as well as validation and verification. During our work on GUAC, SLSA, and other projects we noticed a big problem. Too often we see SBOMs and SLSA attestations in the wild that look valid but are missing a field or value constraints are not strictly followed. We can’t possibly start leveraging the content in these documents to help us secure our supply chains if they’re inaccurate, unreliable, or won’t work with tooling because they don’t comply with the framework and specifications they claim to. It’s impossible to get value out of SBOMs and SLSA attestations if they aren’t valid documents. Open-source software supply chain analysis tooling like GUAC relies on the validity and quality of these documents to provide people with the information they need to better secure their supply chains.

Spector aims to achieve these goals by being strict. We are utilizing Rust to develop this tool due to its strong type system and other security-focused features allowing us to easily and strictly enforce compliance with specifications. This strict compliance allows us to check document compliance while also eliminating classes of runtime failures that lead to common security vulnerabilities. Today, it is often too easy to compel a tool to generate or validate not just an inaccurate document but a document that doesn’t comply with the specification at all. This is dangerous as these sorts of things can lead attackers to leverage SBOMs, SLSA attestations, and other documents along with related tooling as attack vectors.

We are also working to integrate with other tools and frameworks like in-toto, Witness, and Sigstore. In-toto, a framework to secure the integrity of software supply chains, is one we’re working with closely being a maintainer of in-toto-golang and in-toto attestations. In-toto’s various specifications on layouts, attestations, and policies, are closely in-line with Kusari’s vision for how to better define, describe, and verify our software supply chains.

Spector is still pre-release but we have built out a library that can strictly generate and validate compliance of SLSA attestations to the SLSA v1.0 provenance specification in-toto attestation document type. We are enforcing not just that based types like strings match strings but that semantically rich types like URLs, timestamps, base64 encoded content, etc. are all valid. In the future we will also be able to actively verify and crosscheck content in SLSA, SBOMs, and other documents utilizing frameworks and tools like in-toto.

As we continue to develop Spector, our focus will be on expanding its capabilities and improving its usability. We’re eager to collaborate with the open-source community to ensure that Spector becomes a tool in the toolchain for anyone working with supply chain metadata.

Spector is still very early on, but we wanted to open-source it early to get community input. What document types do you want to see in Spector? We invite you to try out Spector and contribute to its development. You can find the source code on our GitHub repository. We’re looking forward to your feedback and contributions as we work together to strengthen the security of the software supply chain.

‍