Журнал "Information Security/ Информационная безопасность" #2, 2025

Первый – традиционная модель ауди- та, где все строится на точечной про- верке: пришел специалист, посмотрел, зафиксировал результат, оформил заключение. Это методика "отчет за отчетом", подход, где многое подчинено регламенту. Второй – родом из разработки. Посто- янный процесс, где действует принцип, который на Западе называют 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? 10 • В ФОКУСЕ