Привет, Хабр! 

Меня зовут Александр Сахаров, я директор по работе с партнерами в Диасофт. Мы строим экосистему Digital Q — платформу для enterprise‑разработки — и сейчас решаем задачу, которая касается всех: как зашить безопасность внутрь конвейера так, чтобы она работала сама, а не превращалась в бумажный ритуал перед релизом. ГОСТ Р 56939–2024 уже вступил в силу, нейронки залезли в пайплайны, а инциденты почему‑то не кончаются. Чтобы понять ожидания рынка я собрал экспертов на обсуждение нового ГОСТа и проблем безопасности. 

Получился интересный разговор: реальные кейсы (включая прекрасную историю про PGP‑пароль во фронтенде, который прошел все сканеры), грабли с библиотеками и архитектурой, ИИ в код‑ревью и его ограничения, новый ГОСТ — полезен или вреден, и минимальный чек‑лист выживания на 2026 год. Я тоже местами не удержался и высказался.

Кому удобнее смотреть — полная версия на Rutube. Спорить и задавать вопросы лучше всего в Telegram‑канале Департамент разработки. Там уже много реальных разработчиков, можно свободно обсуждать любые темы. 

Сканер все зеленое, а в проде — дыра

«Первый провал — даже не в каких‑то наложенных средствах, а в том, что люди не занимаются безопасностью и не имеют этих компетенций на самом базовом уровне. Вовлеченность должна быть у каждого — каждый разработчик должен понимать, что он занимается безопасностью кода и что этому нужно уделять внимание. У меня есть примеры вопиющих ошибок, которые были пропущены всеми средствами автоматического тестирования и практически приводили к вторжениям. Утилиты — сканирование, линтеры — они позволяют сделать безопасность рутиной: люди начинают задумываться, что это нужно. Пусть ложных срабатываний много, но процесс запускается. Однако прежде всего — люди», — отметил Константин Янсон, ведущий эксперт ICL Services в области сетевых технологий и информационной безопасности.

«Безопасность начинается с четко сформулированных векторов угроз, — убежден Максим Силаев, основатель Arch Expert consulting. — Когда мы понимаем, от чего защищаемся, лучше пусть их будет пять, но они будут нам предельно понятны, — чем сто непонятных. Говорить о безопасности кода рано, пока мы не решили, от чего конкретно защищаемся. Это хакеры? Инсайдеры? Переполнение буфера? Когда мы это определим, у нас появится понятный список действий. И, что еще важнее, мы поймем, какие риски можем на себя принять, а какие обязаны закрыть».

А вот как выглядит ситуация, когда модель угроз не определена, а разработчик — вроде бы грамотный.

«Мы расследовали обращения фронтенда к базе данных, — рассказал Янсон. — Выяснилось, что разработчик сделал прямой доступ из фронтенда к БД — ему было так проще. Причем компания занимается безопасностью, человек грамотный: он не просто пароль вписал, а зашифровал его PGP‑ключом, чтобы фронт забирал файл и расшифровывал. Никакие тесты это не обнаруживали — все работало „безопасно“ с точки зрения автоматики. Нашли совершенно случайно, по аномальным соединениям. Больше никаких показателей не было. Наша задача — сделать так, чтобы взломать было тяжело и невыгодно. Но если люди не вовлечены, такие вещи будут случаться. Сторонние библиотеки — еще один источник сюрпризов. OpenSSL — наверное, все ей пользуются — каждый год регулярно приносит таких уязвимостей, что волосы дыбом. Приходится очень быстро обновлять свои продукты, хотя, казалось бы, что мы тут можем сделать. А буквально в декабре была React4Shell. Мы искали ее вместе с коллегами — прежде всего нужна инвентаризация. Не у всех заказчиков было даже понимание, есть ли это у них где‑то. Ретроспективно смотришь: а могли ли мы что‑то сделать заранее? Вряд ли».

«У нас несколько эшелонов. Есть требования, как код должен быть обработан до того, как он выйдет в прод. Первый уровень — человеческий: на код‑ревью другие специалисты просматривают каждый коммит. Дальше — наши скрипты и линтеры, которые проверяют готовность кода со стороны веб‑разработки. Затем уже на пайплайнах внутри контура банка по требованиям безопасников код прогоняется еще раз — и на уязвимости в самом коде, и на транзитивные зависимости по библиотекам. Грубо говоря, до продакшена код проходит и ручные, и автоматические фильтры на каждом этапе. Комплексная работа со всех сторон», — говорит Алексей Кононов, ведущий инженер разработки Газпромбанка.

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

Архитектура ошибок: линтер против плохих решений

«Инструменты совершенствуются, мы их массово внедряем, но основная ошибка совершается не на уровне кода, а на уровне решений, — считает Максим Силаев. — Векторы угроз не определены, приоритеты не расставлены, а необратимые архитектурные выборы принимаются непонятно кем. Вопрос на ступеньку выше, чем код. Да, мы можем обвешаться линтерами, можем провести код‑ревью — но против архитектурных ошибок это не спасет. Продукты стали комплексными. Раньше мы писали десктопные приложения — там все понятно: сломалось — значит сломалось. А сейчас комплексная интеграция, особенно в крупных компаниях и банках. Я постоянно вижу одно и то же: из‑за отказа интеграции или поменявшихся API‑контрактов ломается, казалось бы, совершенно не связанный модуль».

«Отдельный тип угроз — сторонние зависимости. Контролировать чужой код невозможно, но и игнорировать его нельзя. Единственное, что можно делать, — это следить. Менеджмент уязвимостей: не только своего продукта, но и всех сторонних библиотек. Нужно первыми — раньше других — увидеть, что уязвимость появилась. А если появился еще и эксплойт — все, это красный флаг: сразу бежать, закрывать, предупреждать, — объяснил Янсон. — Это не всегда происходит. Особенно разработчики с невысоким грейдом: удобно — взяли, подключили. А может быть, никто и не узнал, что они этой библиотекой пользуются».

И речь не о теоретической опасности. Янсон описал механику, которая превращает любую уязвимость в оружие за считанные часы:

«В интернете существуют исследовательские базы данных, где пронумерованы все ресурсы — например, все сайты с определенной версией React или любой другой библиотекой. Разработчики иногда замечают странные запросы в логах — это формируются такие базы: что установлено, какие версии, какие зависимости. А потом, когда появляется уязвимость, — все очень просто. Берется эксплойт, вкидывается в эту базу — и вот вам готовый список всех адресов, где эта уязвимость есть. С момента публикации эксплойта до его использования остаются считанные минуты. Если вы кому‑то нужны — вы не успеете. Поэтому одной разработкой не обойтись: нужны наложенные средства — WAF, IPS и так далее. Защита многогранна».

«Если говорить про библиотеки — это изолированное хранилище, типа Nexus, где хранятся только доверенные версии. Не последний патч, а тот, который давно проверен сообществом и стабилен. Плюс есть CVE‑базы, где можно посмотреть, в каких библиотеках обнаружены уязвимости и на какие версии пока не стоит обновляться. Банк работает через такую консервативную тактику. Даже если кто‑то хочет подключить новую библиотеку, ее сначала нужно заявить отдельно — если ее нет в безопасном репозитории, она просто не пройдет пайплайн», — рассказывает Алексей Кононов.

Но даже при такой многоуровневой защите появляется новый фактор, который меняет правила игры: нейронные сети в процессе анализа кода.

Нейронка в код-ревью: прорыв или утечка?

«Докладчики Яндекса рассказали о серьезных прорывах: нейронки внедрены во все пайплайны, помимо статического анализа код дополнительно прогоняется через нейросеть. Серьезные показатели по обнаружению плохого, грязного кода. Нейронка отписывает замечания прямо в мерж‑реквесте: здесь поправить, здесь такое замечание. По сути, код‑ревью проводит LLM — похоже на то, как это реализовано в GitHub Copilot. Но на вопрос слушателя конференции „а какую нейронку вы используете?“ представитель Яндекса ответил: давайте я вам на кофебрейке расскажу. Все поняли, что это явно не Алиса и не GigaChat. И тут возникает вопрос: весь код прогоняется, анализируется, уходит куда‑то. Как с этим быть? Финансовый сектор, по‑видимому, пока не готов к такому радикальному шагу», — поделился наблюдением Алексей Кононов.

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

