Привет, Хабр! Хочу поделиться честной историей, в которой мое желание избавиться от рутины, любовь к разработке, open source и enterprise переплелись самым тесным и неожиданным образом. Четыре года назад я всего лишь хотел делать свою восьмичасовую работу за пару часов, а остальное время отдыхать , добавить во внутренний тулинг удобные кнопочки и меню, используя свой опыт разработки, но все пошло не по плану, и я сначала стал разработчиком своего собственного инструмента VSCode-XP (open-vsx.org, marketplace.visualstudio.com), потом его мейнтейнером на GitHub, продвигал его использование среди экспертов на профильных конференциях. Потом наработанный открытым сообществом опыт перенял enterprise-продукт и получилась история в стиле Толкиновского «Хоббита, или Туда и обратно».

Важный дисклеймер. В статье я расскажу историю достаточно специфичного open source из глубин enterprise по кибербезопасности, поэтому если ожидаете тысяч звездочек на GitHub, то тут такого не будет. Также не будет истории про успешный успех, только кровавая true story 😊

Начало истории

Все началось, когда я впервые в жизни занялся разработкой детектирующих правил (далее — просто правил, не будем усложнять повествование) для SIEM-системы (это такая штука, которая собирает логи с устройств и на основе предварительно загруженных правил выявляет возможные атаки либо аномалии). Как это выглядело: за сутки в профильных пабликах появляется множество постов о новых или обновленных хакерских утилитах. Их нужно изучить, скомпилировать, запустить на стенде для сбора порождаемых логов, разработать новые или доработать существующие правила, написать/обновить тесты для проверки корректности их работы (что-то типа интеграционных тестов в классическом программировании). И так… каждый день, изо дня в день. Это непрерывный процесс, который ну очень хотелось оптимизировать, избавиться от лишней рутины. 

Почему я решил что-то поразрабатывать, хотя в компании разработчиком не числюсь? Разработка — моя вторая любовь, после ИБ, конечно. Раньше я фанател от книг, таких как «Архитектура корпоративных программных приложений» Мартина Фаулера, «Паттерны проектирования» Банды четырех, «Чистый код» Роберта Мартина. Профессиональным разработчиком я не стал, но, если есть возможность что-то автоматизировать и разработать, я всегда вспоминаю о своем увлечении. Так и началась история инструмента VSCode-XP. 

Знакомство с eXtraction and Processing

eXtraction and Processing (далее XP) — это проприетарный язык для обработки событий в SIEM-системе компании Positive Technologies, на котором, собственно, и пишутся правила. Чтобы не быть голословным, приведу пример простейшего корреляционного правила. Вначале синтаксис кажется немного странным, но со временем понимаешь, что он достаточно логичен и гибок для решения своих задач. 

Если на узле (event_src.host) будет запущена утилита управления запланированными задачами (schtasks.exe), то с узла поступят два вида событий с Event ID «4688» и «1» (Sysmon) и с помощью регулярного выражения будут проверены параметры запуска утилиты. Если в них встречаются аргументы /create, /change, /run и /delete, тогда на основе данного корреляционного правила в продукте появится алерт. 

Желающим глубоко погрузиться в синтаксис языка можно ознакомиться с документацией по XP.

Устоявшийся инструментарий разработки

Когда я начал заниматься разработкой правил для SIEM-системы, то столкнулся с тем, что внутри компании использовался как комбайн из проприетарного ПО, так и общеизвестные инструменты типа VSCode, Notepad++ и подобные. 

Первое использовалось только внутри компании, заказчиками и партнерами. Это нативное приложение PTSIEMSDK GUI (далее — SDK GUI) для работы с языком с функциями подсветки синтаксиса, подстановки шаблонного кода (boilerplate code), запуска тестов для правил и другой функциональности. К нему в качестве зависимости прилагается SDK, который тоже распространялся ограниченно. На тот момент заложенная в SDK GUI функциональность требовала очень много ручных действий, а также использования дополнительных инструментов. 

