Коллеги, доброго дня!

В пятницу состоится интереснейший эфир, посвященный теме РБПО. В качестве специального гостя - Ирина Сергеевна Гефнер, и она точно ответит на несколько волнующих всех вопросов (например - требуется ли сертификат ФСТЭК России на инструменты статического и динамического анализа 😎). Охват тем максимально широкий - сколько можно втолкнуть в мимолетные два часа! Вопросы - как драгоценные камни-самоцветы! Вместе с участниками дискуссии, в т. ч. великим&ужасным @Dmitry_Shmol, постараемся сделать уважаемой аудитории интересно&полезно - заглядывайте к нам на огонёк.

Также не пропустите второй эфир в этот день - важнейшая тема практической безопасности в наше время это защита цепочек поставок и композиционный анализ как часть этой процедуры. Список участников пока не опубликован, но по слухам ожидается Лёша-КАПО @alsmirn собственной персоной по ВКС 🤗

Коллеги, добрый день!

Пока готовимся к завтрашнему большому эфиру, спешим уже оповестить о следующем событии. 10 июля состоится Kaspersky Certification Day, да не простой, а золотой юбилейный - 10й!

На мой личный взгляд это одно из трёх главных отечественных мероприятий по безопасной и качественной разработке в году - наравне с зимними ТБФорум и ISPRASOPEN. Как всегда заявлены интереснейшие темы и традиционное большое выступление ФСТЭК России (Дмитрий Николаевич Шевцов), как всегда - теплейшие компания и кулуары, поскольку проход на конференцию "по спискам по рекомендации".

Что важно - уже второй год конференция будет транслироваться онлайн.

Что ещё важнее - несмотря на традиционный аншлаг и вход только по спискам и рекомендациям, глубокоуважаемая-неподражаемая Карина Олеговна ❤️‍🔥 - идеолог и организатор CertDay, участник РБПО-сообщества и просто чудесный человек - в этом году, в связи с юбилеем, приняла решение выделить небольшой батч мест для потенциальных новых участников - участников РБПО-сообщества ФСТЭК России и ИСП РАН!

Поэтому приглашаем всех пройти регистрацию на мероприятие по ссылке, и - если вы готовы 10 июля выделить день - поставить галочку "офлайн"-участие. Число очных "проходок" будет распределено организаторами по жребию или иным критериям.

Важно! Необходимо подать ваши заявки до 13:00 пятницы 27 июня, а лучше - прямо сейчас!

P.S. Вот как это было в таком далёком 2024м.

P.S.S. Пока трек докладов доформировывается на сайте, анонсирую доклад про ход испытаний инструментом статического анализа под патронажем ФСТЭК России 🔥

Методическая рекомендация № 2025-07-010 | Уровень критичности: 3

Область: Фаззинг-тестирование

Тип недостатка: Применение средств фаззинг-тестирования, не реализующих генетические алгоритмы фаззинг-тестирования (в том числе за счет инструментирования тестируемого кода).

Описание: На рис. 1-3 представлены протоколы сертификационных испытаний (4 уровень доверия) с применением инструментов (BurpSuite, OWASP ZAP, RestlerFuzz), не предназначенных для проведения фаззинг-тестирования с инструментированием кода и не реализующих генетические алгоритмы фаззинг-тестирования.

Что такое генетические алгоритмы в фаззинге?
Генетические алгоритмы в фаззинге применяются для автоматической генерации и оптимизации тестовых входных данных, на основе отобранных входных данных, которые максимизируют покрытие кода или вызывают аномальное поведение программы. Примеры популярных фаззеров, реализующих генетические алгоритмы фаззинг-тестирования: AFL++, libFuzzer, go-fuzz, SharpFuzz, JQF.

Что такое фаззинг с инструментированием кода?
Инструментирование кода – это процесс внедрения минимально возможных изменений в код программы для сбора информации о её выполнении. Может проводиться как до запуска программного обеспечения (статическое инструментирование, выполняется на этапе компиляции), так и во время выполнения исполняемого кода программного обеспечения (динамическое инструментирование, например с помощью Pin, Valgrind или DynamoRIO).

BurpSuite, OWASP ZAP и подобные инструменты анализа уязвимостей и тестирования безопасности веб-приложений не подходят для мутационного фаззинга с инструментированием кода и реализации генетических алгоритмов тестирования. Данные инструменты выполняют сканирование на основе сигнатур и заранее определенных шаблонов атак (SQL-инъекции, XSS, CSRF). В состав данных инструментов входят базовые фаззеры для автоматизации тестирования веб-приложений методом подстановки значений из заранее заданных словарей (payloads). Функция Grep-Extract не осуществляет мутации полученных данных, а позволяет автоматически извлекать данные из HTTP-ответов и использовать их в качестве payloads для последующих запросов по заданному правилу (regex, позиции текста, HTML-атрибуты). Для мутации (автоматизированной генерации) значений в BurpSuite / OWASP ZAP могут интегрироваться сторонние инструменты, такие как Radamsa. Однако инструменты не содержат функциональных возможностей по инструментированию кода тестируемых веб-приложений, и как следствие, не обеспечивают возможность проведения фаззинг-тестирования, реализующего генетические алгоритмы.