«Если в коде написана какая‑то „каша‑малаша“ — например, из‑за излишнего „шифрования“ и усложнения — странно, что на код‑ревью никто не задал простой вопрос: »А что здесь вообще происходит?“ Дело не в том, что разработчик недостаточно квалифицирован. Важно другое: код должен быть понятен не только его автору, но и любому другому человеку, который будет с ним работать. Иногда лучше написать пять строк вместо двух, если так логика становится очевидной. Тогда любой разработчик сразу поймет, что происходит. Именно такие вещи и должны выявляться на код‑ревью«.»

«Когда дело касается критической инфраструктуры, мы не просто опираемся на свои знания и технологический стек. Нам приходится консультироваться напрямую — обращаемся в ФСБ, в ФСТЭК, буквально пишем: можно ли так сделать или нельзя. Даже для самых безопасных песочниц все равно нужен аудит. Проекты, связанные с большими языковыми моделями, почти целиком построены на импортных компонентах — и построить классический контур информационной безопасности здесь очень тяжело. Экспериментальные запуски ИИ у нас полностью отрезаны от внешней сети, живут во внутреннем контуре предприятия. Попасть туда можно только аппаратным способом. Нейрон живет в устройстве и дальше никуда не выходит: устройство получает данные в ограниченном формате, а наружу выходит только аналитическая выжимка. Это промышленная история — машинное зрение, контроль процессов. Только так», — говорит Андрей Вишняков, основатель нейро‑артели «Полезные цифры».

«Но, для малого бизнеса вопросы информационной безопасности — это что‑то, чего они не касались и не касаются никогда, — продолжает Вишняков. — Этой процедуры нет в бизнес‑модели, нет в бизнес‑процессе, нет в статьях расхода. Гигиены нет вообще. Собственники, на которых и так по 50 ролей, просто берут на себя еще и эту. Мы, конечно, выдаем инструкции, даем протоколы — как обеспечить хотя бы инфраструктурную безопасность у себя в бизнесе. Но я не могу сказать, что на текущий момент все эти задачи решены и что мы стопроцентно гарантируем безопасность своим клиентам».

Получается парадоксальная картина: на одном полюсе — Яндекс с нейросетью в каждом пайплайне, на другом — микробизнес, который вообще не знает, что такое CVE‑база. И именно в этот разрыв приходит новый ГОСТ Р 56939–2024.

ГОСТ — зубная щетка, а не лекарство

«Представьте: государство придумало правила дорожного движения. А ему отвечают — мы и так умеем переходить дорогу, нас никогда не сбивали, нам и права не нужны, и полиция не нужна, — провел аналогию Константин Янсон. — Можно привести множество примеров неправильного применения правил, злоупотреблений, коррупции — но в целом есть направление, которое позволяет отрасли двигаться. ГОСТ не придуман с потолка — он основан на мировых практиках. Переведите его на английский, посмотрите, где это уже применяется. Другое дело, что многие боятся штрафов: у нас часто бывает — внедрили закон и пошли всех штрафовать. Об этом я пока не слышал. Зато появился единый документ, и его начнут изучать в университетах и техникумах. Многие разработчики приходят оттуда уже программистами, но безопасности их никто не учил. Теперь хотя бы будут знать, что ГОСТ существует».

«Допустим, есть ГОСТ на чистку зубов. Гарантирует ли он отсутствие кариеса? Конкретный человек может чистить неправильно, перепутать пасту с шампунем или вообще заниматься этим для вида. Но по стране в целом процент кариеса уменьшается. То же самое здесь: эта процедура заставляет людей задуматься, где у них уязвимости, зафиксировать это, оформить артефакты. А при наличии артефактов очень легко проверить вещи, которые раньше проверить было невозможно. Меняется структура кода, меняется структура документации — и это реально облегчает контроль качества», — отмечает Александр Сахаров. 

