Алексей Смирнов, 04/06/25
Алексей Смирнов, основатель CodeScoring, – о создании первого российского анализатора состава кода, машинном обучении и культуре безопасной разработки.
– Алексей, расскажите о себе.
– Я родился в Ленинграде, папа – офицер военно-морского флота, мама – инженер-строитель. Первые годы своей жизни провел далеко от родного города – на военно-морской базе, на севере, где проходила служба отца. Сопки, метели и суровый воздух – мои первые впечатления о мире. Позже мы вернулись в Петербург, где я поступил во французскую гимназию. Этот момент совпал с эпохой компьютеризации, и тогда меня этот мир захватил с головой. В юношеской мечте я видел себя программистом – таким, каким только мог вообразить подросток 90-х.
Первую программу, с которой я попал в научную школу "Земля и Вселенная", написал в 1998 г. Это была программа для изучения астрономии, идею которой подсказала мне учительница физики. Я тогда впервые услышал мысль, что если овладеть фундаментальной наукой, например математикой, можно стать кем угодно. Эта мысль крепко во мне укоренилась, и после школы я поступил на астрономическое отделение матмеха СПбГУ. К тому времени уже знал три языка программирования: C, Java и Fortran, – которые использовал для научных расчетов.
Со второго курса я начал работать. На факультете тогда витало новое слово – "стартап". В 2004 г. я оказался в команде, которая разрабатывала поисковую систему для анализа финансовых новостей. Это первое знакомство с NLP (Natural Language Processing) случилось задолго до того, как он стал хайпом. Там же я впервые прикоснулся и к машинному обучению.
Будучи студентом пятого курса, начал преподавать программирование в альмаматер, на втором высшем. И продолжал это делать 15 лет. Именно там я отточил ораторские навыки, которые сегодня так пригождаются на конференциях и выступлениях. Поступил в аспирантуру, продолжал заниматься вейвлет-анализом временных рядов и звездных каталогов, параллельно пытался вписаться в международные астрономические проекты. Хотел исследовать Вселенную не только в теории, но и в рамках настоящих космических миссий.
– С чего вы начинали свою карьеру?
– Первым полноценным местом работы стала компания General Satellite, впоследствии – GS Group, где я начинал программистом, но вскоре стал руководить отделом интерактивного телевидения. Мы разрабатывали веб-сервисы, упрощающие взаимодействие с ТВ, – по тем временам это было весьма новаторское направление. После General Satellite был шестилетний этап в компании "Нетрика", куда я пришел на позицию технического директора. Это был период стремительного роста компании. Я оказался в самом центре интеграционных проектов, архитектурных решений, управленческих задач и впитал, как мне тогда казалось, весь возможный опыт, какой можно было получить в интеграторской ИТ-компании.
В стране тем временем бурлила стартап-культура, повсюду обсуждали открытый код. GitHub только набирал обороты. И я подумал: ведь GitHub – это и есть новое резюме программиста. Не бумажка с заголовками и приукрашенными навыками, а живой, настоящий код. И вот мы с моим другом-математиком Константином Тяпочкиным решили попробовать: можно ли превратить код в резюме? Даже придумали фразу: "Резюме лжет, исходный код – никогда". Скачали весь GitHub и при помощи машинного обучения попытались понять навыки авторов кода: на что они способны и с каким качеством.
Это была авантюра. Годы ушли на разработку алгоритмов, оценку кода, эксперименты. В 2015 г. мы наконец созрели: оформили все в продукт, зарегистрировали компанию и назвали ее Profiscope.
Нам казалось, что это точное попадание: мы действительно искали и выделяли таланты и действительно умели анализировать код. Но с оформлением бизнеса пришло неожиданное осознание: рекрутинг – не наша сфера. Наши технологии про код, мы – про код. Про его структуру, качество, лицензионную чистоту и безопасность. Безусловно, важно знать, кто этот код написал. А значит, наш опыт можно направить в сторону аудита программного обеспечения. Начали с малого – обзванивали знакомых, предлагали помощь в аудите, искали способы применить наши инструменты в сделках M&A, в оценке технических активов.
К 2019 г. мы провели десяток работ, которые можно назвать аудитами. Где-то мы входили в большие проектные группы реинжиниринга информационных систем, где-то проводили аудит самостоятельно. Каждый случай был уникален – не бывает двух одинаковых проектов. Но в какой-то момент поняли: пора перестать подстраиваться под каждый случай, пора из этой боли и практики "родить" продукт.
– С чего начинался Profiscope как сервис?
– Profiscope как сервис вырос из аудитов. Занимаясь техническим анализом программного обеспечения, мы увидели, что люди не понимают, из чего состоит их код: они покупали компании, принимали проекты от подрядчиков, но никто не задавался вопросом: что там внутри? Из этого опыта сложился свод очень конкретных вопросов, на которые бизнесу и технарям нужны ясные ответы. Кто писал код? Какого он качества? Соблюдаются ли лицензии? Сколько в проекте чужого, а сколько своего?
Пришло понимание, что пора двигаться к созданию продукта. Мы хотели дать людям инструмент. Так родился CodeScoring.
– Как развивался CodeScoring?
– Сначала мы заказали логотип – кажется, в 2019 г. Презентации стали красивее, из-за чего уверенности прибавилось. Начали собирать кусочки: алгоритмы, методики, подходы. В какой-то момент позвонил Андрей Акинин – тогда мы не были знакомы лично. Он нашел меня через общих знакомых и предложил выступить на круглом столе Общественной палаты РФ по анализу исходного кода. Я написал тезисы, выступил. Все было новым, я никого там не знал. Наш подход казался настолько нестандартным, что меня даже приняли за представителя иностранной компании.
Потом все затихло, но в августе 2020 г. Андрей снова позвонил. В одной крупной телеком-компании возник запрос на нечто, похожее на наш продукт. Мы собрались, вдохнули глубже – и начали энергично собирать CodeScoring. К нам подключился мой старый коллега – Дмитрий Волк, он и сейчас рулит всей разработкой в роли технического директора. С августа по декабрь, по сути, мы ускоренно создавали систему из всего, что у нас было: данных, наработок и знаний. Общались с заказчиком, уточняли детали, формировали контуры.
В январе 2021 г. презентовали первую версию CodeScoring. Нам сказали: интересно, давайте пробовать. Важно отметить, что это корпоративный сегмент, особенный и со множеством требований (забегая вперед, скажу, что нашим заказчиком эта компания стала только в этом году). Но мы уже были разогреты. Я вел по пять-шесть презентаций в день. Команда чуть подросла. Мы по-прежнему не искали инвестиций – все строилось на энтузиазме, опыте и вере в продукт. Весь 2021 г. мы работали с удвоенной энергией. Усилили команду – к нам присоединился директор по продукту Роман
Лапин. Интересный факт: с Романом мы познакомились, когда я пытался его зарекрутить через наш Profiscope, когда последний еще работал. Наняли админа, взяли программистов. В июне состоялась первая выставка – Tech Week в Сколково. Первый стенд, первый живой показ. Людям было интересно – это чувствовалось. Мы тоже чувствовали: что-то не так. Система решала проблему, но слишком комплексно. Мы говорили: "Загрузите код – получите все: и качество, и безопасность, и профиль разработки". Звучало красиво, но не срабатывало.
Для нас стало открытием, что в России ИТ и ИБ – это не просто разные отделы, это разные вселенные. Разные бюджеты. Разные языки. Безопасники, увидев что-то "не свое", сразу передавали мячик айтишникам. И наоборот. Мы поняли: нужно менять подход. И поменяли. Система стала модульной. Один модуль – про качество, другой – про безопасность. И все это под единым девизом: знай свой продукт.
Наступил 2022 год. И тогда мне казалось – всё. Больше нет сил. Аудиты не всегда перекрывали стоимость разработки продукта. Был февраль. Но нам позвонили. И написали. Писали люди, которые когда-то брали мою визитку, кому я говорил про нашу систему. И они говорили: "Вы помните? Мы тогда говорили про импортозамещение. Вот он – момент настал". Количество пилотов решения значительно возросло, появились особенно требовательные заказчики, а к команде присоединился Игорь Петров, который основал у нас "Службу заботы о заказчике", которая привносит особую душевность в нашу работу и отношения с заказчиками.
Оглядываясь назад, я часто думал: мы бы все равно дошли до этой точки – просто медленнее, тяжелее, с десятками лишних витков. Но события ускорились. Мир резко изменился. А мы к этому моменту уже были на старте: продукт собран, команда в строю, рынок – открыт. Все, что оставалось, – идти вперед.
Нас поддерживал дистрибьютор Web Control во главе с Андреем Акининым – он не просто партнер, а настоящий идейный вдохновитель. Именно с его участием мы начали движение по рынку, стали завоевывать доверие, собирать кейсы, объяснять, что безопасность приложений – не абстракция, а жизненная необходимость.
Главное – мы сделали то, чего в России раньше не было. С гордостью говорим об этом: мы стали первой отечественной системой композиционного анализа ПО. Пусть это звучит громко, но это правда.
– Как это вообще работает?
– Чтобы действительно понять, как сегодня устроен CodeScoring, важно взглянуть не только на механику, но и на философию, из которой все выросло. Существует два подхода, два взгляда, которые, идут параллельно.
Первый – традиционная модель аудита, где все строится на точечной проверке: пришел специалист, посмотрел, зафиксировал результат, оформил заключение. Это методика "отчет за отчетом", подход, где многое подчинено регламенту.
Второй – родом из разработки. Постоянный процесс, где действует принцип, который на Западе называют Shift Left – сдвиг проверки влево, ближе к началу процесса: чем раньше ты находишь проблему, тем дешевле ее исправить. Эта идея нам особенно близка.
Сегодня CodeScoring – не просто инструмент аудита, а полноценная платформа для безопасной работы с Open Source, проверки совместимости лицензий, поиска секретов и оценки качества кода в разрезе команды. CodeScoring интегрируется с двумя десятками смежных систем и обеспечивает встраивание проверок на каждом этапе разработки.
– Каким образом CodeScoring решает поставленные задачи?
– Сегодня в системе есть четыре направления. Первое – защита на входе. Разработчик может по незнанию попытаться скачать вредоносный или особо уязвимый пакет Open Source, и задача CodeScoring – не пустить его внутрь по совокупности настраиваемых критериев. Это – первая линия защиты цепочки поставки ПО. Чтобы обеспечивать качественный анализ Open Source, мы собираем данные про мировой открытый код: про пакеты разработки, информацию об угрозах, уязвимостях и лицензиях. Ведем регулярную работу по очистке этих данных, нахождению в них пробелов и сопоставлению информации. Эта сведения также используются и в следующем направлении.
Второе – композиционный анализ, ядро системы. Мы берем программу, разбираем на части, определяем, из чего она состоит, какие компоненты входят, находим известные уязвимости, сверяем лицензии, определяем критичность найденных проблем и даем рекомендации: заменить, обновить, применить патч. Мы делаем это прежде всего для программистов, потому что именно им придется все исправлять. Наша цель – сократить трение между разработкой и безопасностью, чтобы они говорили на одном языке. Поэтому мы встроили наш анализ в процесс сборки и добавляем проверки на уровне редактора кода (IDE). Анализ работает и на локальной машине, и на этапе сборки, и даже после релиза: ведь уязвимости сами по себе не появляются, а обнаруживаются спустя месяцы. И код, который вчера был безопасным, завтра может оказаться под угрозой.
Третье направление – анализ качества разработки. Мы смотрим не просто на код, но и на тех, кто его пишет. Как растет или ухудшается качество, где возникают риски. Это модуль TQI – Teams and Quality Intelligence. Он помогает увидеть динамику и заранее понять, где может вспыхнуть проблема.
И четвертая, финальная часть, – защита от случайных утечек конфиденциальной информации через код. Мы заметили, насколько это распространено: программисты по неосторожности оставляют в коде токены, ключи, пароли. Такие "секреты" попадают в публичные репозитории, в финальные сборки, откуда их могут извлечь злоумышленники. По статистике, каждый десятый разработчик с этим сталкивался. Это кажется мелочью – но иногда из-за этого могут утечь и деньги.
Сам по себе анализ секретов – это, с технической точки зрения, не самая сложная задача, если ты умеешь анализировать код. Но используемый статический анализ, как известно, подвержен приличному числу ложноположительных срабатываний. Так называемых "фолзов". Их может быть до 90% ото всех найденных "угроз". Разработчики тратят часы и дни на борьбу с тем, чего, по сути, нет. Мы начали искать способ, как сократить количество ложных срабатываний. И нашли его – в машинном обучении.
– Как машинное обучение повлияло на функциональность CodeScoring?
– Именно машинное обучение оказалось тем инструментом, который позволяет сделать анализ более эффективным. Мы натренировали собственную модель машинного обучения и встроили в наш продукт возможность дополнительного обучения прямо на стороне заказчика. Потому что CodeScoring – не облачный сервис, а полноценная установка в контуре пользователя. Продукт разворачивается внутри инфраструктуры клиента, рядом с его кодом, его данными, его командами. Естественно, никакой заказчик никогда не отдаст нам свои настоящие секреты – они слишком важны, слишком чувствительны, чтобы с ними обращаться иначе.
Наша модель "из коробки" умеет отфильтровывать до 70% ложноположительных срабатываний, но если пользователь включает дообучение на своих данных – а мы такую возможность предусмотрели – точность возрастает до 90%–95%.
Мы не останавливаемся на оптимизации работы с секретами машинным обучением: в нашей лаборатории ведутся исследования нацеленные на повышение скорости принятия решений пользователем при столкновениях с вопросами безопасности кода.
CodeScoring – не кнопка, а среда, которая помогает создавать более безопасное, прозрачное и предсказуемое в разработке ПО.
– Что получают заказчики, устанавливая у себя CodeScoring?
– Когда в компании появляется CodeScoring – вместе с композиционным анализом, анализом качества, поиском секретов – возникает нечто большее, чем просто контроль. Возникает прозрачность. Появляется понимание, что происходит в коде, как устроена работа команд, где риски, а где сильные стороны.
CodeScoring устанавливается у заказчика, интегрируется с десятками других систем, подключается к сборочным конвейерам, к трекерам, к хранилищам кода. Он умеет собирать данные, анализировать их, реагировать на события, блокировать сборки при нарушении политики безопасности. Но при этом CodeScoring живет рядом с разработкой, а не над ней. Не мешает, а помогает. Мы уверены: безопасность – это не надстройка, а часть качества.
– А сколько стоит CodeScoring?
– Прямой вопрос, а ответ – не совсем прямой. CodeScoring лицензируется по числу разработчиков. Поэтому одной универсальной цены просто не существует. Мы работаем там, где уже есть отлаженные процессы, зрелая разработка, инфраструктура.
Но у нас есть внутренняя миссия: сделать CodeScoring понятным и полезным не только банкам, крупным нефтегазовым компаниям или маркетплейсам, где мы сегодня активно работаем. Мы хотим, чтобы доступ к качественному анализу кода был и у маленьких студий, стартапов, у команд из 10 человек и даже у студентов, которые только начинают писать свои первые проекты.
– С чего, вообще, начинается безопасная разработка?
– Кто-то, открыв нормативные документы, тут же укажет на ГОСТы, на требования, на списки обязательных практик и стандартов. Но это будет не совсем правда. Настоящая безопасная разработка начинается вовсе не с бумажек. Нас научили программировать, быть может даже писать тесты, чтобы не было функциональных ошибок. Но почти никто не учил думать о безопасности системно, последовательно – как об ответственности. Только в последние годы появились курсы по безопасной разработке, и то – единичные. К сожалению, большинство учится этому не на лекциях, а от последствий, от инцидентов. Все-таки, по-настоящему безопасная разработка начинается там, где человек начинает думать об ответственности и возможных последствиях.
– Вы руководите группой по разработке ГОСТа по композиционному анализу. Расскажите – как вас, человека из коммерческой разработки, занесло в Технический комитет 362?
– В 2022 г. я выступал на мероприятии, посвященном безопасной разработке, рассказывал о нашей работе, о подходах, делился практикой и поднимал вопрос: почему так важно вовремя заниматься безопасностью. И там же познакомился с Дмитрием Пономаревым из "Фобос-НТ" и ИСП РАН, который и стал для меня проводником в новый мир: науки и технологий ИСП РАН и нашей отечественной регуляторики. Про меня и наши умения рассказали ответственным коллегам и познакомили с Вартаном Падаряном, руководителем направления обратной инженерии бинарного кода ИСП РАН. Оказалось, во ФСТЭК России была задача: разработать стандарт по безопасной разработке с применением заимствованных компонентов. Тема важная, острая, но без исполнителя. И вот коллеги из ИСП РАН рассказали о нашей экспертизе в этом направлении.
Я никогда раньше не писал ГОСТы, но сказал себе: "Вызов принят. Погнали". И мы начали. Создалась рабочая группа. Я – главный автор проекта стандарта, но рядом со мной – Дмитрий Пономарев и Вартан Падарян. Мы работаем вместе. С нами также уважаемые компании, которые следят, чтобы мы не увлеклись и не написали ерунды: "Лаборатория Касперского", "Астра", "ИнфоТеКС" и другие. Работа продолжается и сейчас. Стандарт уже на финальной стадии. Это история про то, как путь из глубокой инженерной практики вдруг может привести в мир нормативов, регуляторики и государственной экспертизы – если у тебя есть что сказать. А лучше не сказать, а сделать.
В процессе написания проекта стандарта было много личных открытий и полезного опыта: от работы с терминами и определениями до проверки применимости требований для организаций разного типа. Кроме того, я иначе стал воспринимать классические термины, одним из таких стала "поверхность атаки", которой я проникся с более инженерной точки зрения. Представление этого термина можно прочитать в ГОСТ Р 56939– 2024.
– Расскажите про петербургскую ветку сообщества по безопасной разработке. Как все началось?
– Как водится, вышло это не по плану, а почти стихийно. Формально, конечно, в России уже давно существует большое профессиональное сообщество под эгидой ИСП РАН и ФСТЭК России – SDL-сообщество. Исторически оно московское: большинство участников, инициатив, встреч – все там, в столице. Но, как известно, Петербург – город живой, и айтишной крови здесь хватает. Однажды к нам в гости приехал Дмитрий Пономарев и сказал: "Давай сделаем питерскую ветку? Ну, организуем что-то свое?". Я ответил просто: "А давай!". Это было года три назад. Так мы и стали соорганизаторами. CodeScoring с самого начала был в числе тех, кто это поддержал. Вместе с нами – "Фобос-НТ" (они, пожалуй, играют здесь главную роль) и компания YADRO, которая тоже активно включилась. Так родилось то, что мы теперь называем питерской веткой сообщества РБПО.
Наши встречи – это не просто посиделки в баре, а полноценное мероприятие по безопасности: всегда минимум три-четыре, а то и восемь выступлений, докладов. Мы делимся опытом, обсуждаем практики, новые инструменты. Собираемся примерно дважды в год.
Мы даже придумали собственный символ – сделали флаг с игрой слов Saint-РБПО. С этим флагом прошлым летом мы катались по Неве на кораблике. В этом году уже провели весеннюю встречу и, скорее всего, соберемся еще раз, ближе к осени. Это неформальное, но очень живое сообщество: здесь встречаются программисты, тимлиды, специалисты по безопасности приложений, владельцы продуктов, руководители высокого уровня – со штатом в 5 тыс. человек. Даже предприниматели приходят – те, кому интересна безопасность как часть устойчивости бизнеса.
Что особенно приятно, здесь никто не отделен от других званием или должностью. Все равны. Люди приходят, чтобы слушать, делиться, задавать вопросы. Это и есть настоящая профессиональная среда. Без ярлыков.
– Какие у вас планы на ближайшую пару лет?
– У нас случилось важное событие – мы открыли офис в Москве. Создаем представительство ближе к заказчикам, партнерам, коллегам и друзьям, которые находятся в столице, потому что чем плотнее общение, тем лучше понимание и живее диалог.
При этом наша штаб-квартира остается в Санкт-Петербурге. Именно там сосредоточен основной центр компетенций, наша инженерная сила, наша команда – нас уже более пятидесяти человек.
Мы не просто поддерживаем текущие решения, но активно двигаемся вперед и создаем новое. В разработке находятся несколько новых модулей CodeScoring, которые дадут пользователям еще больше гибкости, глубины и скорости при работе с безопасностью кода. Мы хотим, чтобы защита становилась не обузой, а естественной частью разработки. Ближайшие 2–3 года для нас – это время роста, созревания и расширения. Мы уже на этом пути.
