Информ::Доверенная Разработка

Информационное сообщение о применении методики опубликовано на сайте ФСТЭК

Коллеги, доброго утра! На сайте ФСТЭК России опубликовано информационное сообщение о новой версии Методики ВУ и НДВ, а также - и впервые - выписка из Методики (6-4 УД). Методика вступила в действие с 12 мая 2026, все новые испытания необходимо планировать уже с ее учетом. Также считаю, что не будет нарушением NDA поделиться полученным ответом на вопрос: "Как быть с уже идущими работами"? Если работа идет давно и заканчивается в окрестностях июня-июля, то можно завершить по ранее утвержденному плану. Чем дальше от текущей даты - тем больше вопросов будет вызывать предоставление материалов, подготовленных в соответствии с прошлой версией Методики. Обратите внимание на Раздел 1 Методики. Явно зафиксирована рекомендация опираться на Методику при выстраивании процессов РБПО в соответствии с ГОСТ Р 56939-2024. Обратите внимание на Раздел 5 Методики. Там появились принципиально новые и важные моменты, в т.ч. таблица недостатков - отход от бинарной логики тех. заключения, в котором традиционно пишут, что "всё идеально".

Приказ ФСТЭК о внесении изменений в Положение о системе сертификации http://publication.pravo.gov.ru/document/0001202604210031?index=2

Утверждены Меры и Мероприятия к 117 Приказу ФСТЭК России.

Методическая рекомендация № 2026-03-014 | Уровень критичности: 3 Область: Поддержка безопасности эксплуатируемых средств защиты информации (далее - СЗИ). Тип недостатка: Отсутствие поддержки разработчиком безопасности эксплуатируемых СЗИ, в том числе устранения известных уязвимостей программных компонентов СЗИ. Описание: В соответствии с требованиями информационного письма от 26 сентября 2024 г. № 240/24/4436 изготовители СЗИ, испытательные лаборатории и органы по сертификации при проведении сертификации СЗИ, включающих в свой состав заимствованные программные компоненты с открытым исходным кодом (далее - заимствованные компоненты), должны проводить сертификационные испытания СЗИ и осуществлять их поддержку безопасности в соответствии с планами испытаний заимствованных компонентов и планами поддержки безопасности заимствованных компонентов. При выявлении уязвимостей заимствованных программных компонентов СЗИ в соответствии с пунктом 22 Требований по безопасности информации, устанавливающих уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденных приказом ФСТЭК России от 2 июня 2020 г. № 76, разработчику СЗИ необходимо: - в кратчайшие сроки разработать компенсирующие меры по защите информации или ограничения по применению СЗИ, а также доведение информации о недостатках и указанных мерах и ограничениях до потребителей; - разработать обновления программного обеспечения СЗИ, или разработать меры по защите информации, нейтрализующих недостаток; - довести информацию об обнаруженном недостатке до банка данных угроз безопасности информации, ведение которого осуществляется ФСТЭК России. В соответствии с пунктом 83 Положения о системе сертификации средств защиты информации, утвержденного приказом ФСТЭК России от 3 апреля 2018 г. № 55, действие сертификата соответствия приостанавливается в случае установления факта несоответствия сертифицированного СЗИ требованиям по безопасности информации на основании поступившей в ФСТЭК России информации, в том числе о наличии в сертифицированном средстве защиты информации уязвимостей или недекларированных возможностей. ФСТЭК России осуществляет и совершенствует процедуру контроля за устранением угроз безопасности информации, возникающих в сертифицированных СЗИ вследствие наличия известных уязвимостей в заимствованных компонентах СЗИ. За ноябрь-декабрь 2025 г. приостановлено действие сертификатов соответствия для 2-х сертифицированных СЗИ. Рекомендации: 1. Разработчикам СЗИ обеспечить реализацию мероприятий по выявлению и устранению уязвимостей в заимствованных компонентах СЗИ на постоянной основе. 2. Работникам испытательных лабораторий и органов по сертификации проводить оценку уязвимостей в заимствованных компонентах СЗИ. 3. Разработчикам СЗИ в целях оперативного выявления и устранения уязвимостей в заимствованных компонентах СЗИ использовать автоматизированные средства, в том числе инструментальные средства композиционного анализа. В соответствии с действующими национальными стандартами в области РБПО контроль наличия известных уязвимостей должен осуществляться в автоматическом (автоматизированном) режиме с использованием инструментальных средств композиционного анализа. Дополнительные информационные материалы: - Положение о системе сертификации средств защиты информации, утвержденное приказом ФСТЭК России от 3 апреля 2018 г. № 55; - Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий, утвержденные приказом ФСТЭК России от 2 июня 2020 г. № 76; - ГОСТ Р 56939-2024 "Безопасная разработка. Общие требования"; - проект ГОСТ "Безопасная разработка. Композиционный анализ ПО".

