Федералы хотят, чтобы мы перешли с C/C++

Похоже, что крик о необходимости безопасных языков программирования становится все более настойчивым и официальным. Мы уже давно знаем, что C и C++ - опасные языки, так почему же сейчас это стало такой проблемой и актуально ли это вообще?

С тех пор как Rust стал лучшим способом низкоуровневого программирования, мы все больше понимаем недостатки C и C++. Лично я считаю, что у этих двух языков совершенно разные проблемы, но давайте на время забудем об этом, ведь главная проблема - безопасность памяти. Оба языка являются низкоуровневыми и не используют диспетчер памяти. Они также предлагают низкоуровневые указатели, которые, в зависимости от операционной системы, позволяют вам использовать память так, как вы хотите. Именно поэтому они мощны и именно поэтому опасны. Программисту слишком легко допустить ошибку, которая может привести к созданию конструкции, пригодной для эксплуатации. Конечно, если вы программируете идеально, эксплуатируемого кода быть не должно, но все мы люди.

В принципе, безопасные языки, такие как Rust, дают вам те же возможности, но заставляют вас прыгать через обручи, чтобы использовать их. Когда вы не можете проскочить через обручи и сделать то, что хотите, вам приходится писать код, помеченный как небезопасный, и тогда вы можете делать то, что хотите. Так ли нужно писать безопасный код? Текущее мнение таково: «да, это так» или, по крайней мере, «это лучше, чем C/C++».

Теперь Агентство по кибербезопасности и защите инфраструктуры США (CISA) и Федеральное бюро расследований (ФБР) выпустили руководящий документ на тему порочной практики:

«Разработка новых линий продуктов для использования в критической инфраструктуре или национальных критических функциях (NCF) на небезопасном для памяти языке (например, C или C++) при наличии легкодоступных альтернативных безопасных для памяти языков, которые можно использовать, опасна и значительно повышает риск для национальной безопасности, национальной экономической безопасности, здоровья и безопасности населения страны».

Что же нам делать с этим:

"Производители программного обеспечения должны создавать продукты таким образом, чтобы систематически предотвращать появление уязвимостей безопасности памяти, например, используя безопасный для памяти язык или аппаратные возможности, которые предотвращают уязвимости безопасности памяти. Кроме того, производители программного обеспечения должны опубликовать дорожную карту безопасности памяти к 1 января 2026 года».

В документе не упоминается язык Rust, но можно сказать, что он находится на заднем плане. А как насчет Python или Java? Безопасны ли они для памяти? Они оба имеют менеджеры памяти и не позволяют обычному программисту даже близко подойти к необработанной памяти, но они медленные. Так что мы действительно говорим о языках, безопасных для памяти, которые могут предложить такую же производительность, как C или C++.

Учитывая, что программирование в настоящее время находится в состоянии беспорядка из-за того, что вторые пилоты ИИ грозятся стать пилотами ИИ, весь этот вопрос может оказаться спорным. На данный момент мы не можем доверять ИИ в написании кода, безопасного для памяти, но с некоторым дополнительным обучением и оперативной инженерией я не вижу причин, по которым это не могло бы произойти. Рассматривать ИИ как своего рода безопасный компилятор из подсказок в C или C++ кажется разумной возможностью. В этот момент кого волнует, насколько безопасен целевой язык. В конце концов, Rust компилируется в ассемблер, который далеко не безопасен для памяти.

Вполне возможно, что сейчас мы поднимаем шум из-за пустяка.

В документе также говорится о других проблемах безопасности:

• SQL-инъекции
• инъекции в команды ОС
• использование паролей по умолчанию
• избегать использования компонентов с известными уязвимостями
• использование многофакторной аутентификации
• отсутствие протоколирования вторжений
• неспособность сделать проблемы известными через CVEs
• отсутствие политики публичного раскрытия информации