Tu cites 3 cas qui ont eu certe un gros impact parce que présent longtemps et utilisés un peu partout.
Mais si tu regardes bien dans ces cas si la détection n'a pas été réalisée lors d'une review de code, avoir accès aux code source a permis aux experts sécurités de comprendre et d ́identifier très rapidement la raison de la faille. Dans le cas de shellshock, le patch a été proposé par celui qui a découvert la faille.
De plus dans le cas de shellshock, ça a conduit à l'analyse par d'autre chercheurs pour trouver des failles similaires dans le code. Idem pour Heartbleed suite à son annonce de nombreuses vulnérabilitées ont été découvertes.
Donc code libre et ouvert n'est pas une garanti mais est aussi une aide à la découverte des failles même si le nerf de la guerre reste d'avoir:
- une politique de sécurité et de revue de code
- des ressources (quand heartbleed a été annoncé, openssl c'était géré par 2 devs, log4j 1 mainteneur).
- des audits réguliers. Et je dirais que ça c'est de la responsabilité de toute équipe de developpeurs utilisant une librairie. Si tu incorpores du code tiers, la bonne pratique veut que tu le fasses auditer avant, et à intervalles régulières une fois intégré.
[^] # Re: Nuance...
Posté par Psychofox (Mastodon) . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 5.
Tu cites 3 cas qui ont eu certe un gros impact parce que présent longtemps et utilisés un peu partout.
Mais si tu regardes bien dans ces cas si la détection n'a pas été réalisée lors d'une review de code, avoir accès aux code source a permis aux experts sécurités de comprendre et d ́identifier très rapidement la raison de la faille. Dans le cas de shellshock, le patch a été proposé par celui qui a découvert la faille.
De plus dans le cas de shellshock, ça a conduit à l'analyse par d'autre chercheurs pour trouver des failles similaires dans le code. Idem pour Heartbleed suite à son annonce de nombreuses vulnérabilitées ont été découvertes.
Donc code libre et ouvert n'est pas une garanti mais est aussi une aide à la découverte des failles même si le nerf de la guerre reste d'avoir:
- une politique de sécurité et de revue de code
- des ressources (quand heartbleed a été annoncé, openssl c'était géré par 2 devs, log4j 1 mainteneur).
- des audits réguliers. Et je dirais que ça c'est de la responsabilité de toute équipe de developpeurs utilisant une librairie. Si tu incorpores du code tiers, la bonne pratique veut que tu le fasses auditer avant, et à intervalles régulières une fois intégré.