Launch HN: EdgeBit (YC W23) – live software vulnerability analysis
80 points| robszumski | 3 years ago
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...
[+] [-] pquerna|3 years ago|reply
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
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
[+] [-] dkhots|3 years ago|reply
[+] [-] philips|3 years ago|reply
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!
[+] [-] robszumski|3 years ago|reply
You can read more about our "realtime SBOM" concept as well: https://edgebit.io/blog/realtime-sbom/
[+] [-] drcongo|3 years ago|reply
[1] https://edgebit.io/plans/
[+] [-] robszumski|3 years ago|reply
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
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
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
[+] [-] candiddevmike|3 years ago|reply
[+] [-] robszumski|3 years ago|reply
[+] [-] freeqaz|3 years ago|reply
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
[+] [-] fierro|3 years ago|reply
[+] [-] ceva|3 years ago|reply
[+] [-] robszumski|3 years ago|reply
edit: it's gone
[+] [-] russell_h|3 years ago|reply
[+] [-] Sk012|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] komarkomala|3 years ago|reply
[deleted]