Оркестрирование безопасности как бизнес-преимущество: история успеха платформы AppSec.Hub под руководством Александра Пинаева

Мы беседуем с основателем Swordfish Security, компании, которая на сегодняшний день является одной из ведущих в области кибербезопасности

В 2026 году интеграция процессов кибербезопасности в цикл разработки программного обеспечения перестала быть нишевой задачей и перешла в разряд требований для бесперебойной работы бизнеса. Повсеместное внедрение искусственного интеллекта и усложнение кода привели к тому, что традиционные методы защиты стали неэффективными. Компании больше не могут позволить себе проверять готовый продукт постфактум; рынок требует непрерывного контроля на каждом этапе создания цифровых решений. В этих условиях комплексный подход и класс программных решений для автоматизированного мониторинга, анализа и управления безопасностью приложений на всех этапах жизненного цикла (Application Security Posture Management, ASPM), стал индустриальным стандартом.

В контексте трансформации отрасли мы беседуем с Александром Пинаевым, основателем Swordfish Security, компании, которая на сегодняшний день является ведущей российской компанией в области кибербезопасности и архитектором платформы AppSec.Hub. Выбор спикера обусловлен его ролью в формировании рынка DevSecOps: начав в 2013 году с сервисной модели, Александр выстроил компанию, которая впоследствии перешла к созданию собственных платформенных решений, занявших лидирующие позиции. Эксперты отрасли отмечают, что Пинаев одним из первых спрогнозировал необходимость отказа от ручного тестирования в пользу автоматизированных конвейеров.

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

— Александр, в 2013 году вы покинули должность в крупной корпорации Luxoft, чтобы основать Swordfish Security. Как формировалось это решение и какие шаги были предприняты на старте?

Мотивом для ухода из найма стало понимание того, что в корпоративной структуре я достиг определенного предела развития. К концу 2012 года, получив опционы в преддверии выхода Luxoft на биржу NASDAQ, я осознал, что дальнейшее пребывание в компании не принесет принципиально нового опыта. Я заранее передал дела преемнику, дождался закрытия финансового года и весной 2013 года полностью сфокусировался на собственном проекте.

К моменту фактического увольнения у меня была подготовлена базовая бизнес-инфраструктура. Совместно с партнером Юрием Сергеевым мы проработали позиционирование, выбрали название, зарегистрировали юридические лица и открыли банковские счета. Это позволило нам сразу начать операционную деятельность, не теряя времени на административные процедуры, которые часто тормозят запуск новых предприятий.

Выбор ниши безопасности приложений (Application Security, AppSec) был результатом аналитического расчета, а не случайностью. Мы с партнером оценили различные направления IT-услуг и пришли к выводу, что сфера безопасной разработки обладает наибольшим потенциалом опережающего роста по сравнению с классическим программированием. На тот момент профильных специалистов на рынке было мало, а потребность в защите приложений у крупного бизнеса уже формировалась.

Первые результаты подтвердили правильность расчетов. Уже в мае 2013 года мы заключили контракт с американским разработчиком Venafi, который стал нашим основным заказчиком на последующие годы. На начальном этапе мы лично занимались полным циклом работ: от подготовки коммерческих предложений и продаж до управления аккаунтами, что заложило фундамент для дальнейшего масштабирования сервисного направления.

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

Катализатором послужил анализ путей достижения целевого показателя выручки в 10 миллионов долларов. Сервисная модель предполагает линейный рост: чтобы увеличить доход, необходимо пропорционально увеличивать штат инженеров. На практике это означало необходимость найма и обеспечения проектами около 200 специалистов, что в условиях дефицита кадров и неравномерной загрузки по консалтинговым контрактам представляло высокий риск.

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

Опираясь на этот тезис, в 2016 году мы провели серию внутренних сессий по выбору перспективных направлений. Мой партнер систематизировал требования рынка на основе работы с крупными финансовыми структурами, и мы определили две концепции, которые легли в основу платформ AppSec.Hub и Stingray. Мы понимали, что создание собственного продукта мирового уровня — это единственный шанс занять лидирующие позиции, так как конкурировать объемами штата с гигантами аутсорсинга было нецелесообразно.

Финансовая сторона трансформации оказалась сложнее прогнозов. Мы рассчитывали выпустить продукт за год, вложив около 300 тысяч долларов. На практике путь до первых коммерческих внедрений занял три года, а инвестиции превысили миллион долларов. Все эти средства мы реинвестировали из прибыли сервисного направления, что требовало строгой дисциплины и готовности акционеров откладывать личную выгоду ради долгосрочной капитализации компании.

