From hijacked updates to compromised open source code, software supply chain attacks don’t seem to be slowing down. Over the course of 2021, 62% of organizations faced attacks. Securing the supply chain can be challenging due to its many components and the numerous opportunities for exploitation from cybercriminals. Scribe Security, a cybersecurity company specializing in the software supply chain, is aiming to make security a standard that’s easy to uphold.
Scribe is releasing a code integrity validator (Scribe Integrity) that verifies and authenticates proprietary and open source code. For developers, this will provide more transparency for ensuring code doesn’t have any malicious components. In an interview with The New Stack, Scribe Security, CTO and founder Danny Nebenzahl said, “It’s not something in the current toolbox of DevSec. Unfortunately, in many areas, security does not come first.”
Paired with Scribe Integrity’s release is an open source Github security project from the company. GitGat is a free policy-as-a-code tool whose features allow users to run reports that supply an overarching view of a business’ security position by using the OPA (Open Policy Agent) policy manager. Both products are in early stages but with the state of security in open source software, CEO and co-founder Rubi Arbel says the market is long overdue for these tools. “Better security is crucial for open source technology’s survival. If people don’t trust open source, they won’t use it.”
The Quest for Software Integrity
According to Nebenzahl, Scribe’s approach to securing against open source and supply chain attacks is focusing on the artifacts. Regarding code with a neverending suspicion, Nebenzahl says, “When an artifact is created, we tell it that it’s guilty unless it can prove otherwise. At that point, metaphorically, the artifact should collect evidence that will prove its innocence. Along that pipeline, policies can be evaluated.”
What can be classified as evidence? Nebenzahl says it varies. “Integrity of materials and processes or the final artifacts, proof that nothing was modified. It could also be things that have to do with processes, like did the right people sign off on what they needed to? It could have to do with the security of the factory — are the gates locked?” This evidence collection capability is a part of what Scribe calls their bottom-up concept. On the other side is the “top-down description”, where employees in higher roles can use insights from the data for compliance and other matters.
“These insights are what connects the bottom-up and top-down approach. The DevSecOps guy is worried if the code was modified. The Cisco guy is more worried about ‘Did we comply with the SDF?’ Which requires integrity and preservation along the pipeline,” Nebenzahl said. Arbel weighed in to agree. “The tool’s main goal is to give users the feeling of what integrity along the pipeline should look like.” He continued, “Suppose you have a Node project. How would verification of the pipeline’s integrity look if you had only two points, the beginning and the end — including verifying the open source components?”
The road to release was not easily traveled, Arbel says. Software integrity is inherently a difficult problem, but creating the technology behind Scribe Integrity was filled with roadblocks. The evidence collectors, or sensors as Arbel calls them, were a complex puzzle to solve. “We had to develop sensors whose main task is to collect evidence that isn’t being collected by anyone today. It’s not just application logs of GitHub or Jenkins, it’s a new kind of data. We need to generate the data, collect it, and then transfer it to a secure place where we can run our rule engines on it. And that’s the second challenge.”
Deciding what is and isn’t suspicious isn’t always as easy as one would think for a machine. Arbel went on, “Let’s say that the data is metadata in the hash in a cryptographically hard signature. So now you’ve got it, but now you need to decide what is a normal process. What is an anomaly, and when the integrity changes, you need to understand if a certain specific change is legitimate or not.”
Now that Scribe Integrity is ready for public use, Arbel is confident in the uniqueness of the technology. “There is no good technology for software integrity today that we’re familiar with, especially one capable of doing it in an automatic way towards pipelines.”
Making Open Source Projects Secure
The open source bug spread pretty fast. Though it’s been an astronomical help in advancing technology, Nebenzahl says security tends to be an afterthought.
“The open source movement, which started from more volunteering ecosystem, is now more business-oriented with business-related activities inside. What was driving it at first was community building, and now we are seeing Business and Technology building,” he said.
While he acknowledged that it isn’t a bad thing, Nebenzahl says users have to be mindful of the lack of security. “Whoever is building an open source project has not committed currently to any security requirements,” he noted. “He’s not building a product, he’s not giving a service. He’s just writing code. The requirements of security and regulation become irrelevant when you start using this technology. However, when it gets to real-world scenarios and in real products, or real companies that are liable, people scratch their heads and say, ‘Hey, what about the security of these pieces?’”
Low-security oversight has been the cause of millions of dollars in hacker theft and the nail in the coffin for otherwise strong businesses. The developer community continues to see growth and change in the way code is shared, and it’s more necessary than ever to stay vigilant with the software supply chain’s security. As the open source community expands and attacks continue, prepare to see tools like Scribe Security’s at the forefront of the fight.