Как это выглядело. Например, кто-то из нашей команды использовал дополнительный текстовый редактор (VS Code, Notepad++ или IntelliJ IDEA), который ему нравился больше, чем встроенный в SDK GUI. Чтобы код не выглядел однообразно, включали подсветку синтаксиса одного из известных языков, чтобы подсвечивалось побольше ключевых слов. Например, одна моя коллега предпочитала подсветку CoffeeScript. Если нужно было что-то дополнительно масштабно обработать, например скорректировать метки времени, тогда параллельно появлялись скрипты автоматизации на Python.

Мне этот процесс показался очень муторным: ты перемещаешься между окнами различных IDE, какие-то операции делаешь в одном, какие-то в другом, затем еще какие-то скрипты нужно не забыть запустить. Если что-то забыл, быть беде то все сломается или не будет работать. 

Почему не доработал проприетарную IDE

Был, естественно, базовый вариант: добавить в нашу SDK GUI функциональность дополнительного редактора и интегрировать скрипты в виде ее доработки. Получается вроде бы классная история: нет больше никаких дополнительных скриптов и IDE, все в одном приложении. В целом я так и планировал: добавить нужные менюшки и кнопочки, которые бы оптимизировали работу с правилами… Но не тут-то было: самое логичное, простое и понятное решение оказалось совсем нежизнеспособным. Так как я считаю важным подсветить этот момент в своем повествовании, то я все причины разложил на административные и технические. 

Во-первых, это официальный инструмент, который используется внутри компании и находится на поддержке. У него есть цикл разработки и поставки, роадмап, пользователи, поэтому нужно все согласовывать и уточнять с командой разработки. А что еще более важно, у пользователя уже сформировался UX-опыт, который нельзя начать ломать. А лично мне хотелось совсем с другой стороны посмотреть на разработку правил. Даже когда один из наших коллег сделал внутренний форк инструмента и быстро затащил туда нужный функционал, влить его в основную ветку разработки оказалось невозможно из-за большого количества изменений. 

Во-вторых, пользователи IDE (в нашем случае эксперты продукта) и разработчики, которые поддерживали SDK GUI, по-разному смотрели на одну и ту же задачу. Для иллюстрации возьмем такой кусок кода на языке XP. 

Например, по версии пользователя для семантической проверки, для которой нужно проверить равенство второго параметра в функции filter::CheckWL_Specific_Only (вообще в языке XP это макрос, но я не буду усложнять рассказ занудствами такого рода) и правого выражения оператора присваивания (выделены красным на рисунке), необходимо написать пару регулярок для парсинга, убрать все непечатные символы и сравнить две строки. И для разработки такого функционала времени требуется минут… 20, в крайнем случае 30, но это только если еще успеть выпить чашечку кофе. Для пользователя это рабочий вариант, даже если иногда будет плохо работать, показывать ошибку там, где ее нет.

Профессиональный разработчик смотрит на это иначе: нужна описанная грамматика языка для парсинга всех конструкций языка в синтаксическое дерево, после чего уже можно начать обход этого дерева для выявления семантических ошибок. Тут еще появляются модульные и интеграционные тесты и… ни 20, ни 30 минут никак не выходит ☹

Следующий комплекс причин — технический. 

  1. Пользователи хотят Я хотел кросс-платформенности. Когда в 2022 году приложение работает только на Windows, это как-то несовременно (мягко говоря). У стека, который использовался в SDK GUI, такой возможности «из коробки» не было. 

  2. Нативное приложение очень сложно превратить в IDE. Все разработчики привыкли к классным IDE, где есть целая база расширений, функционал для рефакторинга, готовых сменных тем и другого. Это очень большая работа, требующая много времени. 

  3. Существование, зрелость и популярность VS Code / VSCodium, которые позволяют добавить поддержку произвольных языков DSL (domain-specific language) или программируемых языков, как указано в документации. Причем это достаточно несложно сделать: нужно разработать расширение (extension) на TypeScript/JavaScript и Node.js для поддержки нового языка. В некоторых случаях не нужно даже писать код, можно просто заполнить текстовый файлик. Например, вы хотите получить фолдинг, чтобы какая-то большая конструкция скрывалась в плюсик и раскладывалась. Для этого просто заполняете JSON’чик — и он работает. Хотите подсветку синтаксиса? Используете грамматику TextMate, описываете ее с помощью определенной структуры и регулярных выражений — вот и подсветка синтаксиса готова. Отлаживать можно прямо в VSCode через Scope inspector. 