Рекомендации:

- в соответствии с требованиями Методики выявления уязвимостей и недекларированных возможностей, утвержденной ФСТЭК России 25 декабря 2020 года, начиная с 5 уровня доверия, необходимо проводить мутационное фаззинг-тестирование объекта оценки с инструментированием кода, обеспечивающим реализацию генетических алгоритмов фаззинг-тестирования.

- для фаззинг-тестирования веб-приложения с инструментированием кода и использованием генетических алгоритмов необходимо выделить участки кода, непосредственно доступные потенциальному нарушителю для взаимодействия с ними и передачи значений аргументов в них (например: обработка JSON-запросов; обработка входных данных через API или веб-интерфейсы; обработка данных, передаваемых через HTTP-запросы), создать минимальный тестируемый интерфейс (fuzz target) — функцию, которая: принимает входные данные от фаззера → передает их в тестируемый участок кода (функцию, библиотеку, модуль).

- применение генетических инструментирующих фаззеров и REST-фаззеров не противоречит друг-другу. Данные типы инструментов ориентированы на нахождение различных типов дефектов, рекомендуется применять их совместно. В дальнейшем развитии методической базы запланировано расширение разделов, описывающих подходы к динамическому тестированию API.

Дополнительные информационные материалы:

- чат сообщества ФСТЭК России и ИСП РАН. Динамика.
- методическая рекомендация № 2025-04-004
- методическая рекомендация № 2025-04-007
- документация на AFL++
- документация на libfuzzer

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

Методическая рекомендация № 2025-07-011 | Уровень критичности: 3

Область: Инструментальный анализ

Тип недостатка: Необоснованный выбор инструментов, в том числе инструментов статического анализа исходного кода, для выстраивания и выполнения процессов РБПО.

Описание: В настоящий момент ФСТЭК России не предъявляет требования наличия сертификата соответствия к большинству типов инструментов анализа кода и архитектуры. При этом к инструментам предъявляются следующие требования:

- инструменты должны быть открытыми, либо отечественной разработки, обеспечивающие реализацию требований ФСТЭК России и национальных стандартов

- инструменты должны удовлетворять частным техническим требованиям, если они заданы ФСТЭК России (например, требованиям Методики ВУ и НДВ ФСТЭК России к статическим анализаторам исходного кода, написанного на ЯП высокого уровня)

- инструменты должны позволять разработчикам выполнять рекомендации Центра исследований безопасности системного программного обеспечения

Также при сертификации процессов безопасной разработки контролируется использование организацией инструмента (-ов) статического анализа, соответствующего требованиям ГОСТ Р 71207-2024.

В указанном ГОСТ приведены как требованиям к методам статического анализа, так и алгоритм выбора и конфигурирования инструмента, алгоритм проверки соответствия инструмента требованиям ГОСТ, а также базовые численные критерии.

В настоящий момент под патронажем ФСТЭК России проводятся публичные испытания статических анализаторов (для 6 ЯП). В рамках данных испытаний создаются как публичная база тестов, так и методология оценки соответствия инструментов требованиям ГОСТ. Данная методология будет являться опорной (либо - прототипом, для инструментов статического анализа иных ЯП) для проверки соответствия тех или иных инструментов статического анализа требованиям ГОСТ.

Статические анализаторы, не выполняющие требования ГОСТ, не будут рассматриваться в качестве инструментов, использование которых позволяет выполнить требования, устанавливаемые ФСТЭК России к процессам РБПО.

Рекомендации:

- ознакомиться с требованиям ГОСТ к инструментам и методологией оценки соответствия инструментов этим требованиям

- ознакомиться с целями, задачами, материалами испытаний статических анализаторов

Дополнительные информационные материалы:

- ответ представителя ФСТЭК России на вопрос о наличии требования сертифицированности инструментов

- ГОСТ Р 71207-2024 "Статический анализ программного обеспечения"

- пресс-релиз о ходе испытаний статических анализаторов под патронажем ФСТЭК России

Уважаемые коллеги, добрый день!

Предлагаем Вашему вниманию электронную версию тематической рубрики "Три кита РБПО". В этом номере материалы посвящены Динамическому анализу. Также в рубрике представлена заметка о ходе испытаний статических анализаторов исходного кода, проходящих под методическим и организационным руководством ФСТЭК России.

Редакция благодарит авторов статей и компании, принявших участие в этом выпуске.

Ссылка на материалы по РБПО: https://ib-bank.ru/rbpos

