![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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 года производители должны иметь:- "Дорожную карту по безопасности памяти" для существующих продуктов, написанных на языках с небезопасной работой с памятью. Она "должна описывать приоритетный подход производителя к устранению уязвимостей безопасности памяти в ключевых компонентах кода".
- Демонстрацию того, как эта дорожная карта позволит сократить количество уязвимостей, связанных с безопасностью памяти.
- Подтверждение “разумных усилий” по следованию данной дорожной карте.
- Либо, в качестве альтернативы, использование языка с безопасной моделью работы с памятью.
- Python
- Java
- C#
- Go
- Delphi / Object Pascal
- Swift
- Ruby
- Rust
- Ada
Другие плохие практики: от слабых паролей до отсутствия раскрытия уязвимостей
К другим практикам, которые CISA и ФБР обозначили как "исключительно рискованные", относятся:- Прямое использование пользовательского ввода в необработанном содержимом строки SQL-запроса.
- Прямое использование пользовательского ввода в необработанном содержимом строки команды операционной системы.
- Использование паролей по умолчанию. Вместо этого производители должны обеспечивать:
- случайные, уникальные для каждого экземпляра начальные пароли;
- обязательное создание новых паролей пользователем в начале процесса установки;
- необходимость физического доступа для первичной настройки;
- отказ от паролей по умолчанию в уже развернутых системах.
- Выпуск продукта, содержащего уязвимость из каталога CISA Known Exploited Vulnerabilities (KEV).
- Использование программного обеспечения с открытым исходным кодом, в котором известны эксплуатируемые уязвимости.
- Отсутствие многофакторной аутентификации.
- Отсутствие возможности собирать доказательства вторжения в случае атаки.
- Несвоевременная публикация CVE, включая указание Common Weakness Enumeration (CWE) — типа уязвимости, лежащей в основе CVE.
- Отсутствие политики раскрытия уязвимостей.
no subject
Date: 2026-01-22 07:39 (UTC)no subject
Date: 2026-01-22 07:52 (UTC)no subject
Date: 2026-01-22 08:17 (UTC)Go: ~16%
Rust: ~15%
Swift: ~8-10%
Delphi/Object Pascal: <2%
Ada: <1%
no subject
Date: 2026-01-22 08:33 (UTC)no subject
Date: 2026-01-22 08:35 (UTC)no subject
Date: 2026-01-22 08:47 (UTC)Предыдущая администрация вообще известна чувствительностью к несвоевременным публикациям.
no subject
Date: 2026-01-22 09:47 (UTC)Нельзя давать такую опасну вещь как С в руки кому попало. Продавать только в оружейньіх магазинах по лицензии.
no subject
Date: 2026-01-22 09:50 (UTC)no subject
Date: 2026-01-22 10:50 (UTC)в их списке половина интерпретаторов, которые вообще про другое плюс те же бейцы только в профиль - системные вызовы для работы с памятью и освобождение лапгами (в паскале совсем в профиль, в аде надо унаследовацца от деаллокатора, в особо извращенной скрытой форме)
то что в крестах с памятью надо аккуратно, это да, хде взял там и положь
no subject
Date: 2026-01-22 13:47 (UTC)no subject
Date: 2026-01-22 14:31 (UTC)no subject
Date: 2026-01-22 16:33 (UTC)no subject
Date: 2026-01-22 16:39 (UTC)Во-вторых, есть идея интеграции и ответственность кода непонятна.
Например две строчки кода, ввод числа, вторая извлечение квадратного корня. Ввожу -1, падает, кто виноват? Библиотека ввода или математики? Интегратор? Ну, он напишет юзеру, что сам он интегрировать не будет, а юзеру надо набрать самому первое, потом второе.
Идея дурацкая, на уровне запрещения ножей.
А, так уже! Ну хорошо; слава те господи, может быть, и пом
Date: 2026-01-22 17:15 (UTC)То есть попросят(заставят) переписать его.
На Го, например.
no subject
Date: 2026-01-22 19:00 (UTC)Вспомнился анекдот "жаль, а то у меня ещё много идей".
Да-да, сейчас все бросят и прекратят.
Date: 2026-01-22 19:13 (UTC)Re: Да-да, сейчас все бросят и прекратят.
Date: 2026-01-22 19:15 (UTC)no subject
Date: 2026-01-22 20:08 (UTC)If you program in Rust: Happy holidays!
Re: А, так уже! Ну хорошо; слава те господи, может быть, и п
Date: 2026-01-22 21:10 (UTC)no subject
Date: 2026-01-22 21:48 (UTC)Среднее качество кода на нём возрастёт
no subject
Date: 2026-01-22 23:48 (UTC)no subject
Date: 2026-01-22 23:51 (UTC)no subject
Date: 2026-01-23 00:13 (UTC)Нуачё? Мы так и делаем.
no subject
Date: 2026-01-23 03:28 (UTC)no subject
Date: 2026-01-23 04:47 (UTC)У нас, например, динамической памяти не бывает.
Ada/Spark даёт нам formal verification - требование заказчиков.
no subject
Date: 2026-01-23 06:15 (UTC)no subject
Date: 2026-01-23 07:15 (UTC)no subject
Date: 2026-01-23 08:10 (UTC)Был у меня опыт, когда в одном проекте некую flash file system надо было читать-писать. Решено было для этого взять готовую библиотеку, требовавшую malloc()/free(). Ну, пришлось писать махонький malloc() из pre-allocated heap. Привело это к тому, что уже когда начались поставки, пришлось раз или два увеличивать размер этого heap-а. Прикинь, в каком-нибудь условном гугле FW field upgrade десятков тысяч нодов.
Так что нафик-нафик.
И я не понимаю, зачем нам этот Раст, когда у нас на Аде всё очень гладко идёт. Что он нам даст, чего у нас нет?
no subject
Date: 2026-01-23 13:38 (UTC)