This content originally appeared on Level Up Coding - Medium and was authored by Trey Huffine
An Interview with Barak Brudo from Scribe
This week we interviewed Barak Brudo from Scribe. He shares how Scribe handles the complex task of finding malicious software exploits, and how they are creating the standards to ensure that the vast combination of packages we all use in your code are safe, and that the software doesn’t change as it passes through your pipeline. Barak provides deep insight into how the delivery of code works, how hackers try to infiltrate, and what we can do to stay safe.
> Be interviewed in Level Up Coding ➡️ Fill out this form
> Looking for an amazing job? ➡️ Visit the Level Up hiring platform
“The bad guys don’t often go directly after a particular company. For example, you wouldn’t directly try to infiltrate Microsoft’s code. You look for the small building blocks that many companies use. These are much easier to attack. You let it disseminate naturally and dormantly. Then, once you reach a high-value target, the bad actor activates the attack.”
What does Scribe do?
Scribe aims to help solve the software supply chain security problem. Currently, we offer integrity validation and an SBOM (software bill of materials) with insights on your process and artifacts. I was attracted to the company because it feels like a product that has actual use and importance in the world — I didn’t want to work for a company that is just moving money around without giving back something of value to the world.
The software supply chain is the idea that all software uses other pieces of software. Let’s take a fighter jet. A company gets to put its name on the jet, but it’s made of many components created by different companies. Then those companies use components and materials supplied by other companies themselves. For software, it’s the same. All software is comprised of building blocks from other people’s code, usually open-source software.
You can think of it as the roots of a tree or an iceberg. You can see the visible part. However, as you go deeper, much more is hidden below the surface.
The bad guys don’t often go directly after a particular company. For example, you wouldn’t directly try to infiltrate Microsoft’s code. You look for the small building blocks that many companies use. These are much easier to attack. You let it disseminate naturally and dormantly. Then, once you reach a high-value target, the bad actor activates the attack.
Eventually, companies stop checking the building block software because it’s been fine for so long. In addition, a “main” company validates and signs the code that they’re using that contains the exploit, but the companies further down the pipeline never see the malicious code. This creates a false sense of trust.
This is the problem we’re solving — the risk of the hidden software making unapproved changes to your code. We are addressing the issue of visibility and trust. We are trying to get information shared as freely as possible. We aim to show you all the different packages that are actually in your code, including the full range of transient dependencies.
We’re starting with NPM and Node and will later begin working on other package managers.
To see the kinds of attacks Scribe is trying to prevent, look at the SolarWinds hack.
Can you explain integrity validation and the SBOM?
SBOM — software bill of materials. These are the software ingredients. This contains all the files and libraries in a piece of software. It contains all the needed data, including transient dependencies and relationships. It’s a detailed description of what comprises that software artifact.
You want the SBOM to be a standard. You want it to be sharable by any person and any organization. Then you can scan the SBOM with code to fully understand the software you’re including.
We are using our own system to create the SBOM. To verify, we need two points of comparison, and we check for differences. The SBOM creates a hash of all files included so we can compare the file hash as it was in the repository and the file hash as it appears in the final image. If there’s a difference in any file that wasn’t meant to change, that means it was modified somewhere along the pipeline. Any unscheduled modification might indicate a problem.
What technology stack do you use?
Our product is written in Go and uses Mongo as the database. We’re still pretty early in the release schedule so as more features are added, it stands to reason we’ll incorporate additional building blocks.
What about Go and Mongo make it the right choice to solve this problem?
One of the advantages of Go is that it’s fully compiled. When you have compiled code, you know exactly what you’re getting, and you know exactly what is going on in your final artifact.
We chose Mongo because we needed NoSQL and didn’t need tables. There is such a high volume of data that we needed to easily and quickly connect and access the files and folders. There are so many complex layers and images that we need the flexibility of a non-table database.
How did Scribe start?
The company started around June of 2021 not long after the Biden administration released EO 14028 following the famous Solar Winds incident. Section 4, about securing the software supply chain, stood out to the founders as a relatively new niche that is underdeveloped. They had an idea for a product and an ecosystem that could answer a lot of the EO’s requirements and give real value to anyone using open-source software.
What makes Scribe unique?
Not many companies approach the software supply chain problem from the angle of integrity validation without adding any scans. The idea behind it is simple enough — create an SBOM at several points in the CI/CD pipeline and use the file hash values included in the SBOM to compare the files. Any changes to the hash means the file was changed, and most files are not meant to change along the pipeline, so that change is suspected as malicious.
The practical side is, of course, is much more complicated since each language has a unique way of compiling and building code, and some files are meant to change as part of the process. The files can change their name or location between the source control and the final artifact, so a straight 1-to-1 comparison is rarely easy.
What are some of the most interesting problems you’re solving?
One issue impacting a lot of companies is just a lack of information. The market is still not sufficiently informed about the potential dangers and possible remediation. There is the NIST’s SSDF, CICA’s work on promoting the SBOM and, of course, the EO itself, poised to drive change in the market. But such changes are slow, and I just hope we can get to a more secure place in the global software supply chain before we see the next Solar Winds.
Then there is the issue with intellectual property. No one wants their code open, but they do want the validation that we offer. The way we do this is file hashing. We don’t need to look at the code when we have the file hash created by the SBOM.
We create an SBOM of the repo and an SBOM of the final image. Then we compare the hash of the input and output, and if files don’t match, then we know this is a place that we should inspect.
For open source, we compare the packages you use with their known source online. If we see differences, we know there is an issue. If this is the case, the user may have downloaded the code from the wrong place or it was modified along the way. We’re not looking for bugs or secrets, we’re just verifying that what you’re using and delivering is exactly what you intended.
What will the world look like once Scribe achieves its vision?
The vision is a world where you can immediately search for any company or product and see the chain of evidence and provenance that proves it was not tampered with. “Trust but verify” is a common idiom, and we aim to make it as simple as possible to verify any sort of library, package, or product, of course, as long as they incorporate our solution into their pipeline.
Once every piece of software has been detailed, we’ll live in a utopic world where a company can fully understand the software they use and produce. Every company will have insight into any potential issues. You’d know in advance what issues or possible vulnerabilities have been detected in the code version you’d choose to employ.
What does a typical day look like for you?
I have numerous tasks, so I’ll probably start by writing down what are the most important things I need to do that day. On any day, I also try to give time to social media to see what’s new in the field and follow Google alerts to see if something relevant crops up. I also try to find time to check my emails and answer relevant queries, give some time to writing or editing articles or blog posts, and prepare for the next conference or webinar that we have scheduled.
Are there any technologies or tools you’re playing around with right now that you’re excited about?
Most of our tools are standard, but one thing we did release recently is an open source package called GitGat designed to offer a GitHub security posture report. This is brand new and just getting started. GitHub is easy to attack, but it’s also easy to defend. We describe the problem and tell you how to solve it. We scan your repo and give you recommendations.
Are you hiring and for what roles?
We’re hiring senior Golang backend developers (there are never enough), and security researchers.
Where can we go to learn more?
Our website, scribesecurity.com
Level Up Coding
Level Up is a community of 3 million monthly developers (learn more and follow or read more interviews). We also work with the best startups and most innovative tech companies 🔥
- Are you a developer? Have the best companies request to hire you
➡️ Join the Level Up Talent Collective - ➡️ Hire FAANG-caliber Engineers
- ➡️ Interview Request Form to have your company interviewed
We also provide free tools for developers to grow their careers: coding interview course, automatic resume builder, portfolio API
Follow us on Twitter and LinkedIn
How Scribe is building a world where every piece of software is validated and secure was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Trey Huffine
Trey Huffine | Sciencx (2022-07-18T15:01:41+00:00) How Scribe is building a world where every piece of software is validated and secure. Retrieved from https://www.scien.cx/2022/07/18/how-scribe-is-building-a-world-where-every-piece-of-software-is-validated-and-secure/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.