vak | Завязывайте с Си++, он того

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

(Меган Крауз, 4 ноября 2024г)

Агентство по кибербезопасности и защите инфраструктуры США (CISA) и Федеральное бюро расследований (FBI) утверждают, что C, C++ и другие языки программирования с небезопасной работой с памятью способствуют возникновению потенциальных уязвимостей.

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

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

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

"Следуя рекомендациям данного руководства, производители подают клиентам сигнал о том, что они берут на себя ответственность за результаты в области безопасности, что является ключевым принципом подхода Secure by Design", — говорится в отчёте.

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

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

Вопрос безопасности памяти обсуждается как минимум с 2019 года. Языки вроде C и C++ "предоставляют большую свободу и гибкость в управлении памятью, при этом в значительной степени полагаясь на программиста в выполнении необходимых проверок обращений к памяти", отмечалось в отчёте Агентства национальной безопасности США (NSA) за 2023 год, посвящённом безопасности памяти. Однако в нём также подчёркивалось, что этим языкам не хватает встроенных механизмов защиты памяти, которые могли бы предотвращать ошибки управления памятью. Злоумышленники могут эксплуатировать такие проблемы, возникающие в этих языках.

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

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

"Дорожную карту по безопасности памяти" для существующих продуктов, написанных на языках с небезопасной работой с памятью. Она "должна описывать приоритетный подход производителя к устранению уязвимостей безопасности памяти в ключевых компонентах кода".
Демонстрацию того, как эта дорожная карта позволит сократить количество уязвимостей, связанных с безопасностью памяти.
Подтверждение “разумных усилий” по следованию данной дорожной карте.
Либо, в качестве альтернативы, использование языка с безопасной моделью работы с памятью.

К языкам с безопасной работой с памятью, одобренным NSA, относятся:

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

Другие плохие практики: от слабых паролей до отсутствия раскрытия уязвимостей

К другим практикам, которые CISA и ФБР обозначили как "исключительно рискованные", относятся:

Прямое использование пользовательского ввода в необработанном содержимом строки SQL-запроса.
Прямое использование пользовательского ввода в необработанном содержимом строки команды операционной системы.
Использование паролей по умолчанию. Вместо этого производители должны обеспечивать:
- случайные, уникальные для каждого экземпляра начальные пароли;
- обязательное создание новых паролей пользователем в начале процесса установки;
- необходимость физического доступа для первичной настройки;
- отказ от паролей по умолчанию в уже развернутых системах.
Выпуск продукта, содержащего уязвимость из каталога CISA Known Exploited Vulnerabilities (KEV).
Использование программного обеспечения с открытым исходным кодом, в котором известны эксплуатируемые уязвимости.
Отсутствие многофакторной аутентификации.
Отсутствие возможности собирать доказательства вторжения в случае атаки.
Несвоевременная публикация CVE, включая указание Common Weakness Enumeration (CWE) — типа уязвимости, лежащей в основе CVE.
Отсутствие политики раскрытия уязвимостей.

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

Flat | Top-Level Comments Only

From:

archaicos

При нонешней администрации это наверное устарело, и в моде снова традиционные ценности, в т.ч. C/C++.

From:

vak

Администрации приходят и уходят, а комитет по стандартизации Си++ уже неспособен этого отмыть. Проще родить нового.

From:

archaicos

Так одно другому не мешает. Я сейчас смеюсь с роликов с CppCon, у которых в названии "back to the basics". Фундамент гнилой же, и постоянно приходится к нему возвращаться.

From:

itsi

Откопают Дельфи!

From:

vak

Глянем последний опрос среди разработчиков на Stack Overflow (2025). "Приняли участие около 49 000 разработчиков, которые рассказали о технологиях, которые они использовали за последний год."

Go: ~16%
Rust: ~15%
Swift: ~8-10%
Delphi/Object Pascal: <2%
Ada: <1%

From:

archaicos

Я, кстати, не припомню что бы там у них в Delphi помогало избежать проблем с памятью, как в C++.

From:

itsi

Ну, тут я уже не подскажу ибо на дельфях погроммировал лет 25 назад в последний раз, равно как и интересовался ими.

From:

madef

Тогда за использование Ассемблера надо заводить уголовное дело. Там вообще всё делается под личную ответственность разработчика.

From:

lxe

Несвоевременная публикация CVE

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

From:

toprunner

Нельзя давать такую опасну вещь как С в руки кому попало. Продавать только в оружейньіх магазинах по лицензии.

From:

dimorlus

А чем принципиально работа с памятью в Delphi (OP) отличается от C++? На сколько я помню Паскаль, там все примерно тоже самое было, Паскаль даже большие вольности позволял.

From:

straktor

В паскале динамическая аллокация чувствительна к типу и касты пойнтеров делать не надо. Но да, возможность есть.

From:

norian

эти сраные двуногие обезьяны вообще не разбираюцца в колбасных обрезках

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

то что в крестах с памятью надо аккуратно, это да, хде взял там и положь

From:

ufm

Я примерно лет 20 назад пришёл к выводу, что лушая защита от багов в софте - введение уголовной ответственности для программистов за их софт. Взломали что-то через твой софт? Значит сядешь. Вот прям по уровню CVE, какой уровень - на столько и сядешь.

From:

straktor

Ну и никто ничего писать не будет. Как минимум оперсорс.

Во-вторых, есть идея интеграции и ответственность кода непонятна.

Например две строчки кода, ввод числа, вторая извлечение квадратного корня. Ввожу -1, падает, кто виноват? Библиотека ввода или математики? Интегратор? Ну, он напишет юзеру, что сам он интегрировать не будет, а юзеру надо набрать самому первое, потом второе.

Идея дурацкая, на уровне запрещения ножей.