Linux Foundation вводит систему оценки качества, безопасности и стабильности СПО
Сформированный при организации Linux Foundation фонд Core Infrastructure Initiative, в рамках которого ведущие корпорации объединили свои усилия в направлении обеспечения поддержки открытых проектов, задействованных в ключевых областях компьютерной индустрии, анонсировал первые результаты продвижения инициативы Best Practices Badge Program для стимулирования повышения безопасности свободных проектов.
В рамках инициативы сформирован набор критериев, составленных с учётом опыта наиболее серьёзно относящихся к безопасности сообществ. Список включает 74 критерия, разделённых по степени важности (обязательные, желательные и рекомендуемые). Выполнение критериев позволяет судить о серьёзном отношении проектов к безопасности, обеспечению качества и поддержанию стабильности кодовой базы. Для оценки соответствия своего проекта предъявляемым критериям подготовлено простое web-приложение.
На базе данных критериев запущена программа сертификации соответствия проектов требованиям качества, безопасности и стабильности. Прошедшие сертификацию проекты получают право размещения на сайте специального знака качества, сигнализирующего о серьёзном отношении разработчиков к безопасности. В настоящее время заявки на проведение проверки сформированы для 114 проектов. Успешно прошли проверку 7 проектов: Curl, GitLab, ядро Linux, OpenBlox, OpenSSL, Node.js и Zephyr. Три проекта признаны не соответствующими критериям (pkgsrc — указание нескольких лицензий в разных файлах, container-tools — сайт без HTTPS, byobu — сайт без HTTPS c TLS). Остальные проекты находятся на стадии проверки.
Ключевые требования к проектам:
- Доступный по постоянному адресу web-сайт, на котором описано назначение проекта, предоставлены ссылки для загрузки, имеется возможность отправки отзыва разработчикам и доступна инструкция по подключению к разработке/отправке изменений;
- Использование типовой свободной лицензии и размещение информации о лицензии в файлах LICENSE или COPYING;
- Поддержка HTTPS на сайте;
- Наличие документации, описывающей установку и запуск, а также наличие спецификации для API;
- Доступность кода через распределённые системы контроля версий и возможность оценки изменений между релизами;
- Присвоение каждому выпуску уникального номера версии в формате семантического версионирования;
- Наличие списка изменений, в котором явно выделены исправленные уязвимости;
- Предоставление средства для отправки разработчикам сообщений об ошибках и отслеживания их исправления. Доступ к архиву сообщений о проблемах. Аргументированная реакция на любые сообщения об ошибках и запросов на улучшения, без игнорирования;
- Наличие безопасного и документированного процесса отправке уведомлений об обнаружении уязвимостей. Ответ на подобные сообщения должен составлять не более 14 дней, а проблема должна быть устранена не более чем за 60 дней;
- Возможность сборки с использованием штатных открытых инструментов. Возможность включения сборки в режиме вывода предупреждений компилятором и компоновщиком. Возможность запуска статических анализаторов кода;
- Наличие автоматизированного тестового набора, покрывающего большую часть функциональности проекта. Добавление новых тестов для нового кода;
- Автоматизированный запуск тестов для всех изменений и применение динамических проверок с использованием анализаторов, подобных Valgrind, систем fuzzing-тестирования и сканеров безопасности;
- Знание разработчиками методов безопасного программирования и типовых ошибок, приводящих к уязвимостям;
- В случае наличия поддержки шифрования применение публичных протоколов и алгоритмов, задействование уже готовых проверенных и открытых реализаций, использование ключей надлежащей длины, отказ от поддержки проблемных и уязвимых алгоритмов, использование алгоритмов с Forward secrecy, хранение любых паролей в форме хэшей с солью, применение надёжных генераторов случайных чисел.
© OpenNet