Bjarne Stroustrup, twórca języka C++, opublikował odpowiedź na ustalenia raportu NSA, w którym zalecono organizacjom odejście od języków programowania, takich jak C i C++, które delegują zarządzanie pamięcią programistom, na rzecz języków takich jak C#, Go, Java, Ruby, Rust i Swift, które zapewniają automatyczne zarządzanie pamięcią lub wykonują kontrole bezpieczeństwa pamięci w czasie kompilacji.
Według Stroustrupa bezpieczne języki wymienione w raporcie NSA nie są w rzeczywistości lepsze od C++ w aplikacjach, które są dla niego ważne. W szczególności wytyczne C++ Core Guidelines, które opracowano w ostatnich latach, obejmują bezpieczne praktyki programowania i zalecają korzystanie z narzędzi gwarantujących bezpieczne przetwarzanie typów i zasobów. Jednocześnie deweloperzy, którzy nie wymagają tak rygorystycznych gwarancji bezpieczeństwa, mają możliwość dalszego korzystania ze starych metod rozwoju.
Stroustrup uważa, że dobry analizator statyczny zgodny z C++ Core Guidelines może zapewnić niezbędne gwarancje bezpieczeństwa dla kodu C++ przy znacznie niższych kosztach niż przejście na nowe bezpieczne języki programowania. Na przykład większość zaleceń Core Guidelines jest już zaimplementowana w analizatorze statycznym i profilu bezpieczeństwa pamięci dołączonym do Microsoft Visual Studio. Niektóre zalecenia są również uwzględniane w analizatorze statycznym Clang tidy.
Raport NSA był również krytykowany za skupienie się wyłącznie na problemach z pamięcią, pomijając wiele innych problemów związanych z językiem programowania, które wpływają na bezpieczeństwo i niezawodność. Stroustrup postrzega bezpieczeństwo jako szerszą koncepcję, której różne aspekty można osiągnąć poprzez połączenie stylu kodowania, bibliotek i analizatorów statycznych. Aby kontrolować włączenie reguł zapewniających bezpieczeństwo pracy z typami i zasobami, proponuje się użycie adnotacji w kodzie i opcjach kompilatora.
W aplikacjach, gdzie wydajność jest ważniejsza niż bezpieczeństwo, podejście to pozwala na selektywne zastosowanie funkcji gwarantujących bezpieczeństwo tylko tam, gdzie jest ono potrzebne. Narzędzia zabezpieczające można również stosować fragmentarycznie, na przykład zaczynając od sprawdzania zakresu i reguł inicjalizacji, a następnie stopniowo dostosowując kod do bardziej rygorystycznych wymagań.
Źródło: opennet.ru
