SubImage is our hosted offering built on top of Cartography (https://github.com/cartography-cncf/cartography), the open source security graph that we created at Lyft in 2019, originally shared on HN here: https://news.ycombinator.com/item?id=19517977. You can think of us as an open-core Wiz alternative.
In 2016, I worked on Microsoft’s Azure Red Team, where we built an infra mapping service to find the shortest paths to exploit our targets. We were so effective that the Blue Team wanted it too. In 2019, I joined Lyft, where we applied the same ideas to AWS and beyond, helping build and open-source Cartography. Over the past six years, it’s been incredible to grow the community and see over 70 companies (that I know of) use it.
Kunaal and I first worked closely together in 2020 when we helped bootstrap Lyft’s vulnerability management program and used Cartography as its backbone: https://eng.lyft.com/vulnerability-management-at-lyft-enforc.... This is actually where the name SubImage comes from: Lyft services are made up of one or more “SubImages”, and modeling this properly was such a memorable engineering challenge that we decided to name our company after it.
Cartography pulls metadata from multiple sources -- SaaS, cloud service providers, a company’s internal services -- and writes it to a graph database. This simple technique is incredibly powerful in modeling otherwise unseen misconfigurations and attack paths in areas like access permissions, networking, and software vulnerabilities.
SubImage picks up where Cartography leaves off: it’s a fully-hosted solution that provides specific recommendations for the problems it finds. The fix-action depends on company size: small teams might run AWS CLI commands, while larger orgs require automated infrastructure-as-code pull requests.
Here’s a video demo showing how we can use SubImage to understand and take action if our Stripe API key is unexpectedly used: https://www.youtube.com/watch?v=RBCr35hb5Hk.
SubImage also provides a natural language interface to quickly answer questions about our infra: https://imgur.com/a/subimage-natural-language-interface-quer....
Security is a competitive space, but we have a few differentiators:
First, we allow a very deep level of customization where the security team can enrich their graph with their own internal data, not just data from the major cloud providers. If it can be expressed as structured JSON, you can graph it; here’s a demo: https://www.youtube.com/watch?v=rvwDJoZaO_w. This flexibility is needed to answer questions like: Which storage buckets contain PII? Who owns them? Who’s on-call for https://example.com/api/payment? Which company director owns the most risk?
Since it’s built on Cartography, teams can also just write custom plugins in Python if they’d like: https://cartography-cncf.github.io/cartography/dev/writing-i....
Second, our core principle is actionability. Security teams drown in alerts. SubImage traces paths from critical assets to the most exploitable misconfigurations, helping teams cut through the noise and prioritize real threats.
Finally, we’re built on open source. We created Cartography and as it improves, so does SubImage. Cartography is a CNCF project (https://eng.lyft.com/cartography-joins-the-cncf-6f6b7be099a7), which means that it is full open source and will remain so.
Going forward, we’re maintaining Cartography while launching SubImage as a fully managed offering. Our roadmap includes Access Management (prune excessive permissions and enforce security invariants, Change Tracking (detect and alert on infra changes that introduce risk), and Cloud & SaaS Misconfigurations (expand visibility, including vulnerability management).
Thanks for reading! If this sounds interesting, try out https://github.com/cartography-cncf/cartography.
It’s an honor to share SubImage with HN, especially having followed projects here for over a decade. We’d love to hear your questions, feedback, and the challenges you face in security and infra!
As someone deeply familiar with this problem (ex-JupiterOne), I'd caution against asserting that 'deep level of customization' is a differentiator. Your buyer (CISO) and userbase (Sec Engs) are drowning. They (and I) don't want yet another product to build on top of. This is a key reason why Wiz is so successful -- an operator can turn Wiz on and immediately receive value, no adjustments or additions needed.
I'd strategically focus on making the 'actionability' part the cornerstone of the product and really become obsessed with making that part of your product incredible. The Goliath-killing story you need will be formed by figuring out how to get your product to the point where someone can turn it on and immediately receive value for the most impactful security problems first (ex: Log4J) and the total surface area of problems the product solves for second.
Security spending is down, so navel gazing products are going to be a really hard sell. Figure out how to actually solve problems in an automated/semi-automated way and ship that instead.
The other issue with all of these tools is handling onboarding/integrations and getting terrible visibility as a result. A big market gap I see is a tool that can use the vulnerabilities it discovers to further information collection just like a real attacker would. Found Splunk creds in a log? Awesome, start using them. Syslog in an S3 bucket... boom. You are now hitting the stuff that every other ASM/visualization tool has missed.
> Found Splunk creds in a log? Awesome, start using them. Syslog in an S3 bucket... boom. You are now hitting the stuff that every other ASM/visualization tool has missed.
This is my dream :). This past weekend I was playing around with something where if I clicked on a SecretsManagerSecret node then it'd give me the CLI commands to assume the roles and then retrieve the secret. It'd be neat to take it a step further and be able to click here and get a shell -- I don't think we're _that_ far off from that (but for now to be very clear we're focusing on read-only actions only since a security tool with permissions to do scary things in your environment kinda defeats the purpose).
Do you have similar plans or are those kinds of things left as an "exercise to the reader" via your Intel Plugins link? I do see https://cartography-cncf.github.io/cartography/modules/aws/s... but I also see https://github.com/cartography-cncf/cartography/blob/0.100.0... so it's hard to know what level of insight one wishes to support out of the box versus the localstack model of "open core, advanced features are $$$" type deal
We 100% do this, see https://eng.lyft.com/iam-whatever-you-say-iam-febce59d1e3b.
We evaluate the policies for the IAM principal against the resources to determine what actions they can perform on each resource. This is configurable too; here's the set of the default permission relationships shipped in OSS: https://github.com/cartography-cncf/cartography/blob/master/...
It doesn't cover conditions since those can be wacky complicated, and it doesn't cover resource policies (yet!) but in my experience this is still a very good heuristic that is already more accurate than AWS IAM Analyzer when I played with it.
The next step we're working on is to take this access map and correlate it with event data to see which permissions are used/unused so that we can prune them for ensuring least privilege. More to come here.
Edit: adding on for the part of your question about what features are paid or OSS, our paid offering is fully hosted and includes things like automatic suggested fixes, a natural language interface, customization with our dynamic schemas, and other bells and whistles. I'm not a fan of doing things like premium modules because I don't want to ever get in the position where I'm declining a pull request in open source because it covers a premium feature; that doesn't feel right.
I think it would probably be unreasonable to say "IAM Conditions when?" in a Launch HN if one had to build those things from scratch. That would be ferociously hard and not a sane ask right out of the gate. But since IAMSpy already exists, and according to you there's some non-trivial amount of IAM evaluation already in Cartography, then what I'm asking is whether you envision your future as one of ("eh, it's good enough", "we're integrating more libraries that attempt to formalize IAM", or "we'll roll our own policy engine in python, how hard could it be")
Further illustrating my point, you linked to a .yaml file with "s3:GetObject" seemingly applied to an S3Bucket saying "can read" but that's for sure not systemically true for a monster list of reasons. I get the impression that Wiz makes their bread and butter on helping people understand when they actually have open S3 buckets and not just giving them a report full of false positives
I do appreciate this can come across as busting your chops, but I don't mean to shit on you, or your product, or your launch. I'm just pointing out that if you put "You can think of us as an open-core Wiz alternative" in the 2nd sentence of your announcement, there is a massive opportunity for expectations being out of alignment unless you have a plan to get from where you are to Industrial Grade Introspection. The other side of that coin is that if you do have the background for it, as your pseudo-resume implied, then it's a massive opportunity to give them a run for their $5 billion, too
1: and it's the misconfiguration that I would want a reasonable tool to chirp about, not "omfg token.actions.githubusercontent.com can get into your Role!"
We recommend changes, though we don't generate Terraform just yet. Great feedback on the specific fixes for this case, thanks.
website(on firefox) nitpicks
- The handle_complexity.png image is too small to read and can't be zoomed unless opened in another tab.
- The background effect is in the foreground of chatbot_cropped_gif.gif
- The yaml schema text should have a background like the rest of the text boxes
Good question. Right now the chatbot is in preview and we're currently figuring that out. That said, we do have it provide the underling query that it used to answer the question so a user can double check with that.
Thanks for the comments on the landing page -- we're security nerds and definitely not great at frontend haha, will fix!
If you can pull this off, you will have a great time