Logiciel fiable, réalité ou utopie ?
Malgré la prolifération d'outils et méthodes pour éviter les bugs, pourquoi sont-ils toujours si présents ?

Le , par Amine Horseman, Expert éminent sénior
Avec la hausse du taux de machines infectées par des programmes malveillants à travers le monde et les fréquentes attaques cybercriminelles, qui ne cessent de se multiplier ces dernières années, il arrive un moment où on se demande ce qui ne va pas réellement avec la façon actuelle de procéder.

Le piratage informatique donne accès à des données sensibles et privées, c'est une manière de gagner de l'argent rapidement, de récupérer des données cachées, de montrer sa supériorité ou tout simplement de se faire une réputation dans le monde des hackers. Cependant, le piratage est aussi parfois une façon d'attirer l'attention sur la vulnérabilité de tel ou tel système qu'on croyait sécurisé.

Mais dans tous les cas, le piratage, qu'il soit bon ou mauvais, n'aurait pas pu atteindre une telle ampleur sans l'existence de failles de sécurité. Ces failles sont partout, que ce soit des bugs, des défauts, des erreurs ou tout type de faiblesse que les hackers pourraient utiliser pour pénétrer dans des systèmes auxquels ils n'ont pas accès normalement.

Les failles de sécurité sont tellement fréquentes, qu'il existe des outils pour les traquer ou les répertorier. Des budgets et des efforts colossaux sont mis en œuvre pour les détecter et les corriger rapidement. Toutefois, est-il possible de les prévoir à l'avance ?

La plupart des techniques utilisées aujourd'hui se basent soit sur des simulations de pénétration après avoir fini le développement du logiciel, soit sur des techniques de tests variées pendant la phase d'implémentation. Mais, est-il possible de les éviter avant même d'avoir commencé le codage ? Et pourquoi les méthodes actuelles de création de logiciels donnent naissance à des produits si peu fiables ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de JayGr JayGr - Membre actif http://www.developpez.com
le 05/11/2014 à 14:09
Hello,

Très bon sujet.
On ne peux pas fournir un système 100% fiable.
Que ce soit en développement ou en réseau, jamais un SI ne peut être complètement opaque.

Mais on peut prévenir et éviter un maximum de failles en sensibilisant et en formant les développeurs et les projets !!!
Soyons honnête, nombre de chefs de projet ou développeurs préfèrent éviter d'avoir à faire à la sécurité ("Ils vont encore nous péter le budget !!"). Alors sensibilisons ces gens pour qu'ils viennent d'eux mêmes se renseigner.

C'est pour moi la première étape d'un long travail... Après nous verrons ce qu'il faut changer dans le développement même. Commençons par une prise de conscience collective.

@+
Avatar de Max Lothaire Max Lothaire - Membre averti http://www.developpez.com
le 05/11/2014 à 15:14
En même temps; quand je vois/entends dire que, au niveau des tests unitaire, on peut se satisfaire d'une couverture de 80% du code; je m'étonne peu du nombre de bogues/failles que l'on peut trouver dans les logiciels
Avatar de spyserver spyserver - Membre averti http://www.developpez.com
le 05/11/2014 à 15:34
Pour moi si on part d'un constat simple : les failles ne sont que des entrées/sorties indésirées au sein d'une application, d'un OS ou d'un réseau, on peut "en théorie" en connaissant parfaitement les entrées/sorties de l'appli que l'on code "maîtriser" la sécurité, sauf que le nombre d'I/O explose au sein des systèmes modernes à cause du nombre grandissant d'interfaces, de plateformes et de canaux de communications par lesquelles les applis sont accessibles. Par logique, on se retrouve donc avec une probabilité supérieure d'avoir des failles au sein d'une appli. Je pense qu'il y a des I/O explicites (champ,code JS,formulaire,port ouvert,etc) et implicites (NFC, interception de paquets, etc.), le tout étant de bien les identifier avant de concevoir le système. Comme dit plus haut, c'est davantage par pur soucis économique que l'aspect sécurité est sans cesse négliger au sein de l'IT, je pense que certains systèmes dits très sensibles peuvent tout à fait être correctement sécurisés, encore faut-il le vouloir ...
Avatar de transgohan transgohan - Expert confirmé http://www.developpez.com
le 05/11/2014 à 15:39
Citation Envoyé par Max Lothaire  Voir le message
En même temps; quand je vois/entends dire que, au niveau des tests unitaire, on peut se satisfaire d'une couverture de 80% du code; je m'étonne peu du nombre de bogues/failles que l'on peut trouver dans les logiciels

