Журнал "Information Security/ Информационная безопасность" #4, 2026

Центр исследований безопасности системного ПО создан на базе ИСП РАН по инициативе ФСТЭК России для повышения безопасности отечественно- го ПО через совместные исследования заимствованных компонентов с откры- тым исходным кодом. Значительная часть этих исследований следует рекомендациям Методики, чтобы при испытаниях организации-участники располагали всеми необходимыми арте- фактами статического анализа (САО.1), функционального (ДАО.1) и фаззинг- тестирования (ДАО.2) заимствованных компонентов с открытым исходным кодом, исследуемых в Центре. Совмест- ная работа с другими организациями позволяет не только разделить затраты на исследования, но и обеспечить неза- висимую кросс-верификацию результа- тов. Это отражено в новой редакции Методики: она допускает зачет получен- ных в Центре результатов исследований безопасности заимствованных компонен- тов при сертификационных испытаниях без дополнительной проверки испыта- тельной лабораторией. Изменения в требованиях к испытаниям В новых требованиях к испытаниям подчеркну два момента. Первый – исклю- чительно терминологический. Предыду- щая редакция Методики требовала устра- нения всех предупреждений об ошибках, признанных истинными. Практика Центра показала: регулярно встречаются истин- ные предупреждения об ошибках, исправ- ление которых полезно для качества и сопровождаемости кода в долгосрочной перспективе, но которые непосредствен- но не влияют на безопасность. Пересо- бирать объект оценки лишь ради их устранения нецелесообразно. Регламен- ты Центра рекомендовали размечать такие предупреждения как истинные, но не влияющие на безопасность, и не тре- бовали их немедленного исправления. Это несколько противоречило предыду- щей редакции Методики, но полностью согласуется с новой. Второй момент заключается в повы- шении требований к тестированию моду- лей (ДАО.1), которое в случае заимство- ванных компонентов рассматривается как их функциональное тестирование на различных уровнях. Необходимость проведения данного вида испытаний для компонентов, реализующих функции безопасности и обеспечивающих (под- держивающих) их реализацию, а также обеспечения покрытия не менее 25% строк кода говорит о необходимости уделить большее внимание этому виду испытаний в рамках дальнейшего функ- ционирования Центра. Частные методики Важное новшество новой редакции – возможность уточнять требования к отдельным видам испытаний заимство- ванных компонентов с открытым исход- ным кодом, публикуя на сайте Центра соответствующие частные методики, формируемые в ходе совместных иссле- дований. Это позволяет до некоторой степени преодолеть одну из проблем разработки Методики: необходимость охватить все виды программного обес- печения (от прошивки смарт-карты до огромного программного комплекса в контейнерном исполнении) во многих случаях не позволяет сформулировать требования достаточно детально. На первом этапе подготовки частных методик предполагается оформить реко- мендации по анализу поверхности атаки объектов оценки, использующих кон- кретные стеки технологий или заимство- ванные программные компоненты с открытым исходным кодом. Например, при включении в состав продукта веб- сервера nginx – учитывать используемые плагины, часть которых может разви- ваться в независимых репозиториях; при анализе поверхности атаки систем виртуализации на основе QEMU – другие компоненты, применяемые для реали- зации виртуального оборудования и доступные коду, выполняющемуся внутри виртуальной машины, например usbredir или SPICE. Следующий шаг – подготовка реко- мендаций по динамическому анализу, например необходимость активации спе- циализированных датчиков срабатыва- ния ошибок (санитайзеров) при анализе компонентов, разработанных в опреде- ленном технологическом стеке, или уточ- нение требований к минимальному уров- ню покрытия исходного кода. Перечни программных компонентов Новые требования Методики к оформ- лению перечней программных компонен- тов и перечней образов контейнеров оперативно реализованы в инструменте проверки корректности их оформления sbom-checker 1 , поддерживаемом на ресурсах Центра, оперативно реализо- вана поддержка новых требований Мето- дики к оформлению перечней программ- ных компонентов и перечней образов контейнеров. В частности, добавлены проверки корректности оформления уни- версального идентификатора программ- ного компонента (УИПК, англ. Package URL/PURL), ставшего обязательным атри- бутом. Этот атрибут важен для идентифика- ции компонентов с открытым исходным кодом. В частности, при поиске извест- ных уязвимостей по открытым источни- кам в рамках КАО.1 требуется устано- вить, совпадает ли компонент из переч- ня с указанным в записи об известной уязвимости. Теоретически УИПК поз- воляет решить эту задачу, но на прак- тике единого подхода к его назначению конкретному компоненту с открытым исходным кодом нет. Вариативность заложена в самой спецификации: она поддерживает схемы именования на основе репозиториев (npm, PyPI, NuGet, Maven), дистрибутивов (deb, rpm), рас- положения репозитория с исходным кодом и др. Чтобы сохранить привычное разнообразие подходов к именованию и при этом решить задачу идентифика- ции, Центр начал эксперимент по фор- мированию каталога компонентов с открытым исходным кодом 2 . В нем предлагается собирать сведения о вари- антах именования одних и тех же ком- понентов, соответствующих репозито- риях с исходным кодом, связях между компонентами и т. д. Приглашаем присоединиться к этой и другим активностям Центра! l • 67 МЕТОДИКА ВУ И НДВ www.itsec.ru Роль Центра исследований безопасности системного ПО при реализации положений Методики Алексей Хорошилов, в.н.с., руководитель Центра исследований безопасности системного программного обеспечения ИСП РАН Фото: ИСП РАН 1 https://gitlab.community.ispras.ru/sdl-tools/sbom-checker 2 https://gitlab.community.ispras.ru/oss-register/oss-register