Разбираем актуальные темы и тренды в рамках кибербезопасности и ИТ
Вебинары
Решения
Детальный анализ изменений 187-ФЗ и проекта Постановления Правительства РФ № 127
Укрепление безопасности КИИ
Услуги
Как бизнесу защититься от киберугроз и не раздуть бюджет
Кейс компании «ДОМА» и УЦСБ SOC
Сервисы
Apsafe
Облачная DevSecOps-платформа для непрерывного анализа защищенности приложений
FAQ: ответы на вопросы к эфиру «Безопасная разработка
под новые требования: от 117 приказа ФСТЭК России до стандартов безопасности ИИ»
25 февраля 2026
17 февраля состоялся эфир «Безопасная разработка под новые требования: от 117 приказа ФСТЭК России до стандартов безопасности ИИ». Эксперты УЦСБ, Renue, CodeScoring и Академии АйТи обсудили ключевые изменения в регулировании безопасной разработки, какие стандарты безопасности для искусственного интеллекта появляются в России, вопросы импортозамещения и прогнозах развития регулирования на 2026-2027 годы.
В этом материале собрали ответы на самые интересные вопросы зрителей
17 февраля состоялся эфир «Безопасная разработка под новые требования: от 117 приказа ФСТЭК России до стандартов безопасности ИИ». Эксперты УЦСБ, Renue, CodeScoring и Академии АйТи обсудили ключевые изменения в регулировании безопасной разработки, какие стандарты безопасности для искусственного интеллекта появляются в России, вопросы импортозамещения и прогнозах развития регулирования на 2026-2027 годы.
В этом материале собрали ответы на самые интересные вопросы зрителей
Какие требования к подрядчикам предъявляются в рамках 117 приказа, как подтвердить, что подрядчик их выполняет?
Даниил Коновалов, инженер информационной безопасности (Information Security Engineer), Renue:
«Следует отметить, что Приказ 117 - не единственный регуляторный документ, и, Заказчик, почти в ста процентах случаев, «приправляет» договор своими требованиями.
Но, гарантированно, будут следующие:
В части подтверждения выполнения требований:
«Следует отметить, что Приказ 117 - не единственный регуляторный документ, и, Заказчик, почти в ста процентах случаев, «приправляет» договор своими требованиями.
Но, гарантированно, будут следующие:
- Строгая регламентация порядка предоставления доступа к информации, в т.ч. обязанность исполнения внутренних регламентов Заказчика по ИБ;
- Организация тестового контура системы, полный запрет на доработки «на живую»;
- Этот пункт пока есть далеко не у всех, но, прогнозирую, что, со вступлением в силу Приказа № 117, появится у большинства: Разработка должна производиться согласно требованиям ГОСТ 56939-2024. Многие будут включать этот пункт «под копирку», но это не избавит подрядчиков от его исполнения.
В части подтверждения выполнения требований:
- Крупные Заказчики будут использовать свои пайплайны для автоматизированной проверки - здесь всё фундаментально просто - код загружается в систему контроля версий Заказчика, если он не проходит через все заданные проверки - отправляется на доработки;
- Почти наверняка останется более щадящий способ подтверждения: Отчетность. Это когда в рамках закрытия работ (по этапу, по контракту), подрядчик представляет Акт о соответствии. Его состав обычно фиксируется в договоре и составление лежит полностью на плечах подрядчика.
- Не исключаю, что некоторые Заказчики повесят исполнение своих обязательств, и добавят к вышеизложенному отчетность по показателю защищенности - 2 раза в год, по показателю уровня зрелости защиты - 1 раз в год, по итогам календарного года - годовой отчет
Частные компании готовы вкладываться в развитие контролируемого репозитория доверенного ПО?
Лев Новоженин, руководитель службы PreSale, CodeScoring:
«Контролируемый репозиторий — это репозиторий, в котором соблюдаются принципы безопасности и применение инструментальных средств проверки хранимых артефактов или кода.
Да, частные компании действительно готовы и уже вкладывают ресурсы в контролируемые репозитории. Такая тенденция обусловлена необходимостью централизованно контролировать цепочку поставки (supply chain), контролировать использование сторонних компонентов, обеспечить безопасность и целостность ПО. Доверенные репозитории помогают компаниям перейти к проактивному управлению рисками.»
«Контролируемый репозиторий — это репозиторий, в котором соблюдаются принципы безопасности и применение инструментальных средств проверки хранимых артефактов или кода.
Да, частные компании действительно готовы и уже вкладывают ресурсы в контролируемые репозитории. Такая тенденция обусловлена необходимостью централизованно контролировать цепочку поставки (supply chain), контролировать использование сторонних компонентов, обеспечить безопасность и целостность ПО. Доверенные репозитории помогают компаниям перейти к проактивному управлению рисками.»
И все-же, можно ли добиться безусловного доверия к ИИ?
Николай Павлов, архитектор MLSecOps и AI Governance, Академия АйТи:
«Нет, безусловное доверие к ИИ не только недостижимо, но и нежелательно с точки зрения безопасности и этики. Если кратко — человек всегда должен и будет контролировать ИИ, прогнозируя его развитие, риски и нивелируя угрозы.
Сегодня многие современные ИИ-системы, особенно на основе глубокого обучения (то есть там, где есть нейроны, нейросети), работают как «чёрные ящики» с триллионами параметров, что делает их решения непрозрачными и труднообъяснимыми. А агенты ИИ имеют еще больше прав и полномочий, и в этом случае вероятности рисков больше в разы.
При этом человеческое доверие опирается на общие этические нормы, культуру, воспитание и способность к моральной рефлексии. ИИ же не обладает сознанием или способностью адаптировать поведение на основе социального восприятия. Его установки статичны и заданы обучающими данными, архитектурой, другими компонентами. Природа ИИ все же другая — и я считаю, что люди все еще не до конца это учитывают.
Безусловное доверие к ИИ опасно еще и потому, что это может привести к критическим ошибкам в медицине, транспорте, финансах и других сферах, где цена ошибки высока, критическая. Как и любую ИТ-систему ИИ-систему нужно проверять и перепроверять.
При этом угрозы со стороны злоумышленников растут вместе с возможностями ИИ. Злоумышленники могут эксплуатировать слепое доверие, создавая системы, которые выглядят надёжно, но действуют вредоносно. Они могут вмешиваться в наши ИИ-системы, и злоупотреблять нашим доверием к ним.
Согласно глобальным исследованиям, лишь 40-50% людей готовы доверять ИИ-системам в целом. И да, со временем эта цифра растет. Это не недостаток, а здоровый скептицизм. Люди видят, что ИИ становится продуктивнее, и там, где раньше ошибался — становится надежнее.
А ведь когда-то ИИ не было… На заре его появление доверие к нему было минимально, около 0%. Тренд очевидный, с этим надо что-то делать, нужно активно пропагандировать MLSecOps и AI Governance, развивать эти направления, чтобы всегда контролировать ИИ-системы, а не делегировать им все возможные процессы бесконтрольно.
Считаю, что будущее России в том числе в развитии ИИ-грамотности, чтобы простые пользователи понимали, когда и почему можно полагаться на ИИ-систему, а когда требуется человеческое вмешательство. Аналогично и разработчики ИИ — должны обеспечивать контроль, мониторинг, прозрачность, этичность, объяснимость и, главное, безопасность.»
«Нет, безусловное доверие к ИИ не только недостижимо, но и нежелательно с точки зрения безопасности и этики. Если кратко — человек всегда должен и будет контролировать ИИ, прогнозируя его развитие, риски и нивелируя угрозы.
Сегодня многие современные ИИ-системы, особенно на основе глубокого обучения (то есть там, где есть нейроны, нейросети), работают как «чёрные ящики» с триллионами параметров, что делает их решения непрозрачными и труднообъяснимыми. А агенты ИИ имеют еще больше прав и полномочий, и в этом случае вероятности рисков больше в разы.
При этом человеческое доверие опирается на общие этические нормы, культуру, воспитание и способность к моральной рефлексии. ИИ же не обладает сознанием или способностью адаптировать поведение на основе социального восприятия. Его установки статичны и заданы обучающими данными, архитектурой, другими компонентами. Природа ИИ все же другая — и я считаю, что люди все еще не до конца это учитывают.
Безусловное доверие к ИИ опасно еще и потому, что это может привести к критическим ошибкам в медицине, транспорте, финансах и других сферах, где цена ошибки высока, критическая. Как и любую ИТ-систему ИИ-систему нужно проверять и перепроверять.
При этом угрозы со стороны злоумышленников растут вместе с возможностями ИИ. Злоумышленники могут эксплуатировать слепое доверие, создавая системы, которые выглядят надёжно, но действуют вредоносно. Они могут вмешиваться в наши ИИ-системы, и злоупотреблять нашим доверием к ним.
Согласно глобальным исследованиям, лишь 40-50% людей готовы доверять ИИ-системам в целом. И да, со временем эта цифра растет. Это не недостаток, а здоровый скептицизм. Люди видят, что ИИ становится продуктивнее, и там, где раньше ошибался — становится надежнее.
А ведь когда-то ИИ не было… На заре его появление доверие к нему было минимально, около 0%. Тренд очевидный, с этим надо что-то делать, нужно активно пропагандировать MLSecOps и AI Governance, развивать эти направления, чтобы всегда контролировать ИИ-системы, а не делегировать им все возможные процессы бесконтрольно.
Считаю, что будущее России в том числе в развитии ИИ-грамотности, чтобы простые пользователи понимали, когда и почему можно полагаться на ИИ-систему, а когда требуется человеческое вмешательство. Аналогично и разработчики ИИ — должны обеспечивать контроль, мониторинг, прозрачность, этичность, объяснимость и, главное, безопасность.»
Как стартапу доказать энтерпрайзу, что его ПО безопасно?
Отвечает Николай Павлов, архитектор MLSecOps и AI Governance, Академия АйТи
«Главное доказательство безопасности — это, конечно, не определенное разовое действие, например, яркая и эффектная презентация, а целенаправленная (долгосрочная!) пошаговая стратегия, сочетающая коммуникацию, встречи с лицами, принимающими конечные решения (не всегда это директора, часто — сеньоры, техлиды, архитекторы), также сочетающая прозрачную документацию и демонстрацию зрелых процессов в компании. Этика общения, дресс-код, грамотная коммуникация – всё это играет роль.
По поводу самого ПО, нужно доходчиво и просто объяснять все преимущества, какие есть: шифрование данных, управление уязвимостями, логирование, противодействие инцидентам, автоматизация отчетности, польза для бизнеса и т.п. Объясняем простым языком, потому что, если это презентация групповая, даже опытные специалисты порой могут не понимать отдельных специфичных терминов.
Также можно показать уже имеющиеся отзывы текущих клиентов, дать их названия, контакты (с их согласия, конечно), оценки известных экспертов, сертификации, объяснить и то, что стартап полностью соблюдает установленные нормативно-правовые требования.
Разработанный процессинг (SLA), индикаторы SLI, SLO, KPI, тоже вызывают доверие. Техническая поддержка также важна, это нужно подсветить обязательно, причем обозначить гарантированное время реагирования на любой инцидент (10 минут, час, 2 ч).
Отдельно показываем плейбуки и ранбуки, техническую документацию, чек-листы, руководства, инструкции. Как для компаний-клиентов стартапа, так и для сотрудников самого стартапа — это сильно помогает доверию.
Ну и советы по коммуникации с энтерпрайзом, нужно говорить грамотно, не «у нас вот тут есть фаервол», а «мы снижаем риск несанкционированного доступа на …%, благодаря...».
Можно сделать файл, где сразу написать часто задаваемые вопросы и ответы на них.
Желательно также дать энтерпрайзу протестировать решение стартапа в изолированной среде с усиленным мониторингом. И при любых моментах важно держать марку! Нужно вселять уверенность, дарить позитив, показывая экспертизу. Нужно быть готовыми максимально идти на встречу каждому отдельному клиенту и приносить пользу бизнесу.»
«Главное доказательство безопасности — это, конечно, не определенное разовое действие, например, яркая и эффектная презентация, а целенаправленная (долгосрочная!) пошаговая стратегия, сочетающая коммуникацию, встречи с лицами, принимающими конечные решения (не всегда это директора, часто — сеньоры, техлиды, архитекторы), также сочетающая прозрачную документацию и демонстрацию зрелых процессов в компании. Этика общения, дресс-код, грамотная коммуникация – всё это играет роль.
По поводу самого ПО, нужно доходчиво и просто объяснять все преимущества, какие есть: шифрование данных, управление уязвимостями, логирование, противодействие инцидентам, автоматизация отчетности, польза для бизнеса и т.п. Объясняем простым языком, потому что, если это презентация групповая, даже опытные специалисты порой могут не понимать отдельных специфичных терминов.
Также можно показать уже имеющиеся отзывы текущих клиентов, дать их названия, контакты (с их согласия, конечно), оценки известных экспертов, сертификации, объяснить и то, что стартап полностью соблюдает установленные нормативно-правовые требования.
Разработанный процессинг (SLA), индикаторы SLI, SLO, KPI, тоже вызывают доверие. Техническая поддержка также важна, это нужно подсветить обязательно, причем обозначить гарантированное время реагирования на любой инцидент (10 минут, час, 2 ч).
Отдельно показываем плейбуки и ранбуки, техническую документацию, чек-листы, руководства, инструкции. Как для компаний-клиентов стартапа, так и для сотрудников самого стартапа — это сильно помогает доверию.
Ну и советы по коммуникации с энтерпрайзом, нужно говорить грамотно, не «у нас вот тут есть фаервол», а «мы снижаем риск несанкционированного доступа на …%, благодаря...».
Можно сделать файл, где сразу написать часто задаваемые вопросы и ответы на них.
Желательно также дать энтерпрайзу протестировать решение стартапа в изолированной среде с усиленным мониторингом. И при любых моментах важно держать марку! Нужно вселять уверенность, дарить позитив, показывая экспертизу. Нужно быть готовыми максимально идти на встречу каждому отдельному клиенту и приносить пользу бизнесу.»
Запись эфира
Напишите нам на cybersec@ussc.ru или оставьте заявку
Нужна консультация
по внедрению безопасной разработки?
Нажимая кнопку «Отправить», я даю свое согласие на обработку моих персональных данных, в соответствии с Федеральным законом от 27.07.2006 года №152-ФЗ «О персональных данных», на условиях и для целей, определенных в Согласии на обработку персональных данных