Si on parle de bogues en général, les prévenir est très difficile et coûteux, sans solution bien arrêtée. Au mieux on dispose de nombreuses bonnes pratiques et d'outils mais à moins d'y mettre vraiment le prix ça reste limité. Et même en y mettant le prix on ne fait pas de miracles.
Si on revanche on parle de failles de sécurité alors on peut déjà en supprimer 90% rien qu'en abandonnant des langages bas-niveau comme le C++ (la vérification des bornes des tableaux, c'est le bien). Et je soupçonne qu'on pourrait encore diviser par dix en collant sur chaque moniteur un post-it "entrées utilisateurs == danger".
Nous sommes bien d'accord.
Mais vous faites une erreur en surestimant le décideur, il y a plus de "gogo" dans les entreprises que vous ne semblez croire
Et tout spécialement avec l'informatique en générale, un domaine dont le décideur ne connait bien souvent qu'une chose: C'est un centre de coùts trop élevé à diminuer par n'importe quel moyen.
D'autre part, les "spammeurs escroc" ont fait leur temps, il y a maintenant du démarchage réel dans les entreprises pour proposer du service "low low low cost"
Oui je suis au courant, au départ quelqu'un peu se faire avoir, mais après soit il trouve une solution pour réussir à faire développer ses applis ou gérer son informatique, soit il saute, parce que lui même doit rendre des comptes à son Directeur/Patron/Gérant/PDG/Board of directors/ Client/Propriétaire/actionnaire/investigateurs/ etc.
Après vu le nombre colossal de dépôts de bilan tous les ans et bien oui tous le monde y arrive pas, il y à un processus de "sélection"...
Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...
Faux et faux.
La plupart des gros problèmes logiciels (ceux qui sont durs à détecter) sont liés à des effets de bord en tous genres :
- accès mémoire (ex : heartbleed, dépassements de capacité)
- problèmes de synchro entre processus concurrents (souvent très durs à reproduire et à résoudre)
- overflow
- etc.
Bref C++, Java ou autre, même combat : plus il y a d'effets de bord possibles, plus il y a risque de bugs (c'est juste que plus c'est bas niveau, plus il y a de risques d'effets de bords, mais Java n'en est pas exempt).
Pour pallier à ce problème, la réponse généralement acceptée en entreprise, c'est : "on n'a qu'à faire plus de tests" (je connais des gens qui ont quasiment fait carrière juste avec cette phrase).
Cependant, il y a de nombreux problèmes avec les tests :
- on n'est jamais sûr de leur couverture
(pour pouvoir tester quelque chose, il faut déjà pouvoir envisager le scénario, comme dans le cas de Heartbleed par exemple)
- c'est parfois difficile à reproduire
(ex: ordonancement d'instructions en cas d'exécution concurrente, comme dans le cas du multi-threading)
- plus le code est long/complexe, plus il y a de cas à tester.
Le nombre de cas à tester peut potentiellement augmenter de manière quadratique, voire exponentielle (un peu comme la notation grand O pour mesurer la complexité d'un algorithme, mais appliquée au nombre de cas de tests en fonction du nombre de branches d'instructions. J'appelle ça "la notation grand T")
Certains tentent de résoudre le problème de qualité avec des outils plus poussés (outils d'analyse statique de code, preuves formelles...) mais bon, tant qu'on restera avec des langages qui, par nature, introduisent autant d'effets de bord (en gros, la grande famille des langages impératifs) c'est plus ou moins peine perdue.
Malheureusement, on n'a pas encore inventé de langage déclaratif à la fois performant et suffisamment puissant pour faire de l'introspection sur la qualité du code (et même si c'était le cas, les gens s'en détourneraient parce que "oh, c'est trop compliqué, ça ressemble pas à un langage que je connais déjà" ) donc on continue sur notre lancée, avec des problèmes de plus en plus difficile à résoudre, et vu que "ça coûte cher" (tout est relatif, il y a pas mal de "décideurs"qui sont loins d'apporter la même valeur ajoutée) alors on outsource dans des pays à bas coûts où on produit de la m**** en très grande quantité.
Relire tout ce que je vient de dire.
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
Tu ne crois pas si bien dire. J'ai travaillé pour un gros groupe industriel. Dans sa mentalité (et dans beaucoup d'autres boites malheureusement), la direction considérait l'informatique comme un centre de cout. Et pourtant si leur informatique s'arrêtait, tout plantait.
Leur matos? Un serveur "survivant" de 1979 avec 2GO de HDD et un soft maison de 25 ans avec des langages maisons, codés par des responsables d'usines. C'est cousus de bugs, ça plantent toutes les 5 mn. Bref, le contre exemple de la fiabilité, mais la direction considère que ça tourne comme ça depuis longtemps donc faut pas y toucher.
Il serait temps que les directions dans cette mentalité se sortent un peu la tête et regarde la réalité. Dans le monde d'aujourd'hui, sans informatique, qui plus est fiable, aucune société ne peux plus avancer.
"La connaissance appartient à tout le monde" (Film Antitrust)
Tout le nécessaire pour Python:
*News/Accueil *Cours/tutoriels *FAQ *Forums *Outils dédiés *Mon espace personnel avec mes Articles, Cours et Tutoriels
Je suis vraiment surpris de lire dans ce sujet des personnes qui travaillent dans des sociétés où on leur demande de ne pas tout couvrir en TU.
Je m'efforce toujours de tout couvrir dans l'ensemble des cas, même si cela implique en conséquence de passer plus de temps à faire des tests unitaires qu'à coder le programme à proprement parler. J'arrive quand même à développer confortablement en dessous de la matrice de la société cliente et de ne pas avoir rencontré de plantage en production lors de mes livraisons. Intervenant en tant que TMA pour une banque, je commence à comprendre pourquoi je récupère de temps en temps des projets en prod qui ne semblent pas terminés.
Hello,
Ce débat est très lié au système de rémunération des chefs de projets, proposé il y a quelques mois. Je subodore que les primes versées à ces memes chefs de projets les pousse à accepter tout et n'importe quoi auprès des clients. Les équipes de dév accumulent des dettes techniques incluant les tests, la sécurisation, la refactorisation et l'optimisation qui ne sont pas facturées et donc jugées inutiles ou du moins optionnelles à traiter.
Comme dit plus haut, la qualité du soft diminue et entraine une augmentation des surfaces d'attaques.
Cela peut paraitre anodin et déconnecté du sujet mais selon moi, c'est bel et bien la part de rémunération variable des décideurs de projets informatiques qui les encourage à dire "Amen" aux clients à tout bout de champ, même quand les délais de livraison sont intenables.
Je porte l'épée brisée, et sépare les vrais rois des tyrans. Qui suis-je ?
Vous oubliez dans votre estimation le coût nécessaire en local pour au final avoir un système qui fonctionne vraiment
Histoire classique constatée sur le terrain:
1. Une société "bien de chez nous" avec un staff de 10 développeurs les licencient pour les remplacer par une équipe outsourcée au ... Vietnam
2. Après moins de 1 an, tous les développeurs vietnamiens avaient changé (ben oui, ils ne sont pas plus bêtes que d'autres, ils ont changé de job pour gagner plus!)
3. La société "bien de chez nous" se rend compte qu'elle doit gérer ses "vietnamiens" de manière plus serrées en créant de "petits projets" faciles à réaliser avant que le développeur ne prenne les ailes
4. Au final, la société "bien de chez nous" se retrouve avec un staff de 10 personnes en Europe pour coordonner le job des développeurs outsourcés
Bingo!!!!!!!!!
Surtout on oublie de dire que les logiciels sont beaucoup plus sur qu'il y a 10,20 ou 30 ans car ils ont été sans cesse renforcés, car on utilise des solutions éprouvé (Open-source ou en place depuis très longtemps) . Mais le problème c'est que l'on est dans une course : une course pour améliorer le SI pour le rendre toujours plus performant, plus intelligent et une course contre les hacker.
Aujourd'hui le premier point faible est avant tout l'utilisateurs final. Pour prendre une image, imaginez une voiture dont le moteur lâche parce que le propriétaire a rajouté un turbo. Tout le travail des hackers aujourd'hui est de convaincre un utilisateur au moins d'ajouter un turbo. Et effectivement la plupart des attaques de hacker utilisent soit des logiciels de type "cheval de troie", soit du spam... autrement dit du social engineering.
Seul les agences gouvernemental ont les moyens de faire du vrai hacking (découverte de failles 0-day, création de virus...) alors que dans les années 70 n'importe qu'elle bidouilleur intelligent y arrivait.
Un hacker isolé ne peut qu'acheter au marché noir un réseau de PC zombi pour faire une attaque DDOS... de moins en moins efficace. S'il veut après acheter une faille 0-day et bien d'autres choses il lui faudra un budget en millions d'euros pour faire une attaque complète...
Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.
Mon petit grain de sable dans cette discussion ...
Je pense qu'il faut faire attention à ne pas confondre sûreté et sécurité, i.e. bugs et failles de sécurité.
Les logiciels fiables (en terme de sûreté) existent, ils sont développés à l'aide des méthodes formelles et peuvent garantir une absence totale de bugs et une correction totale par rapport à la spécification. Comme exemple : Méthode B, model-checking, preuve de programme, ou analyse statique en générale ..
Le problème : ça demande beaucoup de ressource et de compétence, et donc ça coûte cher ... (mais c'est un sujet passionnant !)
Sinon, pour augmenter très fortement la fiabilité sans forcément utiliser des méthodes formelles, il existe d'autre truc. Par exemple, développer avec des langages à typage statique et fort (langages fonctionnels comme OCaml ou Haskell entre autres).
Par contre pour la sécurité des SI contre des attaques extérieurs, c'est un autre sujet. Et là, l'erreur est plus souvent humaine que logiciel ...
see you
Lu'!
Je vais d'abord revenir sur ce point.
Non, on ne peut pas avoir une certitude à 100%. En revanche, pour le critique on sait assurer du 99.9% de certitude ... Par rapport à une spécification donnée.
On appelle ça les méthodes formelles. Et on sait déjà les appliquer sur des projets de taille raisonnable (CompCert, seL4, ...).
Le(s) problème(s) après, c'est
- est qu'on est capable d'écrire la spécification ?
- est ce que ça vaut le coût ?
- est ce que les couches sur lesquelles on se base assurent au moins aussi bien ?
Pour la première question, c'est déjà pas évident. Pour faire de la vérification formelle, on a besoin de specs ... formelles. Cela veut dire apprendre un formalisme aux personnes qui conçoivent. Or ces formalismes ne sont pas simples à prendre en main, encore moins à maîtriser. Et ça, sans compter le fait qu'on peut se gourrer dans la spécification et laisser un joli trou dedans. On peut aussi faire des spécifications trop fortes et (de fait) ne pas réussir à prouver que l'implémentation est valide parce qu'on n'autorise pas assez de cas. Bref, c'est pas simple.
Pour la deuxième question, encore une fois, ça va dépendre des décideurs. Vérifier qu'un micro-noyau à destination d'un hyperviseur pour la Cloud est valide, ça vaut le coût parce qu'il va avoir une tâche très critique. Vérifier formellement que dans l'interface graphique web l'utilisateur verra bien un logo bleu, clairement non. Vérifier formellement le distributed file-system ? Aaaaaah, ça commence à être un peu différent : vérifier formellement que l'utilisateur n'aura accès qu'à ses fichiers, ça peut être cohérent ; vérifier formellement qu'on fait suffisamment de réplications ? ça induit de la probabilité, ça veut dire quoi suffisamment ? Etc. Et même là, tout le monde ne peut pas se permettre ce genre de travaux, pour exemple seL4 et ses 10000 lignes de code c'est de l'ordre de 700$ par ligne de code.
Pour la troisième question, je dirais que c'est la plus cruciale. On ne peut pas imaginer créer un FileSystem parfaitement sûr par dessus un micro-noyau tout pourri de bugs. Plus encore, on ne peut pas assurer qu'un système va tenir ses engagements si un autre système avec plus de droits que lui est susceptible d'aller taper comme un malpropre dans ses données.
Les projets qui se mesurent en millions de lignes de code, c'est de plus en plus répandu. Une erreur assez communes est de ne pas assez les modulariser, cela dit, ce n'est pas toujours facile : un logiciel commence petit, puis gonfle progressivement, jusqu'à un point où l'on se dit "merde, ç'aurait été pas mal de faire un module pour ça et ça", sauf que trop tard, parce que le faire maintenant nécessiterait trop de travail. Un code avec des modules clairement définis est plus facile à spécifier et vérifier.
Finalement un exemple pour illustrer la difficulté. Si on se place dans une optique deuxième question + troisième question et dans le cas des OS, ben force est de constater qu'actuellement c'est peine perdu. Typiquement Linux : on a pleins de modules qui sont définis (très bien). Problème : c'est des millions de ligne de code donc on peut difficilement tout vérifier. Ok, soyons sélectifs, ne vérifions que le plus critique. Problème : tout ce beau monde s'exécute en espace privilégié, donc tout le monde a le pouvoir de tuer tout le monde. On se retrouve avec deux optiques : tout vérifier (20 millions de lignes de code, bon courage) ou reprendre la conception pour avoir la possibilité de vérifier les éléments de manière séparée (approche des micro-noyaux).
Bref, on peut donner des assurances extrêmement fortes qu'un code ne contient pas de bugs par rapport à une spécification donnée. Mais, c'est cher et ça demande des personnes avec des compétences élevées et rares.
Je n'ai pas parlé des problèmes logiciels en général, j'ai expressément restreint mon propos aux failles de sécurité. Et les buffer overflows sur des tableaux (le cas typique) sont bel et bien impossibles avec des langages de plus haut niveau.
Il n'y a pas que Java ou C# dans la vie : Swift, Go ou M#, entre autres, sont justement conçus pour écrire du code système ; ils sont de moins haut niveau que Java ou C# (pas de GC) mais vérifient les limites des tableaux sur chaque accès, promeuvent la séparation stricte des pages de code et de données, interdisent l'arithmétique de pointeurs et certains exposent des mécanismes de concurrence dont le compilateur peut prouver qu'ils ne causeront pas de deadlock. L'impact sur les performances n'est certes pas nul mais il est faible : le surpoids peut souvent être éliminé le compilateur après preuve d'inoffensivité et les conditions introduites sont supposées toujours réussir - sauf bogue du programme - donc pas de rollback du pipeline.
J'aimerais voir une preuve que les effets de bord rendent infaisable l'analyse. Ce qui à ma connaissance rend infaisable l'analyse ce sont des choses comme l'arithmétique de pointeur, les assignations par introspection (reflection), la génération dynamique de code, etc. Pour le reste je veux bien croire que la multiplication des assignations augmentent la taille du problème et donc le temps de calcul mais je doute qu'en 2014 ce soit infaisable, d'autant que le problème est faisable sur GPU (EigenCFA).Certains tentent de résoudre le problème de qualité avec des outils plus poussés (outils d'analyse statique de code, preuves formelles...) mais bon, tant qu'on restera avec des langages qui, par nature, introduisent autant d'effets de bord (en gros, la grande famille des langages impératifs) c'est plus ou moins peine perdue.
Ca ne résoudrait pas le problème : un bogue découle d'erreurs inattention, d'incompréhensions du problème, de défaut de prédiction, etc. Ces erreurs apparaîtraient simplement dans tes contraintes plutôt que dans ton code. Ce serait quand même un progrès : des contraintes déclaratives claires sont plus lisibles et sans doute moins sujette à des bogues que nos langages impératifs.
Cela dit l'idée même de Coq, des tests unitaires, des pré- et post-conditions, etc, c'est la redondance. Tu écris un code pouvant contenir ddes erreurs, tu écris une vérification (tests, invariants, etc) pouvant contenir des erreurs, et tu vois si les deux sont d'accord.
Il y a de plus en plus d'outil ... le reponse est dans la question. Puis a force d'ajouter des couches ont ne peux que ajouter des bug non ?
Je n'ai pas précisé, mais je pensais en particuler à l'arithmetic overflow.
À cause de ça, à un moment il y avait une faille dans MySQL qui faisait qu'on avait une chance sur 256 d'obtenir les droits d'accès root (à cause d'un cast vers char je crois). Un simple brute force suffisait.
Pareil dans le cas de la fusée Arianne 5, qui a explosé en vol à cause d'un dépassement de capacité sur un entier codé sur 8 bits...
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
Merci pour la source. Et, oui, je suis d'accord, difficile de dire quelles conclusions on peut vraiment en tirer : bien sûr qu'on peut écrire des programmes tels qu'en prouver certaines propriétés (comme la preuve de l'arrêt) équivaut à exécuter le programme. Pourtant pour tous les "programmes réels de la vraie vie" les êtres humains sont capables de prouver les propriétés que l'on voudrait que l'ordinateur prouve (sauf programme trop large et erreurs humaines), c'est donc bien que c'est faisable.
Bon en revanche la construction des ensembles may-alias et must-alias est NP-hard. C'est noté et je ne suis pas surpris. Mais là aussi l'être humain y arrive "dans la vraie vie" en raisonnant de façon séquentielle (mais en s'appuyant sur une sacrée indexation mentale préalable).
Ok, cela dit tu reconnaîtras que les buffer overflows sont des failles de sécurité bien plus fréquentes que ce genre d'erreur.
Pour Ariane 5 en revanche c'est un problème de sûreté, pas une faille de sécurité, cf. un commentaire précédent de PierreLeFake.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager