Это самая жёсткая позиция правительства в отношении безопасности программного обеспечения, которая предупреждает производителей: устраняйте опасные методы программирования, иначе вас могут обвинить в халатности.
Федеральное правительство предупреждает об опасных методах разработки программного обеспечения. Агентство по кибербезопасности и защите инфраструктуры США (CISA) и Федеральное бюро расследований (ФБР) публикуют жёсткие предупреждения о нарушениях базовых мер безопасности, которые продолжают затрагивать критически важную инфраструктуру.
В недавнем отчёте, опубликованном совместно CISA и ФБР, о недостаточных мерах обеспечения безопасности продуктов производители программного обеспечения предупреждаются о нежелательности использования небезопасных для памяти языков программирования, таких как C и C++.
«Разработка новых линеек продуктов для использования в критически важной инфраструктуре или [национальных критически важных функциях] NCF на языке, небезопасном для памяти (например, C или C++), когда есть доступные альтернативные языки, безопасные для памяти, которые можно использовать, несет в себе угрозу и значительно повышает риск для национальной безопасности, национальной экономической безопасности, здоровья и безопасности населения», — говорится в отчёте.
Там не только про Memory Unsafe Languages.
Также упоминается про SQL инъекции и опасную работу с параметрами командной строки.
Про сторонние зависимости пишут в частности:
Cache copies of all open-source dependencies within the manufacturer’s own build systems and do not update products or customer systems directly from unverified public sources.
Posted via RSDN NNTP Server 2.1 beta
Re: Правительство США: критически важное программное обеспечение должно отказать
Здравствуйте, sergey2b, Вы писали:
S>«Разработка новых линеек продуктов для использования в критически важной инфраструктуре или [национальных критически важных функциях] NCF на языке, небезопасном для памяти (например, C или C++) ... несет в себе угрозу и значительно повышает риск для национальной безопасности
видимо кто-то устал доказывать что Rust безопаснее и решил просто посадить оппонента
S>Это самая жёсткая позиция правительства в отношении безопасности программного обеспечения, которая предупреждает производителей: устраняйте опасные методы программирования, иначе вас могут обвинить в халатности.
Изучайте C# и не программируйте вредительски-запутанно.
Здравствуйте, Osaka, Вы писали:
O> S>Это самая жёсткая позиция правительства в отношении безопасности программного обеспечения, которая предупреждает производителей: устраняйте опасные методы программирования, иначе вас могут обвинить в халатности.
O> Изучайте C# и не программируйте вредительски-запутанно.
Здравствуйте, sergey2b, Вы писали:
s> Это самая жёсткая позиция правительства в отношении безопасности программного обеспечения, которая предупреждает производителей: устраняйте опасные методы программирования, иначе вас могут обвинить в халатности.
Здравствуйте, Osaka, Вы писали:
O> R>Да там есть из чего выбирать: O> R> Delphi/Object Pascal
O> А в Delphi что, уже приделали сборку мусора и оно стало MEMORY_SAFETY?
NSA не считает наличие мусорщика обязательным атрибутом MEMORY_SAFETY.
Здравствуйте, Osaka, Вы писали:
O>А в Delphi что, уже приделали сборку мусора и оно стало MEMORY_SAFETY?
Memory safety — это не про сборку мусора, а про возможность безнаказанно обратиться по некорректному адресу (некорректный адрес — это не адрес, который указывает вообще "вникуда", а, например, когда можно вылезти за границу массива и попасть в неотносящуюся к нему переменную. Или возможность выделить память, освободить ее, а потом обратиться по старому адресу, где может к этому времени что-то совсем другое уже лежать).
Re: Правительство США: критически важное программное обеспечение должно отказать
Здравствуйте, Pzz, Вы писали:
Pzz> Memory safety — это не про сборку мусора, а про возможность безнаказанно обратиться по некорректному адресу (некорректный адрес — это не адрес, который указывает вообще "вникуда", а, например, когда можно вылезти за границу массива и попасть в неотносящуюся к нему переменную. Или возможность выделить память, освободить ее, а потом обратиться по старому адресу, где может к этому времени что-то совсем другое уже лежать).
Здравствуйте, Pzz, Вы писали:
Pzz>Memory safety — это не про сборку мусора, а про возможность безнаказанно обратиться по некорректному адресу (некорректный адрес — это не адрес, который указывает вообще "вникуда", а, например, когда можно вылезти за границу массива и попасть в неотносящуюся к нему переменную. Или возможность выделить память, освободить ее, а потом обратиться по старому адресу, где может к этому времени что-то совсем другое уже лежать).
Разве в Дельфи это нельзя сделать?
Re[6]: Суть: за C++ хотят привлекать по халатности
Здравствуйте, rudzuk, Вы писали:
Pzz>> Memory safety — это не про сборку мусора, а про возможность безнаказанно обратиться по некорректному адресу (некорректный адрес — это не адрес, который указывает вообще "вникуда", а, например, когда можно вылезти за границу массива и попасть в неотносящуюся к нему переменную. Или возможность выделить память, освободить ее, а потом обратиться по старому адресу, где может к этому времени что-то совсем другое уже лежать).
R>В Delphi это можно
Да это и в Go можно. И в Java можно, если постараться (ну в старых версиях точно). Думаю, и в остальных языках тоже. Я бы сказал, что Memory Safety это когда в типовом коде невозможны подобные ошибки, а не когда эти ошибки вообще невозомжны ни в какой программе на этом языке.
Но про Delphi в любом случае мимо, по крайней мере по моим воспоминаниям Delphi от C особо не отличается в этом плане. Разве что индексация массивов проверяется по дефолту.
Здравствуйте, vsb, Вы писали:
vsb> Я бы сказал, что Memory Safety это когда в типовом коде невозможны подобные ошибки, а не когда эти ошибки вообще невозомжны ни в какой программе на этом языке.
Как раз в типовом коде дельфей это сделать легко. Ссылки на объекты неотслеживаемые, поэтому заехать в удаленный объект — как два пальца. Была попытка прикрутить ARC для объектов и слабые ссылки, но не прижилось оно. Слабые ссылки оставили только для интерфейсных типов в итоге.
vsb> Но про Delphi в любом случае мимо, по крайней мере по моим воспоминаниям Delphi от C особо не отличается в этом плане. Разве что индексация массивов проверяется по дефолту.
Индексция проверяется, строки автоматически управляются, динамические массивы (благодаря которым про сырую память можно забыть вообще) — автоматически, интерфейсы — автоматически, варианты — автоматически, в новых версиях автоматические записи завезли. В общем, все достаточно неплохо.
Здравствуйте, sergey2b, Вы писали:
S>31 октября 2024 года S>Это самая жёсткая позиция правительства в отношении безопасности программного обеспечения, которая предупреждает производителей: устраняйте опасные методы программирования, иначе вас могут обвинить в халатности.
ой-ой-ой!
Пусть для начала почитают лицензионное соглашение и если их не устраивает — не используют.
А если хотят большего, то пусть платят.
