Hi HN, we’re Rob, Russell and Eugene from EdgeBit (
https://edgebit.io). EdgeBit is a tool to secure your software supply chain that focuses on code that is actually running. This simplifies vulnerability management as it cuts through the noise of vulnerabilities you’re not actually exposed to. EdgeBit secures your software all the way from a pull request to build and production. It’s like inbox zero for CVEs. Here’s a demo video:
https://www.youtube.com/watch?v=4lC6qkfN4Uo.
Nothing is more frustrating than investigating a vulnerability to find that it's not exploitable at all. Russell ran security engineering at Okta and knows first hand it’s a constantly moving target of dependencies, frameworks and deployment platforms. Automation is key, but security teams aren’t experts in each app, so “open a ticket for any vulnerability found” is a typical workflow. This is a noisy and frustrating firehose for engineering teams, and tickets don’t contain the context needed for a speedy investigation.
EdgeBit ranks threats to keep the patch SLA promised to your customers, helps engineers fix the riskiest items first and assigns dormant items to a lower tier. We automatically inventory your software dependencies, ensure they are trusted, and monitor vulnerabilities, securing your software supply chain. For security teams, we help you meet new compliance requirements about the libraries and packages in your products. For engineers, we make vulnerability investigation/patching streamlined, so you can get back to writing code.
We use eBPF-based observation of your running software to keep the threat list as short as possible. For example, if your code has a history of exec-ing imagemagick we’ll include it, but if it’s dormant we can lower the priority of those vulnerabilities. When adding a new dependency, EdgeBit’s runtime knowledge helps our GitHub bot suggest versions already in use by other teams in your company, as a nudge towards consistency.
To use EdgeBit, each build execution sends a software bill of materials (SBOM) to EdgeBit. We’re big fans of the open source Syft project, which we use to generate SBOMs. After a build is deployed, we use eBPF to identify packages and files in use, and compare it to the SBOM and vulnerability databases. If there’s a new CVE, EdgeBit passes along context to the engineers tasked to fix it. If a package reports a CVE, but we observe it’s dormant (i.e. you’re not running that particular library), the CVE should be fixed but not be at the top of the list.
Looking beyond compliance, real attacks are happening via software dependencies. Since the Colonial Pipeline attack, Federal compliance requirements and Biden’s cybersecurity directive [1] now cover tracking and understanding your supply chain. For a single library, it’s tricky to securely download, integrate, sign and verify it…and very hard for 100s of dependencies across many apps. Where did the dependency come from? What builds is it in? Where is it deployed? EdgeBit provides a single view across OS packages, standalone binaries and containers to understand the full attack surface.
Monitoring tools don't tie back to the source build nor do they verify the integrity of your workload, so they leave a lot of gruntwork undone. Also, most scanning tools are noisy by design and we're headed to a world where SBOMs are going to be used as a checklist to add even more useless toil to the firehouse, so new tooling is sorely needed. EdgeBit looks at your OS, workloads, and containers continuously. It's not enough to just scan containers in a registry or validate them upon cluster admission and then never look again.
Check us out by using https://signup.edgebit.io to build a real-time SBOM from a live server and then trace your workloads to close the loop. Signup to claim an org name, no payment required. Developers can hook up automation for 10 workloads for free. Past that, we charge per server with unlimited workloads and build volume. I think you’ll be surprised by the ratio of active to dormant dependencies—we’re seeing about 20-40% are actually active.
Our near-term roadmap includes tighter integration with sigstore, pulling SBOMs out of containers automatically, and a smarter Kubernetes admission controller. Today we track file accesses and correlate it to package managers like Deb, RPM, PyPi. Soon we'll add more language specific hooks to better support compiled languages. Further out, we will also allow you to block execution of dormant dependencies and enforce file integrity to ensure the bits that are executing match the SBOM. And we're also exploring how an app can communicate its trust profile to other apps, like a secret store.
We’d love to talk to you about the future of this space, how you’re scaling vulnerability response and feedback on what we’ve built so far. We look forward to your comments!
[1]: https://www.whitehouse.gov/briefing-room/presidential-action...
three questions / thoughts:
1) Your post mentions "Ranking", and while do the most impactful work first is great, the method I have most often used is when dealing with Vuln-overload is to "Reclassify". That is Common Vulnerability Scoring System (CVSS) (super flawed as it is) has let reporters check the box for "remotely exploitable" therefore its a 8.0 HIGH vulnerability -- but I think your product could let me reclassify the vuln to a medium/low - maybe a built in CVSS score editor?
2) One other thing there should also be a built-in concept of "accepting the risk" -- and ideally a concrete report of what was previously "accepted", and if that package gets used in new ways?
3) I'm curious what you think about market segmentation in this space? Specifically the sub-200? person companies seem to be using alot of the "all in one" Compliance platforms (eg, Vanta, Drata, etc). Vanta for example does have a vuln management + SLA tracking dashboard + ticketing tools.