«Это правильное направление, основанное на мировых практиках и собирательном опыте. Вопрос — как его применять: безусловно, это создает бюрократические сложности. Мелкие и микрокомпании будут искать способы соответствовать хотя бы на бумаге — аутсорсить безопасность, что‑то придумывать. Но в целом общую ситуацию это улучшит. Кариес возникает не только от того, что мы неправильно чистим зубы, а по тысяче других причин. ГОСТ на утреннюю чистку не определяет, что мы делаем с зубами в течение остального дня. Это лишь первый шаг. И это не про конкретную технологию — это про подход. Рынок с 2016 года изменился кардинально: стало больше интеграций, и к таким архитектурам нужны новые требования безопасности, которых раньше просто не существовало», — считает Максим Силаев.

Но у ГОСТа есть и обратная сторона — та, которую чувствуют на себе небольшие команды. 

«Крупные компании не пострадают: у них все давно реализовано, есть целые департаменты, специалисты, бюджеты. А вот стартапы и мелкие компании, у которых все впритык, — для них новая обязанность означает увеличение сроков. И вот что важно: по сути, ГОСТ убивает саму идею Agile — максимально быструю доставку продукта заказчику. Смысл первой итерации в том, чтобы закрыть глаза на некоторые вещи и дать MVP — минимальное жизнеспособное решение, — чтобы заказчик оценил, нравится ему это или нет. Теперь эта первая итерация будет сильно заторможена. И пострадает в первую очередь заказчик», — говорит Алексей Кононов.

«ГОСТ создает конфликт интересов. Для среднего и крупного бизнеса — это отлично, это их усиливает. А для малого и микробизнеса — очередная палка в колеса. Себестоимость стартапа или продукта вырастет, точка входа поднимется и приблизится к среднему бизнесу. Компания с годовым оборотом 50–100 миллионов рублей просто не сможет инфраструктурно содержать и обслуживать этот процесс внутри себя. При этом ГОСТ я поддерживаю: инди‑разработка — это романтично, но сейчас России нужно решать критически важные задачи национального масштаба. Этот ГОСТ даст канву, чтобы перекрыть хотя бы критическую инфраструктуру. Но насколько ГОСТ будет гибким? Технологии меняются не только в смысле нейросетей — это и методологии управления, и подходы к продукту. Циклы бывают квартальные, месячные, мир может перевернуться за считанные недели. Успеет ли регламентация за всем этим? Мне кажется, нам не хватает документа, который отвечает на вопрос „зачем“, а не „как“. Гигиена — это набор принципов, а не набор правил. Это про то, почему нужно чистить зубы, а не про то, какой щеткой. С вопросом „как“ мы разберемся сами — в зависимости от времени и технологического стека», — отмечает Андрей Вишняков.

Встроить, а не прикрутить

Если ГОСТ задает направление, то кто решает проблему исполнения — особенно для тех, у кого нет целого департамента безопасности?

«Вспомните, как в Microsoft Word появилась проверка орфографии — и все забыли, как правильно писать, потому что инструмент делает это за тебя. Здесь тот же принцип. Если внутри IDE, внутри экосистемы разработчика все процессы уже заложены и артефакты формируются автоматически — это не усложняет разработку, а удешевляет ее и повышает качество. А вот если руками писать документы, потом отправлять их куда‑то, согласовывать и фиксировать штампами — тогда да, получится имитация бурной деятельности. Наша экосистема уже сейчас позволяет производить профессиональный enterprise‑софт: в ней заложены процессы автотестирования, развертывания, аналитики, проектной архитектуры — юнит‑тесты генерируются автоматом, документация формируется автоматом. Теперь основная идея — включить в этот конвейер процессы, влияющие на безопасность. Покрытие тестами, описание API, генерация документации — все это должно делаться платформой, а не руками. Если делать руками — всему смерть: растет time‑to‑market, растут затраты. А если делает платформа — это проходит незаметно и дает супер результат. Наша задача — чтобы любая команда, которая работает на нашей системе, получала эти процессы из коробки», — говорит Александр Сахаров.