Кстати, VSCodium — это тот же VS Code, только отвязанный от лицензионных ограничений Microsoft. В нем нет телеметрии, иконки другие, шрифты, но под капотом это фактически одно и то же. Хотя у обоих продуктов лицензии MIT, их код есть на GitHub.

Концепция

В итоге придумал я следующее. Функциональность SDK GUI я могу вынести в расширение VSCode-XP, доступное пользователям как внутри компании, так и за ее пределами. Это будет сильно проще, чем переписывание с нуля, так как серьезная часть функциональности ложится на сам VSCode, который «из коробки» умеет управлять файлами (открытие, закрытие, отслеживание состояния), поддерживать Git, функциональность WebView т. д. Все остальное переношу в расширение VSCode-XP и туда же интегрирую дополнительные скрипты. При этом у пользователей, привыкших к SDK GUI, остается привычный им инструмент, который продолжает развиваться и распространяется только среди заказчиков/партнеров. 

Как я отмечал, у языка eXtraction and Processing есть SDK, без которого у нас получается просто текстовый редактор с подсветкой синтаксиса без возможности запустить тесты и обрабатывать логи. Поэтому отдельным направлением была публикация SDK. Его можно без проблем скачать и использовать по лицензии, с которой помогли корпоративные юристы. При этом исходный код его недоступен. 

Тут небольшое отступление. Когда мы рассказывали о наших планах на внутреннем комитете по открытому коду, один авторитетный в опенсорс-сообществе коллега подсветил, что тогда у нас получается какой-то неполноценный опенсорс, когда для SDK нет исходного кода. Да, действительно, в идеале его тоже нужно опубликовать, но найти баланс между интересами enterprise и open source очень трудно, поэтому даже такой результат меня устроил, но в этом отношении нам безусловно есть куда развиваться. 

Слева в окне VS Code или VSCodium — штатный компонент Tree View. Если нужно отобразить какую-то древовидную структуру, просто используем штатный компонент: переопределяете getChildren и getTreeItem, и готово. К компоненту можно привязать открытие любых файлов, расширений с любыми подсветками.

Посередине — код на языке XP, корреляционное правило с подсветкой синтаксиса. Здесь также установлено дополнительное расширение indent-rainbow, которое показывает, правильно ли выставлены табуляции. 

Справа тоже крутая функциональность — компонент webview c возможностью встраивать произвольные веб-интерфейсы. Фактически в нем можно разместить все, что вы можете сверстать. К примеру, я хотел перенести части окон нативного приложения в виде single-page application (SPA), но в текстовый редактор все не интегрировать, поэтому я выносил нативную составляющую в виде отдельных webview. Там можно использовать практически все, что хотите. Умеет работать с HTML, ванильным JavaScript и использовать jQuery (я так делал, и мне до сих пор неловко 😊), а если хотите что-то актуальное, красивое, расширяемое — можно использовать Vue.js, React и Angular. 

Публикация 

На первом этапе мне очень помог комитет по открытому коду нашей компании. В основном у ребят был опыт публикации проектов в классическом open source, связанном с разработкой. Тем не менее это был ценный опыт, который я использовал сполна. Благодаря комитету также удалось решить юридические вопросы, касающиеся интеллектуальной собственности. 

Следующим шагом был выбор площадки. Первое демо состоялось в октябре 2022 года. Тогда репозитории некоторых компаний просто пропадали из GitHub. Не хотелось, чтобы все мои труды однажды неожиданно перешли «в архив» или вообще пропали. Поэтому было выбрано зеркалирование на несколько площадок. Многие в первую очередь думают про код, но на самом деле неплохо было бы с собой унести Issues, теги и какое-то взаимодействие в сообществе. Очень рекомендую эту статью моего коллеги Александра Попова про зеркалирование GitHub-проектов.