Методическая рекомендация № 2026-03-013 | Уровень критичности: 3 Область: Тестирование механизмов реализации функций безопасности (далее - ФБ). Типы недостатков: Неполная инвентаризация реализуемых средством защиты информации (далее - СЗИ) ФБ, недостаточный объем тестирования реализующего ФБ программного кода. Описание: С целью сокращения объемов сертификационных испытаний, а также при реализации процессов разработки безопасного программного обеспечения разработчики СЗИ и испытательные лаборатории в ряде случаев выполняют некачественную инвентаризацию, неполную декларацию и, как следствие, недостаточное тестирование механизмов (кода) СЗИ, отвечающих за реализацию ФБ. Типичным примером, в частности, при сертификации СЗИ на соответствие техническим условиям (в части декларируемых ФБ), является описание в документации СЗИ только ФБ, связанных с группами мер ИАФ, УПД и РСБ (см. Приказ № 17), и только в минимальном их объеме - без декларации всех возможностей и режимов работы данных механизмов. Частным примером является неполная инвентаризация механизмов ИАФ, поддерживаемых веб-серверами и серверами приложения, противоречащая в том числе информационному письму ФСТЭК России от 10 января 2025 г. № 240/24/39. Например, веб-сервер Apache реализует более 10 механизмов аутентификации, доступных в виде модулей, в зависимости от опций его сборки и конфигурации в СЗИ. Отсутствие в документации на СЗИ описания назначения (функциональных возможностей) СЗИ и реализуемых ими ФБ приводит к отказу в выдаче ФСТЭК России решения о проведении сертификационных испытаний. Рекомендации: При инвентаризации функциональных возможностей (далее - ФВ) СЗИ и классификации их в качестве ФБ рекомендуется следовать следующему алгоритму: 1. Получить полный список декларируемых разработчиком ФВ СЗИ. 2. Дополнить список незадекларированными разработчиком СЗИ ФВ, выявленными в ходе ознакомления с СЗИ и последующих испытаний. Все выявленные ФВ, являющиеся ФБ и не заявленные разработчиками в качестве ФБ, являются недекларированными возможностями (далее - НДВ). Выявление НДВ является основанием для прекращения процедуры сертификационных испытаний и выдаче отрицательного технического заключения. 3. Сравнить список ФВ со списками: 3.1. ФБ, вводимых Требованиями ФСТЭК России к различным типам СЗИ 3.2. ФБ, вводимых Профилями ФСТЭК России к различным типам СЗИ 3.3. классов ФБ, определяемых в ГОСТ Р 15408-2-2013 Совпадающие ФВ следует определить в качестве ФБ СЗИ. 4. Проанализировать список угроз безопасности информации, опубликованных в БДУ ФСТЭК России. ФВ СЗИ, реализующие защиту информационной системы или самого СЗИ от данных угроз, следует трактовать в качестве ФБ СЗИ. Дополнительные информационные материалы: - приказ ФСТЭК России от 11 февраля 2013 г. № 17 - информационное письмо от 10 января 2025 г. № 240/24/39 - БДУ ФСТЭК России. Раздел Угрозы безопасности информации - ГОСТ Р 15408-2-2013

В весенний семестр 2026 на ВМК МГУ впервые проводится спецкурс РБПО. Лабораторки рассчитаны только на студентов, но зато лекции транслируются для всех желающих. В объявлении есть ссылка на ВКС и понедельный план.

Коллеги, добрый день! С огромной радостью пересылаю вам информацию от Вартана по спецкурсу РБПО, который сейчас читается в МГУ. Лекции будут транслироваться в Jitsi, прослушивание доступно всем желающим просто по приведенной ссылке. @bootsmanGangreen подскажи пожалуйста, велась ли запись первых двух лекций, в частности по безопасной компиляции?

https://t.me/sdl_community/9752

