top | item 34981946

Launch HN: EdgeBit (YC W23) – live software vulnerability analysis

80 points| robszumski | 3 years ago

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...

29 comments

order
[+] pquerna|3 years ago|reply
congrats on the launch!

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.

[+] eyakubovich|3 years ago|reply
Great feedback.

1) We want to be cautious about changing a score that someone else assigned (CVSS) but we'd like to add our insight to inform of its impact.

2) Absolutely and we'd like to bundle it with active blocking. After reviewing the CVE, we'll let the user either accept (e.g. mute) it or block that specific package from being used (e.g. for dormant ones).

3) We think our service is most useful to slightly larger orgs with dedicated security functions and bigger supply chains. We want to help slow down the fire-hose of vulnerability reports coming from the security to devs.

[+] snowypine|3 years ago|reply
Awesome. Supply chain security is one of the most important pieces of modern security efforts. Tracking active vulnerabilities to cut through the noise is a super solid approach
[+] dkhots|3 years ago|reply
Real time SBOM is something unique!
[+] philips|3 years ago|reply
I tried out the agent on a testing VM. I really like the product direction and overall concept.

It is weirdly satisfying seeing the pie chart of packages in use fill up as you use the machine and the scanner picks up the used software.

Nice work!

[+] drcongo|3 years ago|reply
Small bit of feedback - you have a pricing page [1] that has no prices on it. It offers me the chance to start a free trial and says it's priced per server, but I'm not going to sign up or start a free trial if I don't know what the price per server actually is.

[1] https://edgebit.io/plans/

[+] robszumski|3 years ago|reply
Good point, thank you, this should be renamed to plans to match the url at a minimum. I'll make that change now.

edit: I've also updated the page with the price. We're starting at $15/server/mo and volume discounts apply

[+] tmd83|3 years ago|reply
I wonder what languages it support for language libraries or is it just limited to linux packages? Say java, js etc. ?

Is it marking something active on access or actually checking execution? On execution doesn't work for at least js payload on the other hand on access would add to noise say for an ls.

[+] robszumski|3 years ago|reply
Inside of the SBOMs, we can detect a lot: https://github.com/anchore/syft#supported-ecosystems

You're right that the active/dormant detection needs to be customized per type of runtime. It ends up being a mix of both access and execution, and we'll get more sophisticated with eBPF over time. We cover rpm/deb, python and java with the node and others coming very soon. The compiled languages will be our main focus next. For example, Go binaries embed some dependency metadata in the binary itself.

Also related to this effort is the "in-toto" integrity chain: https://in-toto.io/in-toto/ Since we're already connecting build to run, we aim to complete the chain.

[+] benarent|3 years ago|reply
Congrats on the launch. This is a solid team, exciting use of eBPF and an important problem to solve.
[+] candiddevmike|3 years ago|reply
Why would someone use this vs dependabot? My gut tells me dependabot will be more accurate.
[+] robszumski|3 years ago|reply
Dependabot helps when fixes are available and/or if your automation and test coverage is strong. Context from what’s running can help focus your efforts when more investigation is required, if the CVE is tricky or fixes need to be tracked and rolled out across a lot of teams. You'll see a lot of CVEs marked "won't fix" for example.
[+] freeqaz|3 years ago|reply
There is a cost to fixing every CVE. Dependabot is designed to fix every CVE which is highly inefficient when only a fraction of those CVEs matter/are exploitable.

Approaches like what EdgeBit is taking are very important to reducing fatigue/noise which is the main issue with Dependabot today.

[+] jdoss|3 years ago|reply
Great job Rob, Russell and Eugene! Congrats on the launch! I'll be checking this out this weekend.
[+] fierro|3 years ago|reply
a really great idea. looking forward to testing it out.
[+] ceva|3 years ago|reply
FYI I don't know what you have on the https://edgebit.io but some files got quarantined by MS defender on my company laptop Trojan: Trojan:JS/Phish.RA!MTB
[+] robszumski|3 years ago|reply
The only third party JS we use outside of Google/Youtube is a single marketing analytics tool. I haven't seen a report of this before but I don't like it at all – consider that tool in the trash.

edit: it's gone

[+] russell_h|3 years ago|reply
Thanks, we'll try to figure it out. There's nothing on the marketing site but "normal" web content (agents, etc are all hosted on separate domains) - any indication what file it was?