Open-source software is the building materials of the vast majority of digital technology as we know it. Anyone can access and contribute to it, which is great for flexibility and cost, but also means there’s a risk of hidden flaws. In this episode, Stacklok’s CEO Craig McLuckie shares his tools to check the quality and security of open-source software production. Working together as a community, we can make open-source software safer and more reliable for everyone.
Edited transcription
As CEO and co-founder of Stacklok, a software company specializing in supply chain security for open-source software, Craig McLuckie has closely witnessed a shift in the nature of hackers’ methodologies. Accidental vulnerabilities, in which “someone just didn’t anticipate a buffer overflow here, bad stuff happens there,” have given up their place to “a world where hostile actors are actually trying to manipulate the supply chain.” Consequently, security is moving from finding and fixing vulnerabilities from external threats to preventing malicious contributors from creating, nurturing, and preserving vulnerabilities.
With the recent antecedent of the XZ Utils backdoor as the incident of the highest profile, Craig points out that despite the “high importance, high repackaging, high reuse” of open-source “critical supporting technologies,” these, in turn, have “relatively low maintainer engagement.” As the sophistication, dedication, and scale of this attack raise strong suspicions of state-backed actors behind them, these vulnerabilities are not easy to detect, nor to determine their reach: “With these things, you never know what the blast radius is really,” Craig adds.
The ubiquity of open-source software
Security threats of the magnitude of the XZ vulnerability put under the spotlight one of the main positive qualities of open-source software: Collaboration. Fair enough, it may lead to fear and distrust in the open-source community, as free comes with a cost.
However, according to Craig, there’s no such thing as “non-open source” in today’s industry, in which virtually all software relies on open-source components at some level. Whether it’s the programming languages themselves (like Java or Python) or the underlying libraries, frameworks, and operative systems, “open source is basically the underpinning of everything that we build.”
Moreover, Craig argues that when companies choose to work exclusively with proprietary vendors, what they’re really doing is engaging in a “risk adjustment process” or “arbitraging risk.” In other words, these companies aren’t actually avoiding open source; they’re merely shifting the responsibility for managing open source risks to their vendors. However, according to him, this perspective is flawed in as much as the lack of transparency in these vendor relationships doesn’t reduce risk exposure.
The SolarWinds incident, in which a provider of system management tools for network monitoring was compromised by attackers’ malicious code inserted into updates of its platform, is an example of how even when companies choose to work exclusively with proprietary vendors, they are still exposed to the risks associated with open-source software. Even when working with a closed-system vendor, that vendor is still consuming open-source technology—but the customer doesn’t necessarily know what components are being used, how they’re being used, or where they originate from. Hence, these companies are essentially choosing to close their eyes and trust that vendors are behaving responsibly, rather than actively managing these risks themselves.
Stacklok: Addressing supply chain security
“Collaboration just goes away when there’s fear in the ecosystem,” Craig affirms. Still, he is confident that solving the complex issues of software supply chain security requires collaboration from many parties, not just a single vendor or company. Aligned with this philosophy, Craig envisions Stacklock as a “seed crystal” fostering an active community rather than remaining a solitary solution provider.
Stacklok was born out of Craig’s firsthand experience with enforcing supply chain security standards and controls at large tech companies like Google and VMware. Recognizing this as a widespread issue in the open-source community, Craig sought a solution that would provide greater transparency and traceability. Exploring the potential of employing a generic system for labeling software resources, he eventually came across Luke Hein, the creator of Sigstore. Sigstore’s innovative approach to software signing, which “connects a piece of software with information about its inception,” aligned perfectly with Craig’s vision of empowering users to understand the origins and trustworthiness of the software they rely on.
Setting up policies with Minder
The idea behind Stacklok was to give users ”the ability to apply policy” at any stage of the software development life cycle, ensuring that only software meeting predefined standards would integrate into their projects. To this end, Stacklok’s platform Minder enables multiple controls across the entire software development and deployment process. For example, setting policies around Git repositories, to each merge request, container registries, and Kubernetes deployments.
If you’re building software with dependencies, Craig recommends enforcing a policy “that blocks a merge request if there’s a vulnerability” or unfavorable attribute in it, like “bad licensing material, bad reputational scores, or with known CVEs.” Securing dependencies can save developers countless headaches. ”The last thing you want to do is discover a vulnerability and call a scan in production,” he says. As such, he calls to “intercept these things as quickly and early as possible, ideally in the IDEs.”
Minder can also wrap policies around Github actions and repositories, “and set up controls so that your organization can use or not use actions based on where they’re sourced from.” What’s more, you can write your own rules using YAML or Rego policy language.
Judging dependencies with Trusty
While Minder is useful for setting up granular policies, Stacklock’s second product, Trusty, employs sophisticated data science techniques to assist organizations in evaluating the sustainability of software. By providing “high-quality signals intelligence,” Craig explains, Trusty empowers organizations to assess their hypotheses and make informed decisions about the software they adopt, proactively identifying potential sustainability issues before they escalate.
Signals are pieces of information that provide insight into the quality, security, or reliability of a software package or component. According to Craig, it is necessary to not take signals as a given, but to enforce a signaling process or source we can trust: “Unless you actually have a signature, unless you have some firm point of attestation that an identity that’s known to be associated with this package is the identity that published the package and published the signature of the package, you just don’t know.”
Craig asserts that a technology like SIGSTOR is essential for determining the responsible sourcing of the products or services we consume. However, he acknowledges that implementing such technology can be more challenging in open-source projects. In this way, even in the absence of SIGSTOR, Craig believes that Trusty valuable intelligence signals can assist in assessing responsible sourcing.
For signaling packages, Trusty uses historical provenance. Trusty examines the repo and checks associated release tags to find a chain of trust back to the source code: “If the tags and the sort of known versions associated with this package lineup is probably the package you’re looking for,” Craig explains. “If they don’t, it probably isn’t—we would then give it a very low score because we don’t have proof of its historic provenance.”
Trusty also performs principal component analysis, which analyzes a database of bad packages and compares their composition with good packages. According to Craig, this analysis allows users to “build a statistical model so that when we’re looking at something that we’ve never seen before, we can sort of attest whether it’s good or bad.” Trained AI can find patterns that can be correlated with packages falling out of reputation, such as a lack of maintainers. In these cases, the platform will recommend better alternatives.
The bottom line
Stacklok’s roadmap includes new features for private repositories and introduces commercial offerings. Also, while currently focused on GitHub integration, Stacklok is working on expanding to other providers, such as OCI registry provider and Kubernetes provider to continue introducing control points across various stages of the software development lifecycle.
Visit Stacklok.com and github.com/stacklok to learn more about the project and test its product. Join Stacklok’s Discord community to chat directly with its engineers and find out the latest about its products’ development.
Follow Craig on X at @cmcluck. To learn more about his views on supply chain security, check his talk at the Open Source Software Summit Seattle 2024.
