Programmation : les langages sécurisés, prochain grand saut ?
Avec l’open source en ligne de mire, les appels à l’adoption des langages de programmation « sécurisés » (à gestion automatique de mémoire) se multiplient.
Ruby, Swift, C#… Prière d’envisager sérieusement l’adoption de ces langages de programmation sécurisés. La NSA vient d’émettre une note d’information qui va dans ce sens.
Cette publication s’inscrit, notamment, dans la lignée d’un atelier organisé il y a quelques semaines sous la bannière de l’Open Source Software Security Initiative. Un projet qui associe, sous l’impulsion de la Maison Blanche, les principales agences américaines impliquées dans le domaine de la cyber (CISA, NIST, NTIA).
L’atelier s’est structuré autour de trois grands axes. En l’occurrence, les leviers économiques, la gestion des dépendances… et les langages de programmation sécurisés. Plus précisément, ceux qui gèrent automatiquement la mémoire.
En la matière, le consensus s’est porté sur Rust. Avec Java, Python et Go comme options lorsque les exigences de performances sont moins importantes.
Parmi les démarches souhaitables à court terme pour pousser ces langages, financer le développement de l’outillage attenant. On peut aussi envisager de compartimenter les bases de code afin de favoriser leur migration incrémentielle. À plus long terme, se posent en particulier des questions de formation. L’aspect économique n’est pas à négliger, tout du moins si on croit le constat selon lequel les équipes Java et Rust sont plus petites que les équipes C/C++.
La note de la NSA fait référence à un autre événement, organisé plus tôt cette année : l’Open Source Software Security Summit II. C’était en mai, sous la houlette de la Fondation Linux et de l’OpenSSF. Il en est ressorti un plan d’action en dix points. Parmi eux, la signature de code, l’amélioration de l’outillage SBOM… et, à nouveau, les langages sécurisés.
Google, Microsoft : des stats qui donnent le ton
Au gré de ces événements revient une statistique : 70 % des vulnérabilités logicielles sont dues à des problèmes de mémoire. Les données de Google concernant Chrome la corroborent.
Chez Microsoft aussi, on est autour des 70 %. En tout cas sur la foi de données que le groupe américain a communiquées début 2019 et couvrant une douzaine d’années.
La NSA fait remarquer que le développement des outils de fuzzing a simplifié la découverte de telles failles. Dans le même temps, l’agence reconnaît que les langages sécurisés ont leurs contraintes en matière de performance et de souplesse (nécessité fréquente d’un ramasse-miettes, poids de la vérification des accès potentiellement hors limites…). Elle affirme toutefois qu’il peut en coûter autant de sécuriser ceux qui ne le sont pas nativement. D’autant plus que ce palliatif a ses inconvénients, entre le taux de faux positifs de l’analyse statique et la couverture limitée de l’analyse dynamique.
Illustration principale © Timofey_123 – Shutterstock