«Люди — на первом месте. С первого момента, как начинается разработка, нужно вовлекать всех сотрудников в безопасность. Этот процесс должен быть на каждом этапе. Я как консалтер прихожу позже — и вижу: потом это сделать невозможно. Кто‑то говорит „дорого“ — нет, не дорого, а практически невозможно. Хотя мы, конечно, стараемся делать невозможные вещи. Но как только появляется вовлеченность всей команды — безопасность кода сразу улучшается. А инструменты после этого — уже мелочи. Это не значит, что безопасник сделает все идеально. Может быть полная профанация — испортить можно по‑разному. Тем не менее это дает значительно больше шансов, что разработка будет безопасной», — считает Константин Янсон.

«Присутствие безопасника в команде с первого дня — это очень важная практика. Потому что когда security review проводится перед самым выпуском, его обычно пытаются пройти формально: нужно как‑то „впарить“, чтобы пройти очередной этап и наконец выкатить продукт. А если безопасник присутствует с первого дня, его задачи лежат в общем бэклоге, он наравне со всеми участвует в подготовке продукта — и риск неожиданных открытий на финише существенно снижается. Продукт выходит значительно более готовым, чем когда безопасность подключают в последний момент», — подтверждает Максим Силаев. 

Что делать?

«Первое — составить список угроз: понимать, кто на нас может напасть и откуда. Определить векторы. Второе — на архитектурном уровне разделить зоны ответственности: проработать, какой компонент за что отвечает, какая зона ответственности у конкретного человека, команды. Это именно архитектурный уровень, не уровень кода», — резюмировал Максим Силаев.

«Минимально — внутренний регламент в команде и прогон кода через базовые проверки еще в процессе разработки, а не в постпродакшене. Для архитекторов многоуровневых систем с кучей интеграций — хотя бы ручной аудит: смотреть, где могут быть уязвимости, тестировать вручную. Я тут без пафосных советов — мы сами внизу, в грязи валяемся. Но минимальную гигиену используйте, пожалуйста. Не забывайте: даже микробизнес, даже те, кто работает с маркетплейсами или услугами, — все мы операторы персональных данных. И утечка персональных данных — это как раз главная брешь малого бизнеса. Никто не ломает инфраструктуру, не проводит агрессивных атак. Потихоньку высасываются данные, кто‑то использует их как аналитический ресурс — все происходит в тени, а бизнес даже не знает, что им кто‑то пользуется», — отмечает Андрей Вишняков.

«Совет тимлидам и ведущим разработчикам: на каждом этапе спросите себя — что мы можем здесь добавить по безопасности? На этапе написания кода — линтеры, скрипты, код‑ревью. Тестирование — юнит‑тесты, интеграционные тесты, покрытие кода. CI/CD — квалити‑гейты, анализаторы зависимостей. Продакшен — закрыть source maps, провести обфускацию, настроить грамотное логирование, чтобы в случае инцидента можно было быстро разобраться, что произошло и откуда растут ноги. На каждом этапе — преграда для злоумышленника. Через Kibana, через Sentry, через продуктовую аналитику и Яндекс.Метрику мы видим подозрительную активность: одинаковые IP, резкие всплески запросов. Все это тут же отображается на графиках, безопасникам и тестировщикам валятся алерты — и они начинают реагировать. То есть до продакшена — множество фильтров: человеческий фактор, автоматика анализа кода. А после — сбор информации через агрегаторы событий. Защита не заканчивается на деплое», — говорит Алексей Кононов.

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

«ГОСТы, правила, стандарты — они позволяют на раннем этапе, еще когда люди учатся в университетах и техникумах, понять, что вообще такое безопасность. Тема емкая, и без формализованной точки входа в нее сложно попасть. А когда есть ГОСТ — появляется структура, от которой можно оттолкнуться», — уверен Константин Янсон.

«В современном мире не думать об информационной безопасности — фатально для бизнеса. Поэтому самая главная практика — озаботиться тем, чтобы у вас был специалист, человек, который понимает хотя бы ГОСТ, и чтобы в соответствии с этим ГОСТом и с теми уязвимостями, которые существуют в мире, были выстроены контрольные точки. А вообще писать сегодня код руками, без платформы — все равно что выходить в открытый космос без скафандра», — финализирует Александр Сахаров.