Производителей программного обеспечения призывают прекратить использование C/C++ к 2026 году

Федеральное правительство призывает производителей программного обеспечения отказаться от C/C++ и предпринять другие действия, которые могут «снизить риск для клиентов», согласно отчету Product Security Best Practices. В частности, CISA и ФБР установили крайний срок 1 января 2026 года для соблюдения правил безопасности памяти.

Отчет охватывает скорее руководящие принципы и рекомендации, чем обязательные правила, особенно для производителей программного обеспечения, которые работают над критически важной инфраструктурой или национальными критически важными функциями. Агентства особо выделили локальное программное обеспечение, облачные сервисы и программное обеспечение как услугу.

Хотя в отчете прямо не указано, что использование «небезопасных» языков может лишить производителей возможности работать в государственных учреждениях, а сам отчет не носит обязательный характер, его основная мысль ясна: подобная практика неприемлема для любой работы, которая классифицируется как имеющая отношение к национальной безопасности.

«Следуя рекомендациям, изложенным в настоящем руководстве, производители дадут понять клиентам, что они берут на себя ответственность за результаты обеспечения безопасности клиентов, что является ключевым принципом концепции «Проектируемая безопасность»», — говорится в отчете.

Языки программирования, небезопасные для памяти, содержат потенциальные уязвимости

В отчете небезопасные для памяти языки описываются как «опасные и значительно повышающие риск для национальной безопасности». Разработка на небезопасных для памяти языках — первая практика, упомянутая в отчете.

Безопасность памяти является темой обсуждения как минимум с 2019 года. Такие языки, как C и C++, «предоставляют большую свободу и гибкость в управлении памятью, при этом в значительной степени полагаясь на программиста для выполнения необходимых проверок ссылок памяти», — говорится в отчете АНБ за 2023 год о безопасности памяти. Однако, как говорится в отчете, эти языки не имеют встроенных средств защиты памяти, которые предотвращали бы проблемы управления памятью. Злоумышленники могут использовать проблемы с памятью, которые могут возникнуть в этих языках.

Что должны сделать производители программного обеспечения к январю 2026 года

К 1 января 2026 года производители должны иметь:

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

К безопасным для памяти языкам, одобренным АНБ, относятся:

Python. Java. C#. Go. Delphi/Object Pascal. Swift. Ruby. Rust. Ada.

СМ.: Преимущества, риски и передовой опыт использования менеджеров паролей (TechRepublic)

Другие «плохие практики» варьируются от плохих паролей до отсутствия раскрытия информации.

Другие практики, которые CISA и ФБР считают «исключительно рискованными», включают:

Разрешение ввода данных пользователем непосредственно в необработанное содержимое строки запроса базы данных SQL. Разрешение ввода данных пользователем непосредственно в необработанное содержимое строки команды операционной системы. Использование паролей по умолчанию. Вместо этого производители должны гарантировать, что их продукт предоставляет «случайные, уникальные для экземпляра начальные пароли», требует от пользователей создания новых паролей в начале процесса установки, требует физического доступа для начальной настройки и переводит существующие развертывания с паролей по умолчанию. Выпуск продукта, содержащего уязвимость из каталога известных эксплуатируемых уязвимостей (KEV) CISA. Использование программного обеспечения с открытым исходным кодом с известными эксплуатируемыми уязвимостями. Неиспользование многофакторной аутентификации. Отсутствие возможности сбора доказательств вторжения, если атака действительно произошла. Несвоевременная публикация CVE, включая список общих уязвимостей (CWE), который указывает тип уязвимости, лежащей в основе CVE. Непубликация политики раскрытия уязвимостей.

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