Далее был этап доработки функционала и, естественно, публикация открытого SDK для языка XP.

Важный момент: не забывайте, что, помимо кода и библиотек, которые вы указываете при публикации, есть различные картинки, SVG’шки, которые тоже являются частью интеллектуальной собственности. Нужно убедиться, что вы не занесли ничего, что нельзя использовать. Также рекомендую ресурс choosealicense.com, чтобы познакомиться со спецификой лицензирования, если планируете публикацию проекта. 

Сообщество и коммуникация

Для публикации проекта было выбрано независимое сообщество Security Experts Community. Следующий аспект для сообщества — это способ коммуникации. Мы пробовали GitHub Discussions — это классная штука, которая фактически встроена в GitHub. Очень удобно, когда все в одном месте: код, issues, pull requests и коммуникация. Но оказалось, что для нашей аудитории GitHub Discussions не взлетел. Могу лишь рекомендовать ориентироваться на свою целевую аудиторию, если ваше комьюнити привыкло, например, к Discord, то затащить их во что-то другое, не такое удобное и близкое, будет сложно. 

В нашем случае площадкой стал Telegram, потому что пользователи, эксперты и партнеры привыкли к этому формату. 

Далее — интеграция Telegram и GitHub, позволившая преодолеть некоторый разрыв в коммуникации между двумя площадками. Кстати, реализовано это тоже на основе проекта github-telegram-webhook сообщества. Бот следит за появлением новых issues в GitHub, сообщений в них или pull requests, а затем эта информация отображается в Telegram.

Наконец, забираем идеи и баги только через issue. Так правильно. Для сообщества специалистов по ИБ это не было очевидно: люди писали в Telegram мне в личку, но убедить их завести задачу для классной идеи было непросто. Поначалу я сам нередко перехватывал инициативу и заводил issue. А когда фича доходили до релиза, то я отмечал автора идеи, так что все права были соблюдены.

Как заносил фичи

Когда разработчик — ты сам, то нет возможности использовать лучшие практики по разработке, где есть аналитик, архитектор, фронтенд, бэкенд и тестировщик. Поначалу следует рассчитывать только на себя. Потом, конечно, подтягиваются члены сообщества, начинают помогать, подсвечивать какие-то баги, предлагать что-то улучшить. 

Я придерживался подхода community-driven development, когда только запросы пользователей имеют приоритет, нужно максимально быстро решить проблему, снизить time to market, если говорить менеджерским языком. Быстрые фичи заносились за считаные дни, и обратную связь получали быстро. 

В части расширения для VS Code есть версии и сборки предрелизные и релизные. В первую заносим MVP-фичи. После того как в результате нескольких итераций я получал полностью законченную фичу, она переносилась в релизную сборку. В сыроватых предрелизных версиях, конечно, могут быть какие-то баги. Пользователи, которым нужен стабильный функционал, используют только релизные сборки. Если не было негативной обратной связи, то последний предрелиз становился релизом. Обычно это занимало недели, то есть достаточно быстро для одного разработчика. 

Для фиксации этого движения фич пришлось буквально навязывать общение через issue, чтобы было понятно, в чем состоит проблема и что хотелось бы получить на выходе.

Какие контрибьюты получил

Мои пользователи, эксперты ИБ, обычно не имеют настоящего разработческого опыта, поэтому на контрибьют я совсем не рассчитывал, но был приятно удивлен. Мне приносили баги, предлагали улучшения, запрашивали фичи, подсвечивали узкие места в сценариях использования. Приведу несколько конкретных примеров вклада сообщества.

Очень классный контрибьют — автоматизация сборки и доставки расширения. Честно скажу, что вначале загрузку сборки я делал вручную, мне очень лень было ее автоматизировать. Но благодаря одному из наших контрибьюторов у нас появилась своего рода CI/CD на минималках: GitHub Actions, которая позволяет после сборки расширения загружать его в маркетплейс. Вроде бы все просто, но, когда ты один, это здорово выручает, ну и мотивация возрастает. 

