Репортаж от Wedoany，Агентство по кибербезопасности и защите инфраструктуры США (CISA) опубликовало руководство «Открытое программное обеспечение: принципы и практики безопасности», которое помогает федеральным ведомствам управлять безопасностью открытого ПО, участвовать в открытых проектах и оценивать открытые системы искусственного интеллекта.
В руководстве отмечается, что исходный код открытого ПО может подвергаться независимой проверке, что снижает зависимость от заявлений поставщиков и уменьшает риск привязки к одному вендору; освобождение от лицензионных платежей и распределение работ по разработке позволяют сократить расходы, а публикация публично финансируемого ПО в соответствующих случаях повышает прозрачность.
CISA рекомендует ведомствам относиться к открытому ПО как к обычным программным активам: оценивать его безопасность до внедрения и осуществлять мониторинг на протяжении всего жизненного цикла. Следует отдавать приоритет проектам с активным сопровождением, изучать условия лицензий и вести перечень используемых открытых компонентов.
В руководстве рекомендуется отслеживать зависимости программного обеспечения, контролировать вновь раскрытые уязвимости и регулярно оценивать, заслуживает ли проект доверия. Спецификация программного материала (SBOM) помогает выявлять затронутые компоненты при раскрытии уязвимостей. Ведомствам следует как можно скорее применять обновления безопасности; если для заказного ПО или открытого проекта ещё нет обновлений, необходимо быть готовыми внести собственные исправления. Если проект достиг конца поддержки или проблемы безопасности остаются нерешёнными, его следует заменить на поддерживаемую альтернативу. Инструменты, включая искусственный интеллект, увеличивают количество выявляемых уязвимостей и ускоряют разработку патчей; CISA призывает максимально автоматизировать управление зависимостями, развёртывание обновлений и тестирование безопасности.
CISA призывает ведомства вносить вклад в используемые открытые проекты, включая исправления безопасности, отчёты об ошибках, документацию и технические обсуждения, а также делиться изменениями с сообществом, чтобы сократить дублирование работы, улучшить ПО и публиковать результаты государственного финансирования. Перед внесением вклада следует убедиться, что лицензия проекта допускает участие, а также проверить исходный код, документацию и файлы конфигурации, чтобы предотвратить раскрытие паролей, ключей шифрования, деталей внутренних систем и других конфиденциальных данных.
Для ведомств, разрабатывающих собственное ПО, CISA рекомендует с самого начала рассматривать возможность публикации в виде открытого исходного кода, если этому не препятствуют правовые, охранные или эксплуатационные причины. В перечне внутренне разработанного ПО следует указывать, предназначен ли проект для публичного выпуска, для обмена внутри федерального правительства или остаётся закрытым. Перед публикацией необходимо проверить конфиденциальную информацию, соблюдать практики безопасной разработки, выбрать подходящую лицензию и разместить в публичном репозитории документацию, руководство для участников, политику раскрытия уязвимостей и SBOM. После публикации следует продолжать выпускать обновления, решать проблемы безопасности и чётко определять, когда поддержка ПО прекращается. Если ПО разработано подрядчиком по заказу, правительство должно сохранять права на повторное использование, модификацию и, при соответствующих условиях, открытие исходного кода.
CISA подчёркивает, что при оценке так называемых «открытых» систем искусственного интеллекта их следует отличать от открытого ПО: модели ИИ могут выпускаться под открытой лицензией, но при этом не обязаны раскрывать обучающие данные. Без доступа к обучающим данным и процессу обучения организациям сложно определить происхождение модели, а также оценить, не были ли скомпрометированы процесс разработки или компоненты. Перед развёртыванием следует убедиться в достаточной видимости подхода к разработке (включая обучающие данные и процесс обучения); если информация недоступна, систему следует рассматривать как проприетарное ПО с неполным происхождением и применять более строгие меры управления рисками.