Коллеги, доброго дня. 1 октября - дата большого анонса: приглашаем вас принять участие в Открытой конференции ИСП РАН - крупнейшей межотраслевой объединяющей конференции, и главном ежегодном событии для РБПО-сообщества, которая пройдет 09-10 декабря 2025 в инновационном кластере «Ломоносов»! Программа формируется, уже сейчас понятно, что конференция это: - ещё больше гостей, с учетом успехов в областях медицины, ИИ, РБПО и остальных сферах работы Института - встреча руководства ФСТЭК России с участниками консорциума - подведение итогов испытаний статических анализаторов - бизнес-трек - крупнейшие примеры внедрения технологий ИСП РАН - круглые столы, в том числе традиционный круглый стол "Сертификация РБПО. Год 2025" - и многое-многое другое, в первую очередь серия лютейших докладов о технологиях и инструментах! Важный момент - пилотный опыт организации выставки технологий на полях конференции в 2024 г. оказался успешным, выставка собрала множество посетителей и положительные отзывы от маркетинга экспонентов. С учетом полученного опыта мы доработали "пилот" до полноценной программы партнерских интеграций и начинаем связываться с вами на предмет участия в выставке. Если вы не получили письмо с приглашением и описаниями пакетов до 06.10.2025, пожалуйста напишите мне в личку, или сразу на почту klimchuk@avangardpro.ru! Вишенка на торте - традиционная самоорганизующаяся встреча РБПО-сообщества вечером первого дня. Традиционно же обсуждение и планирование будут осуществляться в чате гостей конференции @ispras_friends - займемся этим на следующей неделе! Регистрируйтесь, участвуйте, предлагайте свои идеи и обязательно приглашайте друзей и коллег - будет интересно!

Завершена трансформация Консорциума участников по поддержке Технологического центра исследования безопасности ядра Linux, нацеленная на то, чтобы Консорциум координировал работу Центра не тольков части исследований ядра Linux, но и в части других компонентов с открытым исходным кодом. Начинается формирование технических комитетов Консорциума в первую очередь по направлениям, исследования по которым уже активно идут: - Qemu/libvirt/Podman/Kubernetes - nginx - OpenSSL - Python3 - NodeJS - .NET - OpenJDK - PostgreSQL Приглашаем присоединяться к совместным исследованиям безопасности компонентов с открытым исходным кодом!

Коллеги, добрый день! Несколько слов о сегодняшнем бесспорно ключевом событии для РБПО-сообщества. 1.В 11:00 состоится торжественное подписание соглашения о практическом сотрудничестве ПАО "Ростелеком" и ИСП РАН по созданию конвейера и сервисов РБПО, в т. ч. на основе наработок проекта Унифицированная среда разработки безопасного отечественного ПО. 2. В 14:00 - 15:45 состоится анонсированный выше круглый стол (трансляция), посвященный и актуальным вопросам РБПО в целом, и рассказу про предпосылки и цели подписанного соглашения. С уважаемыми спикерами, несмотря на стратегические и горящие вопросы, мы решили провести его максимально живо, в стиле "антипленарка"! Приходите очно - будет интересно, и будет возможность задать вопросы. 3. Ну и для тех, кто очно не в Казани - одно фото "раздаточных материалов" про Альянс и протоконвейер! Все официальные публикации и маркетология посыпятся с 11:00, пока же просто картинка для привлечения внимания 😈 Ждем вас на наших стендах и в трансляции!

Методическая рекомендация № 2025-09-012 | Рекомендация Примеры некорректных ссылок: 1. http://github.com/FasterXML/java-classmate — выводит в stderr «warning: redirecting to https://github.com/FasterXML/java-classmate/» Решение: необходимо использовать протокол https. 2. https://gitlab.ow2.org/asm/asm — выводит в stderr «warning: redirecting to https://gitlab.ow2.org/asm/asm.git/» Решение: ссылка на git-репозиторий должна заканчиваться на .git. 3. https://github.com/antlr/website-antlr2/blob/master/download/antlr-2.7.7.tar.gz — не является валидной ссылкой на архив, если указан тип source-distribution. Ссылка ведет на веб-интерфейс для просмотра содержимого репозитория, а не скачивает архив. 4. git+https://github.com/sindresorhus/resolve-from.git – команда git ls-remote не умеет работать с протоколом git+https, поэтому при анализе с опцией --check-vcs этот источник будет обработан как невалидный. 5. https://github.com/vuejs/language-tools.git#packages/component-type-helpers — не является валидной ссылкой на репозиторий, поскольку команда git ls-remote завершается с ошибкой «fatal: unable to update url base from redirection» 6. git://github.com/feross/queue-microtask.git — не является валидной ссылкой на репозиторий, поскольку команда git ls-remote завершается с ошибкой «fatal: unable to connect to github.com» из-за отсутствия прав на этот репозиторий. Решение: следует использовать протокол https.