Далее — подсветка синтаксиса. Я ее не делал. Мой коллега, который уже решал подобную задачу (а часто так бывает, что несколько человек решают одну и ту же задачу, сидя за «соседними столами», хотя могли бы заколлаборироваться), просто поделился своей наработкой –  TextMate-описанием синтаксиса. 

Еще я бы отметил поддержку macOS, ибо эту ОС я видел только в зарубежных сериалах и никогда не пользовался. Я пытался писать кросс-платформенный код, чтобы он нормально работал на Windows и Linux. А благодаря контрибьюту появилась поддержка Mac в виде Web IDE. 

Другие классные штуки, о которых я узнавал только тогда, когда они ко мне поступали, — это поддержка DevContainers в VS Code и Codespaces в GitHub с автоматической настройкой окружения. До этого нужно было зайти в маркетплейс, найти расширение, поставить его, скачать отдельно SDK, привязать его к зависимостям в виде настроек, запустить. А тут ты просто нажал — все развернулось, и поехали. 

Быстро сказка сказывается…

Теперь про реальный таймлайн. В октябре 2022 года я провел первое внутреннее демо. После этого возникла идея идти в open source, как только она будет более или менее закончена, и начать о ней рассказывать. В 2023-м готовили документацию к расширению, решали вопрос о публикации проприетарного SDK и все юридические вопросы. Затем шли базовые мелочи: нужно было подготовить репозиторий, определиться по зеркалированию, разобраться с маркетплейсом. 

Но и этого мало. Как постоянно говорят евангелисты open source, очень важен классный README. Если заходишь в проект, а там ничего не понять, то в течение 10 секунд пользователь уходит и больше никогда не возвращается. Поэтому начинать стоит с базового описания того, какие боли вы решали и как это делали. 

Еще для нас было очень важно поделиться опытом на конференциях. На PHDays 2023 мы с коллегой впервые провели мастер-класс по использованию расширения VSCode-XP, а на PHDays 2025 я поделился своим опытом open source в ИБ на профильном треке.

Помимо этого, в рамках сообщества были крутые активности: два спринта OSW (Open Security Week) по разработке детектирующих правил для Windows и для macOS, все они доступны в open-xp-rules. 

Финализируем. Мало просто выложить код/скрипт/инструмент — нужно показать, как ими пользоваться, хотя бы гифку на GitHub добавить. Я, кстати, вот такой графический Getting Started сделал, мне прям очень нравится 😊

Дальнейшее развитие

Наступает момент, когда подходы, круто работающие на старте, оказываются не такими успешными на дальних дистанциях. Любитель — это не профессиональный разработчик. Сложность в том, что обработка обратной связи, каких-то ошибок и багов начала вытеснять мою основную деятельность — исследование актуальных хакерских инструментов и разработку детектирующих правил. И тут я понял, что без профессионала уже не справиться. 

Как мы этот вопрос решали? У нас сначала появился один разработчик внутри компании, а потом его сменилoutstaff-разработчик. Было решено, что эта активность не основная, поэтому лучше привлечь внешнего человека, не возлагая ответственность на команду разработки какого-то продукта или сервиса. 

У внешнего разработчика было два очень важных направления. Во-первых, он реализовывал «тяжелые» фичи. Например, у меня не выходит фронтенд, а он все переписал и сделал очень красивые React-компоненты. Во-вторых, разработчик также помог разобраться с накопившимся у меня техническим долгом.

Расставание

Представьте, что ваш опенсорс‑проект — это серьезные отношения. Вы вложили в него время, нервы, строили планы на будущее, мечтали о новом релизе, как о совместном отпуске. Но жизнь меняется: вас манят новые технологии, проекты. Вот так меня перетянуло обратно в offensive-направление, от которого сразу вновь загорелись глаза. По итогу расставание с почетной должностью мейнтейнера неизбежно. И тут важно не бросить свою разработку на произвол судьбы со словами «Вы пользуетесь? Вам нравится? Как-нибудь сами разберетесь…» и хлопнуть дверью. Надо было найти сменщика‑мейнтейнера и передать ему дела, и я так и сделал. Конечно, проект далее не будет развиваться именно так, как бы мне хотелось, но это разумный компромисс. 

