Как стартап, использующий Gremlin, победил всех до двери Google
8 августа 2025 г.Googleприобретение Wiz за 32 миллиарда долларовбыл явным сигналом для отрасли: в войне облачной безопасности есть победитель. Что более интересно, так это то, как они выиграли. Wiz не был первым двигателем. Кружева началась пять лет назад с солидной команды, сильного видения продукта и поддержки VC высшего уровня. Так что же пошло не так для кружева? А что пошло прямо для Wiz?
Если вы просматриваете социальные сети, вы найдете инженеры и CISO, которые спрашивают то же самое. В потоках на X, Reddit и Hacker News есть десятки сообщений, рассекающих матч. Ответ содержит уроки не только для поставщиков безопасности, но и для тех, кто создает современные продукты, устойчивые к данным.
Очевидно, что Wiz сделал много вещей прямо от стратегии продукта и GTM до поддержки и выполнения клиентов. Но есть один угол, о котором я не видел много говорил в обычном анализе. Это моя ниша: инфраструктура данных. Это может быть просто их секретное оружие, и это побудило меня написать этот разрыв.
Возьмите, например, Reddit. Несколько сообщений сравнивают кружево и Wiz, причем инженеры обмениваются из первых рук в результате оценки и развертываний.
Я не охранник. Я из фона инфраструктуры данных. Но эта история такая же много об архитектуре данных, как и о стратегии продукта.
Давайте посмотрим на то, что построила каждая компания.
Кружевное изготовление: идеи графика, реальность SQL
Lacework запущен в 2015 году с платформой данных Polygraph®. Он направлен на обнаружение угроз путем отображения отношений и поведения между облачными активами, классическим вариантом использования графа. Но под капотом кружево не использовало графическую базу данных. Они построили его на снежинках.
Почему снежинка? Вероятно, потому что Sutter Hill Ventures инкубировал обе компании. И, честно говоря, снежинка имела смысл на бумаге. Он предлагает сильную масштабируемость и относительно низкую стоимость. Вы можете сохранить огромные объемы облачной телеметрии, и она упруго масштабирует. Это полезно для контроля затрат и удержания данных.
Но есть улов. Снежинка не создана для рабочих нагрузок. Написание запроса отношений с 3 хопами в SQL может взять 100+ линий вложенных соединений. Вот как выглядит базовый обход в SQL:
SELECT a.user_id, d.device_id, n.network_id
FROM users a
JOIN logins b ON a.user_id = b.user_id
JOIN devices d ON b.device_id = d.device_id
JOIN connections c ON d.device_id = c.device_id
JOIN networks n ON c.network_id = n.network_id
WHERE n.public = true;
Теперь представьте, что отлаживает это в 10 хмеле, с фильтрами, агрегациями и логикой предупреждения. Даже лучшие инженеры замедлится. Развитие становится хрупким и трудным для поддержания.
Wiz: нативный график, скорость функции
Wiz был основан в 2020 году Ассафом Раппапортом и его бывшей командой из Адаллома. Они выбрали другой путь. С первого дня Wiz использовал Amazon Neptune, базу данных нативного графика.
В совместном сообщении в блоге с AWS под названием"Мир - это график", Wiz CTO Ami Luttwak объяснил свой подход:
«Мир - это график, а не таблица. Пришло время наше инструмент отразить это».
Wiz смоделировал все, пользователей, активы, роли и потоки, как узлы и края. Они запрашивали это с Гремлином. Вот реальный пример:
g.V().hasLabel("vm").has("public", true)
.out("connectedTo").hasLabel("network")
.out("reachableBy").has("role", "admin")
.path()
Этот вид логики выражается в 10 строках с Gremlin. В SQL? Это был бы кошмар.
Этот архитектурный выбор дал Wiz огромное преимущество в скорости разработчика. С Neptune и Gremlin инженеры могут выразить сложную логику безопасности в кратких, читаемых запросах и быстро их отправить. Что займет несколько дней или недель в SQL из -за хрупких соединений, а длинные цепочки запросов могут быть прототипированы и протолкнуты в течение нескольких часов. Это имело значение. Безопасность-это быстро движущаяся поле, и способность Wiz поставлять функции на скорости запуска означала, что она может отвечать на запросы клиентов, требования к соблюдению и интеллект угроз быстрее, чем кружево. Даже с меньшей командой они постоянно опережают каденцию доставки продукта Lacework.
К 2022 году Wiz углубил свою приверженность графическим инфраструктуре, продолжая масштабироваться на Amazon Neptune. Их ставка на технологию Native Graph была не только архитектурной; Это определило их скорость и дифференциацию.
Ставка на график, который изменил все
Кружевое изготовление приоритет экономической эффективности. Используя Snowflake, они могли проглотить и сохранять огромные объемы телеметрии с упругим масштабированием и более низкими предельными затратами. Им не нужно было поддерживать отдельную графическую базу данных или оптимизировать для рабочих нагрузок. Компромисс был в возможностях: табличный дизайн Snowflake не был создан для глубоких запросов отношений. Моделирование логики графика в SQL, особенно мульти-хоп-соединения, было многословным, хрупким и трудным для выполнения. Это замедлило разработку и усложняло усовершенствованное моделирование угроз.
Wiz оптимизирован для скорости. Сделав ставку на нативный графический двигатель, они получили быструю итерацию, краткую логику запросов и модель безопасности, основанную на отношениях. Они могли бы выразить новые обнаружения или обходные понимания в нескольких линиях гремлина, быстро идей прототипа и быстрее отправляются обновления.
В кибербезопасности скорость выигрывает. Клиенты больше заботятся о скорости функций и качеством обнаружения, чем маргинальной сбережениях. Wiz пошел дорогостоящим, но стратегическим путем: они заплатили гораздо больше за инфраструктуру, но внесли более быстрые инновации и опередили поле.
Архитектура кружева помогла им масштабироваться дешево, но эта же архитектура затрудняла создание графических функций безопасности. Их ставка оптимизирована для хранения и стоимости. Ставка Wiz оптимизирована для итерации и стоимости продукта. Результат был ясен.
Можете ли вы получить скорость Wiz с низкой стоимостью и неограниченной масштабируемостью озер данных?
Если вы сделали это так далеко, вы можете задаться вопросом: возможно ли получить преимущества нативной графической системы, быстрой итерации, экспрессивных запросов с несколькими хопами, без болезненных затрат и сложности традиционных графических баз данных?
Множество единорогов кибербезопасности пытались сделать творческие обходные пути для решения проблем масштабируемости и затрат традиционных графических баз данных:
- Друг в стартапе кибербезопасности серии F сказал мне, что они хранят только один день данных графических данных, потому что база данных графиков не может масштабироваться.
- Другая компания расщепляет свою нагрузку на график: топология остается в базе данных графиков, но все атрибуты разгружены на склад, такой как снежинка или данные о данных.
Это умные компромиссы. Но они все еще компромиссы.
Оригинал