— Как именно AppSec.Hub изменил процесс разработки? Какую проблему индустрии вы решали архитектурой этого продукта?

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

Первым архитектурным решением AppSec.Hub стала интеграция процессов безопасности в привычную для разработчиков среду. Мы отказались от монолитных отчетов. Система начала передавать найденные уязвимости непосредственно в системы трекинга задач, такие как Jira, в виде отдельных задач. Это позволило разработчикам приоритизировать исправление дефектов безопасности точно так же, как они работают с обычными программными ошибками.

Вторая проблема заключалась в качестве данных, которые генерировали сканеры кода. Различные инструменты тестирования (SAST, DAST, SCA) выдавали большое количество ложных срабатываний и дублировали информацию об одних и тех же уязвимостях. Разработчики тратили часы на разбор этого шума, что вызывало отторжение самих практик безопасной разработки.

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

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

Решение развиваться на собственные средства было продиктовано желанием сохранить фокус на архитектуре продукта, а не на метриках для инвесторов. Стандартный путь стартапа требует постоянного участия основателей в раундах финансирования, подготовки презентаций, расчетов объема потенциального рынка (TAM) и обоснования долей. Мы исключили эти процессы из нашей повестки, направив весь временной ресурс на проектирование и реализацию функционала.

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

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

На протяжении всех этапов разработки я лично участвовал в операционном управлении: контролировал расходы, проверял статус разработки, согласовывал найм ключевых специалистов и участвовал в подготовке материалов для продаж. Такая вовлеченность фаундеров позволила удержать команду в едином информационном поле и довести концепции, заложенные в 2016 году, до коммерческой реализации.

— Как рынок отреагировал на появление нового класса продуктов и сколько времени занял переход от разработки к статусу индустриального стандарта?

Период от создания первого прототипа до коммерческой продажи AppSec.Hub составил три года. Задержка была обусловлена не технологическими сложностями создания самого продукта, а объективной реальностью рынка. Процессы разработки программного обеспечения (SDLC) у корпоративных клиентов были крайне разнообразными. Нам приходилось адаптировать платформу под множество различных сред, интеграций и проприетарных систем заказчиков, чтобы обеспечить бесшовное внедрение.

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

К 2022 году выручка компании перешагнула отметку в полмиллиарда рублей, и структура доходов изменилась: продуктовый сегмент стал основным драйвером роста. Платформы AppSec.Hub и Stingray заняли доминирующие позиции, а экспертиза компании позволила диктовать технологические стандарты в своем сегменте.

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

— Сейчас индустрия переживает новый этап трансформации, связанный с генеративным ИИ. Как вы адаптируете стратегию компании и продукты к этим изменениям?

Мы начали предметно изучать потенциал больших языковых моделей в конце 2024 года. Первоначальный импульс исходил из желания оптимизировать внутренние рутинные операции, однако запросы со стороны корпоративных клиентов быстро сместили фокус на создание новых коммерческих сервисов. В частности, возник острый спрос на тестирование безопасности систем искусственного интеллекта (AI Security Penetration Testing), что потребовало от нас привлечения профильных исследователей.

В ходе работы над стратегией развития безопасности для телекоммуникационного сектора в 2025 году мы структурировали понимание новых угроз. Рынок требует перехода от разрозненных инструментов к единым платформам, способным контролировать риски, связанные с массовым внедрением ИИ. Большие языковые модели интегрируются в бизнес-приложения, формируя сложный конвейер из данных (DataOps), разработки (DevSecOps) и управления моделями (AISecOps).

Изменился и вектор кибератак. Злоумышленникам больше не обязательно взламывать саму модель напрямую, эффективнее скомпрометировать любой элемент в цепочке поставок кода. Внедрение уязвимости в открытую библиотеку, которую затем использует ИИ-система заказчика, позволяет получить контроль над промышленным конвейером.

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

Александр Пинаев продемонстрировал способность трансформировать понимание узкоспециализированных инженерных процессов в устойчивую бизнес-модель. Его решение направить ресурсы сервисной компании на создание независимого программного обеспечения позволило не только сформировать новую нишу на локальном рынке, но и опередить глобальные концептуальные стандарты в области управления безопасностью. Развитие платформы от инструмента интеграции уязвимостей до системы защиты ИИ-конвейеров подчеркивает важность долгосрочного архитектурного планирования, которое Пинаев заложил в фундамент своей компании, обеспечив ей статус технологического ориентира в отрасли.