Польза для компании

Чтобы подобная деятельность рассматривалась как ваша активная позиция, а не «какая-то халтура, лишь бы задачи из трекера не делать», важно выделять и доносить до руководства пользу для компании. Из полезного на примере своего опыта я бы выделил следующее.

Во-первых, значительно изменились процессы разработки детектирующих правил в нашей команде. Когда мы создавали VSCode-XP, то посмотрели на свои процессы свежим взглядом, как внешние пользователи. Раньше просто делали так, как делали всегда. И хотя перестроиться было непросто, мы очень здорово оптимизировали процессы: у нас появились best practices и много гайдов, которые ускорили работу. 

Во-вторых, мы получили открытый канал обратной связи как от пользователей продукта, так и просто от пользователей языка и его утилит. Взаимодействие с коммерческой компанией обычно проходит через техподдержку, а здесь можно просто зайти в Telegram-чат и написать: вот тут мне непонятно, а вот тут — не нравится. В рамках такой свободной коммуникации, когда формулируешь ответ на запросы, иногда возникает внутренний вопрос: действительно, а почему мы так делали? Это очень хорошая обратная связь со стороны. По-моему, один только этот пункт стоил всех потраченных на протяжении трех лет человеческих ресурсов. 

В-третьих, в SDK GUI (тот внутренний инструмент, с которым поначалу мне было очень сложно работать) на основе нашего опыта был значительно расширен функционал в сторону упрощения работы пользователя. Конкретные выработанные пользовательские сценарии, сформулированные пользователями VSCode-XP, были также портированы в этот инструмент.

Наконец, в-четвертых, сформированный нашим сообществом пользовательский опыт в 2025 году появился в релизе коммерческого продукта MaxPatrol SIEM, а именно в виде новой версии PT KB — внутренней базы знаний продукта, которая пополнилась фичами на основе опыта нашей команды и сообщества. Пользователи VSCode, присмотритесь к скриншоту ниже, ничего не напоминает? 😉

Польза для сообщества

Во-первых, в отдельном репозитории мы добавили открытую базу готовых правил, в которую каждый желающий может внести свой вклад. Просто посмотреть, как сделан детект, и сделать аналогичный для своего продукта на своем языке, просто переиспользовав опыт сообщества. Кстати, по этой ссылке можно посмотреть правила детекта обхода ETW и Sysmon. Один участник нашего сообщества написал статью и приложил детекты, написанные на языке XP. 

Во-вторых, мы подготовили и опубликовали открытый курс. Чем он полезен? Помимо самого языка, в нем описан наш общий подход к разработке правил для SIEM-системы. Можно переиспользовать этот опыт и методологию, чтобы писать крутые правила, которые стабильно работают и хорошо покрыты тестами. 

В-третьих, я обратил внимание на рост аналогичных активностей в индустрии. Например, в 2024 году коллеги из другого вендора также выложили расширение для языка своего продукта, о чем они рассказали на PHDays. Это неплохо развивает сообщество, и очень отрадно видеть, что коммерческие компании тоже двигаются в схожем направлении.

Итоги

Четыре года назад, когда я только начал заниматься разработкой детектирующих правил для SIEM-системы, мне просто хотелось избавиться от рутины и прокачать рабочий инструмент. Я хотел, чтобы в нашем внутреннем тулинге появились удобные кнопочки и меню, рутина свелась к минимуму, а моя продуктивность выросла. Но все явно пошло не по плану, и я стал сначала разработчиком своего собственного инструмента VSCode-XP (open-vsx.org, marketplace.visualstudio.com), потом его мейнтейнером на GitHub и продвигал его использование среди экспертов. Сформированные открытым сообществом пользовательские сценарии были переняты enterprise-продуктом, что сделало всю историю до конца целостной. 

И хоть все реально пошло не по плану почти с самого начала и я уже отдалился от мейнтейнерства, получилась интересная история!