Методическая рекомендация № 2025-09-012 | Рекомендация Алгоритм представления перечня заимствованных программных компонентов с открытым исходным кодом (далее - SBOM). Описание: В соответствии с требованиями информационного письма № 240/24/4436 от 26.09.2024 изготовители средств защиты информации (далее - СЗИ), испытательные лаборатории и органы по сертификации при проведении сертификации СЗИ, включающих в свой состав заимствованные программные компоненты с открытым исходным кодом (далее - заимствованные компоненты), должны проводить сертификационные испытания СЗИ и осуществлять их поддержку безопасности в соответствии с Порядком испытаний и поддержки безопасности СЗИ, в состав которых входят заимствованные компоненты. На практике значительная часть представленных SBOM возвращается на доработку по причине ошибок, несоответствий или недостатка информации. Целью данной методической рекомендации является представление алгоритма подготовки SBOM, направленного на минимизацию ошибок. 1. Для проверки SBOM рекомендуется использовать скрипт sbom-checker.py с включенными опциями: -e ERRORS, --errors ERRORS — максимальное число ошибок для вывода; по умолчанию - 10; для вывода всех ошибок - 0. --check-vcs — проверка url типа vcs на git/svn/hg/fossil-репозиторий (требуется доступ к Интернет и наличие пакетов git, subversion и mercurial). --check-source-distribution — проверка url типа source-distribution. - Ошибки типа ERROR обязательны к исправлению; - Большинство ошибок типа WARNING являются обязательными к исправлению, но при проверке ссылок могут быть ложные срабатывания. (см. п. 4.1). 2. В соответствии с требованиями к полям объекта, описывающего информацию о продукте (Табл. 3 информационного письма) необходимо: - проверить, что содержимое поля "name" совпадает с названием продукта, указанным в формуляре; - проверить, что содержимое поля "version" совпадает с версией продукта, указанной в формуляре. 3. В соответствии с требованиями к полям объекта, описывающего информацию об изготовителе продукта (Табл. 4 информационного письма) необходимо: - проверить, что содержимое поля "manufacturer": { "name": совпадает с названием организации — изготовителя продукта, указанным в формуляре. 4. В соответствии с требованиями к полям объекта, описывающего источники получения и внешние ссылки заимствованного компонента (Табл. 6 информационного письма) необходимо: 4.1. Проверить содержимое поля url для объектов массива externalReferences, имеющих значение vcs в поле type: - ссылка ведет на репозиторий; Команды для проверки корректности ссылки на репозиторий: git ls-remote <URL> //не должна выводить ошибок или предупреждений в stderr svn ls <URL> hg identify <URL> curl --silent {url} 2>&1 | grep -iPzo "<footer>\sthis\spage\swas\sgenerated\sin\sabout\s(\d+\.\d+)s\sby\sfossil" — если вывод начинается с <footer>, то ссылка корректна. При необходимости указать подпапку в репозитории или версию компонента рекомендуется использовать следующий шаблон: "https://{GITSERVER}/{GROUP}/{PROJECT}/tree/{BRANCH|TAG|HASH}/{FOLDER}" 4.2. Проверить содержимое поля url для объектов массива externalReferences, имеющих значение source-distribution в поле type: - по указанной ссылке расположен архив (условно можно скачать с помощью curl); - архив содержит исходный код компонента (пример: для Java часто в url указывают ссылку на архив из Maven-репозитория. Такие архивы обычно имеют расширение .jar. При этом необходимо убедиться, что в архиве действительно присутствуют исходные тексты (.java), а не только скомпилированные .class-файлы. В случаях, когда программный компонент заимствуется из состава сертифицированного дистрибутива операционной системы, составляющей среду функционирования ОО, то допускается у такого компонента опускать поле externalReferences, указав в поле properties свойство с именем GOST:provided_by и значением, содержащим название СЗИ, из состава которого заимствован данный компонент (или список названий, разделяемых точкой с запятой). Например: "name": "GOST:provided_by", "value": "SomeLinux Certified Edition"

Коллеги, добрый день! С 17 по 19 сентября в Казани уже 6 раз пройдет международный форум Kazan Digital Week. В программе форума целый комплекс экспонентов и событий связаны с тематикой РБПО, и ключевым событием станет большой круглый стол «Безопасная и качественная разработка ПО: культура, конвейер, технологическая независимость» (18 сентября, прайм-тайм 14:00-15:45). Тема - максимально "горячая", а с учетом масштаба спикеров и запланированного объема освещения в прессе круглый стол обещает оказаться интереснейшим и полезным для всех нас событием. Участвуют: Арутюн Аветисян — директор, Институт системного программирования РАН Ирина Гефнер — заместитель начальника 2 управления ФСТЭК России Давид Мартиросов — старший вице-президент по коммерческим ИТ-продуктам, «Ростелеком»; генеральный директор, «Базис» Арсен Благов — генеральный директор, ИТ-экосистема «Лукоморье» (ООО «РТК ИТ плюс»), организатор трека и круглого стола Алексей Смирнов — генеральный директор и основатель, CodeScoring Артем Кострюков — генеральный директор, Test IT (Девелоника, кластер ГК Softline). Приглашаем участников РБПО-сообщества ФСТЭК России и ИСП РАН и ваших коллег, заинтересованных в вопросах выстраивания и конвейеризации процессов РБПО (в том числе в системах с ИИ), принять участие в круглом столе. Будет интересно! P. S. Ну и куда же без сюрприза? 🤗 Круглый стол - "вишенка на торте" в комплексе мероприятий и демонстраций к которым в режиме максимального приоритета мы готовимся прямо сейчас! Анонсы и фактура будут в первый день форума - приходите увидеть лично. Ключевой день для первых лиц 18е сентября!

Уважаемые коллеги, добрый день! Предлагаем Вашему вниманию электронную версию тематической рубрики "Три кита РБПО". В этом номере материалы посвящены Динамическому анализу. Также в рубрике представлена заметка о ходе испытаний статических анализаторов исходного кода, проходящих под методическим и организационным руководством ФСТЭК России. Редакция благодарит авторов статей и компании, принявших участие в этом выпуске. Ссылка на материалы по РБПО: https://ib-bank.ru/rbpos Желаем Вам полезного и интересного чтения!

Методическая рекомендация № 2025-07-011 | Уровень критичности: 3 Область: Инструментальный анализ Тип недостатка: Необоснованный выбор инструментов, в том числе инструментов статического анализа исходного кода, для выстраивания и выполнения процессов РБПО. Описание: В настоящий момент ФСТЭК России не предъявляет требования наличия сертификата соответствия к большинству типов инструментов анализа кода и архитектуры. При этом к инструментам предъявляются следующие требования: - инструменты должны быть открытыми, либо отечественной разработки, обеспечивающие реализацию требований ФСТЭК России и национальных стандартов - инструменты должны удовлетворять частным техническим требованиям, если они заданы ФСТЭК России (например, требованиям Методики ВУ и НДВ ФСТЭК России к статическим анализаторам исходного кода, написанного на ЯП высокого уровня) - инструменты должны позволять разработчикам выполнять рекомендации Центра исследований безопасности системного программного обеспечения Также при сертификации процессов безопасной разработки контролируется использование организацией инструмента (-ов) статического анализа, соответствующего требованиям ГОСТ Р 71207-2024. В указанном ГОСТ приведены как требованиям к методам статического анализа, так и алгоритм выбора и конфигурирования инструмента, алгоритм проверки соответствия инструмента требованиям ГОСТ, а также базовые численные критерии. В настоящий момент под патронажем ФСТЭК России проводятся публичные испытания статических анализаторов (для 6 ЯП). В рамках данных испытаний создаются как публичная база тестов, так и методология оценки соответствия инструментов требованиям ГОСТ. Данная методология будет являться опорной (либо - прототипом, для инструментов статического анализа иных ЯП) для проверки соответствия тех или иных инструментов статического анализа требованиям ГОСТ. Статические анализаторы, не выполняющие требования ГОСТ, не будут рассматриваться в качестве инструментов, использование которых позволяет выполнить требования, устанавливаемые ФСТЭК России к процессам РБПО. Рекомендации: - ознакомиться с требованиям ГОСТ к инструментам и методологией оценки соответствия инструментов этим требованиям - ознакомиться с целями, задачами, материалами испытаний статических анализаторов Дополнительные информационные материалы: - ответ представителя ФСТЭК России на вопрос о наличии требования сертифицированности инструментов - ГОСТ Р 71207-2024 "Статический анализ программного обеспечения" - пресс-релиз о ходе испытаний статических анализаторов под патронажем ФСТЭК России

Всем доброго дня! Уважаемые коллеги, подготовлено и опубликовано информационное сообщение по итогам этапа "Домашнее задание" испытаний статических анализаторов под патронажем ФСТЭК России. Ссылка на документ: https://ib-bank.ru/bisjournal/post/2508

Методическая рекомендация № 2025-07-010 (графические материалы)