Желаем Вам полезного и интересного чтения!

Коллеги, добрый день!

С 17 по 19 сентября в Казани уже 6 раз пройдет международный форум Kazan Digital Week. В программе форума целый комплекс экспонентов и событий связаны с тематикой РБПО, и ключевым событием станет большой круглый стол «Безопасная и качественная разработка ПО: культура, конвейер, технологическая независимость» (18 сентября, прайм-тайм 14:00-15:45).

Тема - максимально "горячая", а с учетом масштаба спикеров и запланированного объема освещения в прессе круглый стол обещает оказаться интереснейшим и полезным для всех нас событием. Участвуют:

Арутюн Аветисян — директор, Институт системного программирования РАН

Ирина Гефнер — заместитель начальника 2 управления ФСТЭК России

Давид Мартиросов — старший вице-президент по коммерческим ИТ-продуктам, «Ростелеком»; генеральный директор, «Базис»

Арсен Благов — генеральный директор, ИТ-экосистема «Лукоморье» (ООО «РТК ИТ плюс»), организатор трека и круглого стола

Алексей Смирнов — генеральный директор и основатель, CodeScoring

Артем Кострюков — генеральный директор, Test IT (Девелоника, кластер ГК Softline).

Приглашаем участников РБПО-сообщества ФСТЭК России и ИСП РАН и ваших коллег, заинтересованных в вопросах выстраивания и конвейеризации процессов РБПО (в том числе в системах с ИИ), принять участие в круглом столе. Будет интересно!

P. S. Ну и куда же без сюрприза? 🤗

Круглый стол - "вишенка на торте" в комплексе мероприятий и демонстраций к которым в режиме максимального приоритета мы готовимся прямо сейчас! Анонсы и фактура будут в первый день форума - приходите увидеть лично.

Ключевой день для первых лиц 18е сентября!

Методическая рекомендация № 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"

Методическая рекомендация № 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.

Коллеги, добрый день!

Несколько слов о сегодняшнем бесспорно ключевом событии для РБПО-сообщества.

1.В 11:00 состоится торжественное подписание соглашения о практическом сотрудничестве ПАО "Ростелеком" и ИСП РАН по созданию конвейера и сервисов РБПО, в т. ч. на основе наработок проекта Унифицированная среда разработки безопасного отечественного ПО.


2. В 14:00 - 15:45 состоится анонсированный выше круглый стол (трансляция), посвященный и актуальным вопросам РБПО в целом, и рассказу про предпосылки и цели подписанного соглашения. С уважаемыми спикерами, несмотря на стратегические и горящие вопросы, мы решили провести его максимально живо, в стиле "антипленарка"! Приходите очно - будет интересно, и будет возможность задать вопросы.


3. Ну и для тех, кто очно не в Казани - одно фото "раздаточных материалов" про Альянс и протоконвейер! Все официальные публикации и маркетология посыпятся с 11:00, пока же просто картинка для привлечения внимания 😈

Ждем вас на наших стендах и в трансляции!

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

Приглашаем присоединяться к совместным исследованиям безопасности компонентов с открытым исходным кодом!

Коллеги, доброго дня.

1 октября - дата большого анонса:

приглашаем вас принять участие в Открытой конференции ИСП РАН - крупнейшей межотраслевой объединяющей конференции, и главном ежегодном событии для РБПО-сообщества, которая пройдет 09-10 декабря 2025 в инновационном кластере «Ломоносов»!

Программа формируется, уже сейчас понятно, что конференция это:

- ещё больше гостей, с учетом успехов в областях медицины, ИИ, РБПО и остальных сферах работы Института

- встреча руководства ФСТЭК России с участниками консорциума

- подведение итогов испытаний статических анализаторов

- бизнес-трек - крупнейшие примеры внедрения технологий ИСП РАН

- круглые столы, в том числе традиционный круглый стол "Сертификация РБПО. Год 2025"

- и многое-многое другое, в первую очередь серия лютейших докладов о технологиях и инструментах!

Важный момент - пилотный опыт организации выставки технологий на полях конференции в 2024 г. оказался успешным, выставка собрала множество посетителей и положительные отзывы от маркетинга экспонентов. С учетом полученного опыта мы доработали "пилот" до полноценной программы партнерских интеграций и начинаем связываться с вами на предмет участия в выставке. Если вы не получили письмо с приглашением и описаниями пакетов до 06.10.2025, пожалуйста напишите мне в личку, или сразу на почту klimchuk@avangardpro.ru!

Вишенка на торте - традиционная самоорганизующаяся встреча РБПО-сообщества вечером первого дня. Традиционно же обсуждение и планирование будут осуществляться в чате гостей конференции @ispras_friends - займемся этим на следующей неделе!

Регистрируйтесь, участвуйте, предлагайте свои идеи и обязательно приглашайте друзей и коллег - будет интересно!