На SOC Forum одним из самых горячих дискуссий стала тема, которая ещё пять лет назад казалась нишевой, а сегодня напрямую влияет на устойчивость критической инфраструктуры: создание доверенных репозиториев ПО.
В дискуссии приняли участие: Федор Герасимов, лидер сообщества FinDevSecOps, эксперты финансового сектора − Максим Кожокарь (Банк России), Всеслав Соленик (Сбертех), а также Антон Прокофьев (ГК «Солар»), Юлия Липатникова (Cloud.ru) и Николай Костригин (Базальт СПО).
Полную запись дискуссии можно посмотреть здесь (Программа 18 ноября, Зал 3, 16.00).
Дискуссию открыл Федор Герасимов, который отметил, что атаки на цепочки поставок выросли с 20 до 30% инцидентов в финансовом секторе, а прирост новых уязвимостей CVE в 2024 году увеличился на 40% год к году. При этом каждая крупная организация тратит 4–8 недель на проверку одного open-source компонента, зачастую дублируя усилия других игроков рынка.
Российские участники рынка начали реагировать: появились первые промышленные инициативы — от репозитория Московского правительства до хранилища Ассоциации ФинТех и корпоративных репозиториев крупнейших финансовых организаций. Но ключевой вопрос остаётся открытым: при каких условиях компаниям действительно стоит переходить от классического SCA-анализа к подписке на доверенные репозитории?
Почему возникла тема доверенных репозиториев?
Сегодня большинство крупных компаний в России используют тысячи библиотек открытого исходного кода, проводят одни и те же проверки, тратят одни и те же ресурсы и при этом постоянно сталкиваются с недостатком специалистов.
Атаки на supply chain больше не воспринимаются как «крайний случай». Антон Прокофьев из «Солара» отметил: «Ошибка не в том, что компонент может оказаться уязвимым. Ошибка — в том, что его каждый раз по цепочке проверяют сто команд. Мы просто воспроизводим один и тот же процесс снова и снова. Структурно — это ошибка всей отрасли».
По словам Максима Кожокаря (Банк России), понятие „проверенное ПО“ сегодня в каждой компании трактуется по-своему. «Один считает достаточным пропустить пакет через три сканера. Другой делает полный цикл ручного анализа, реверса и фаззинга. Эти две процедуры даже по уровню доверия несопоставимы − и рынок это знает», − прокомментировал эксперт.
Проблема №1 - нет стандартизации
И пока её нет, у всех участников свои критерии: автоматизированный SCA-анализ, ручная экспертиза, реверс-инжиниринг, инструменты фаззинга, анализ транзитивных зависимостей и др.
По словам Николая Костригина из «Базальт СПО», ситуация сейчас выглядит так: «Сегодня два вендора могут уверенно говорить, что их ПО проверено — и оба будут правы. Только один имеет в виду быструю автоматическую проверку, а второй — две недели реверса и динамики. И это нормальная ситуация, просто рынок пока не договорился о шкале».
Проблема №2 - прозрачность и ответственность
Фёдор Герасимов задал важный вопрос: если уязвимость всё же попадёт через доверенный репозиторий — кто отвечает? С юридической точки зрения, на него не может быть простого ответа.
Юлия Липатникова (Cloud.ru) пояснила: «Если вендор предоставляет проверенный репозиторий — это часть PaaS. Но заказчик всё равно обязан контролировать обновления, цепочки зависимостей и риски использования. То есть наличие “чистого” репозитория не освобождает от инженерной и регуляторной ответственности внутри компании. Даже если пакет был проверен на входе, никто не гарантирует, что через месяц не появится новая CVE. Поэтому в реальности возникает модель разделенной ответственности: провайдер обеспечивает входной контроль, заказчик — своевременную реакцию в своём контуре. Именно поэтому рынок сегодня ищет модель управляемого риска, а не «идеальной защиты».
Когда компании пора переходить к доверенному репозиторию?
По словам Максима Кожокаря, этот вопрос − не технический, а экономический:
«Порог перехода наступает, когда стоимость инцидента становиться выше стоимости проверки. Если простая уязвимость может стоить бизнесу 200 млн, то даже дорогой анализ перестаёт быть дорогим». На практике переход происходит в трех ситуациях: если внутренние ресурсы перестают справляться, проверки становятся организационно неэффективными, а также в силу того, что разные зоны требуют разной глубины проверки.
Антон Прокофьев отметил: «Когда по цепочке ПО подвергается одинаковой проверке— проблема не техническая, она организационная. Модель перестает масштабироваться. Также стоит помнить о том, что при проверке много времени отнимает проверка достижимости уязвимостей в сторонних компонентах».
Всеслав Соленик в свою очередь выделил три зоны риска: ПО внутри самого продукта, ПО в инфраструктуре заказчика, ПО, которое используется на endpoint-ах (АРМ, терминалы, сервера). По словам эксперта, оно представляет три разных уровня угроз, а значит, и три разных уровня экспертизы и анализа. Поэтому универсального подхода не существует.
Сколько стоит проверка ПО?
Цифры, которые публично озвучили участники:
· проверка одной библиотеки — от 1 до 3 рабочих дней одного инженера
· проверка прошивки / firmware — 1–2 недели работы инженера
· проверка полного репозитория — «две недели работы трёх человек»
И эта стоимость рабочего времени не включает расходы на поддержку инфраструктуры (TCO) и стоимость лицензий.
Юлия Липатникова добавила, что помимо стоимости самой услуги проверки ПО, есть еще такой аспект, как SLA: готов ли заказчик ожидать конкретное время для того, чтобы получить результат (отчет о проверке). Всегда важно понимать, что мы упираемся не только в деньги как оплату услуги, мы упираемся еще и в то время, за которое мы будем выпускать какой-то продукт − Time to Market.
Антон Прокофьев дополнил: «Когда бизнес видит цифры в бюджете, он говорит: “Это дорого”. Но когда мы показываем, сколько стоит один реальный инцидент — вопрос исчезает сам собой».
Универсальный стандарт проверки - возможен, но не обязателен
Здесь участники сошлись во мнении, что универсального стандарта, скорее всего, не будет, так как в различных отраслях существуют разные риски и вес ошибки также разнится. Как отметил Максим Кожокарь: «Невозможно одинаково проверять библиотеку для интернет-банка и библиотеку для внутреннего wiki. Цена атаки просто разная». Но при этом рынок ждет единой набора требований и методики к качеству проверки ПО и зрелого формата сертификации.
Влияет ли доверенный репозиторий на time-to-market?
Всеслав Соленик пояснил: «Когда 50 команд перестают направлять одни и те же заявки на одни и те же компоненты − скорость релизов растёт автоматически. Без дополнительных KPI, без перенастройки процессов − просто потому, что исчезает лишняя работа». По его словам, эффект ощутим, так как разработчики получают гарантированный уровень доверия «из коробки», сокращается объем рутины для ИБ-специалистов, а стек ПО становится унифицированным.
Фёдор Герасимов также отметил: «Внедрение стандартизированного репозитория снижает технологический долг — команды перестают бояться обновлений и быстрее переходят на новые версии». Александр Гадай (SwordFish) дополнил: «Как только появляется прозрачность проверки — исчезает фактор страха и “чёрной магии” вокруг безопасности».
Какие барьеры тормозят рынок?
Технологические рамки
Антон Прокофьев: «Проверить тысячу компонентов без ручного анализа так же глубоко, как ручная проверка — пока никто в мире не умеет. Алгоритмизации здесь ограничены чисто физикой задачи».
Риски монополизации
Федор Герасимов: «Если отрасль сделает одного поставщика единственным входом, отрасль передаст ему слишком много контроля. Рынок должен оставаться мультиплатформенным».
Лакуны в юридическом поле
Максим Кожокарь: «В настоящее время отсутствует регулирование данной области. С одной стороны, это хорошо, так как позволяет самостоятельно развиваться рынку данных услуг. Но и плохо так как вопрос ответственности и принятия рисков не урегулирован и остаётся на потребители услуг доверенного репозитория.
Что станет точкой доверия на рынке?
Как отметил Максим Кожокарь, «Банкам нужны альтернативы, иначе зависимость станет новой уязвимостью». Он выразил позицию, совпадающую со значительной частью банковского сектора, заявив: «Реальность такова: несколько репозиториев лучше монополии. Рынок сам решит, кому доверять, по качеству практик, по стабильности и по прозрачности подходов».
Александр Гадай продолжил дискуссию о нескольких репозиториях: «Когда работает консорциум, перестаёшь просто верить на слово. Ты видишь: какой анализатор, какие правила триажа, какие версии проверены и когда повторно пересмотрены. Таким образом, создаётся модель, в которой репутация строится на проверяемой методологии, а не на маркетинге».
Что дальше?
Российский рынок уже создал первые платформы, начал инвестировать и включил регуляторов в диалог. Но главный вопрос ещё впереди: сможет ли отрасль договориться о правилах игры — не потеряв конкуренцию, скорость и инновационность?
Доверенные репозитории — это не дань моде, а новый уровень зрелости рынка. Они помогают экономить тысячи инженерных часов, снижают вероятность инцидентов, повышают воспроизводимость и доверие к цепочке поставок. Но вместе с тем полностью не снимают ответственность с команды разработки, не работают без SLA на обновление, требуют зрелых процессов внутри самого заказчика и пока не имеют единого отраслевого стандарта проверки. До появления такого стандарта вендорам, бизнесу и госструктурам ещё предстоит договориться о самом главном: что такое «доверие» и сколько оно стоит.
Как заметил Федор Герасимов: «Важно, чтобы возникла экосистема, в которой доверие измеримо, стандартизируемо и взаимно проверяемо». Если это произойдёт, то DevSecOps в России выйдет на принципиально новый уровень зрелости.
И в завершение дискуссии отметим позицию «Солара» по той теме: на горизонте 5-6 лет появление доверенных репозиториев возможно, но сначала всему сообществу и регуляторов важно будет ответить на вопрос «Будет ли владелец репозитория отвечать за качество проверки кода и какие санкции будут наложены в случае инцидентов, связанных с уязвимостями в ПО». Поэтому пока единственной разумной альтернативой остаются анализаторы кода, которые позволяет провести комплексную проверку кода – от SAST и DAST до проверки компонентов открытого исходного кода, проверки лицензионных рисков в соответствии с требованиями бизнеса и обязательствами перед регуляторами в критически важных проектах.