C'est parce que 80% c'est déjà énorme par rapport à la réalité...
Certains projets couvrent à peine 20% en TU.
(après faut bien comprendre que tout couvrir n'est pas forcement utile, mais de là à dire que seul 20% sont utiles il y a un cap)

Pour ma part cet article m'a fait penser à une phrase sortie un jour comme conclusion de comment améliorer la qualité : "Les développeurs ont qu'à développer sans introduire de bug."
Je vous fait pas le dessin des personnes réunis dans la salle, tous les développeurs ont failli perdre leurs yeux tandis que tous les managers approuvaient bêtement cette si sainte idée.
Avatar de Washmid Washmid - Membre actif http://www.developpez.com
le 05/11/2014 à 15:51
J'ai mieux : 0% de test unitaire chez nous.

La dernière fois qu'on a essayé d'introduire cette notion on s'est fait rembarrer... Alors 20% de tests ce serait le rêve

Puis bon, pour écrire un test, il faut documenter ce qu'on teste, et certains collègues en sont encore à paraphraser le nom des méthodes, et on s'en fout des arguments "ça sert à rien de les décrire".
Avatar de tontonnux tontonnux - Membre expérimenté http://www.developpez.com
le 05/11/2014 à 16:04
Le problème c'est que beaucoup de "failles" viennent de comportements (au sens large) qui n'avaient pas été envisagés.

Du coup, la question devient: "Peut-on envisager ce qu'on n'a pas envisagé ?".
Réponse: "Bah... non."

On peut envisager qu'il y aura des problèmes et mettre en place des process forts de détection et de gestion de ces problèmes.
Vouloir éviter les problème n'a donc aucun sens. En revanche, on peut toujours essayer de mieux les gérer.
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré http://www.developpez.com
le 05/11/2014 à 16:13
Après tous il existe plusieurs sorte de bogues et plusieurs raisons à ces bogues.
Avatar de lrinaldi lrinaldi - Membre à l'essai http://www.developpez.com
le 05/11/2014 à 16:14
Les failles de sécurité sont tellement fréquentes, qu'il existe des outils pour les traquer ou les répertorier. Des budgets et des efforts colossaux sont mis en œuvre pour les détecter et les corriger rapidement. Toutefois, est-il possible de les prévoir à l'avance ?

Dans les petites entreprises, en général il n'y a pas de temps ni de budget pour la sécurité.

La plupart des techniques utilisées aujourd'hui se basent soi sur des simulations de pénétration après avoir fini le développement du logiciel, soit sur des techniques de tests variées pendant la phase d'implémentation. Mais, est-il possible de les éviter avant même d'avoir commencé le codage ? Et pourquoi les méthodes actuelles de création de logiciels donnent naissance à des produits si peu fiables ?

Pour moi le problème réside dans l'utilisation à outrance des "solutions clé en main" de type CMS/ERP/... où le développeur ne voit pas ce qu'il se passe sur le système car soit il n'a pas accès aux sources parce que le système est fermé, soit il n'a pas de temps pour ça.
Sans compter les fois où le système une fois livré et déployé chez un client ne sera plus jamais mis à jour.
Avatar de frfancha frfancha - Membre averti http://www.developpez.com
le 05/11/2014 à 16:26
C'est un choix global de société: un trux qui marche à 90 % à 1000 EUR est préféré à un truc qui marche à 100% à 1.000.000 EUR, c'est tout.
Et c'est sans doute le choix qui a le plus de sens dans certains cas.
Avatar de NSKis NSKis - Membre expérimenté http://www.developpez.com
le 05/11/2014 à 16:42
Citation Envoyé par frfancha  Voir le message
C'est un choix global de société: un trux qui marche à 90 % à 1000 EUR est préféré à un truc qui marche à 100% à 1.000.000 EUR, c'est tout.
Et c'est sans doute le choix qui a le plus de sens dans certains cas.


Je connais un client (une banque que l'on ne nommera pas ) qui a entièrement outsourcé son équipes de développement dans un pays à bas coûts ("outsourcé", c'est le petit mot qui signifie "on vire tous le monde et on fait faire le job par une boite externe qui paye ses développeurs 200 euro/mois")

Et qu'est-il arrivé? Une baisse de la qualité du logiciel

Ben m... alors, on aurait pu espérer qu'avec le genre de coût salarial, ils auraient les moyens de mettre des ressources pour tester leur code
Offres d'emploi IT
Technical leader / moe perle (H/F)
Société Générale - Ile de France - Val de Marne
Ingénieur développeur intégrateur débutant H/F
Safran - Ile de France - Osny (95520)
Chef de projet SI confirmé (H/F)
Société Générale - Ile de France - Val-de-Fontenay

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil