Discussion :

[Amine Horseman]

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 ?

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 ?

[JayGr]

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.

@+

[Max Lothaire]

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

[transgohan]

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.

[spyserver]

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 ...

[Washmid]

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".

[tontonnux]

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.

[MikeRowSoft]

Après tous il existe plusieurs sorte de bogues et plusieurs raisons à ces bogues.

[lrinaldi]

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.

[frfancha]

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.

[NSKis]

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

[Pierre Louis Chevalier]

Ça existe pas des développeurs à 200 Eu / mois, même au Bangladesh.

Généralement un développeur offshore valable c'est au moins 800 Eu / mois.

[NSKis]

Ça existe pas des développeurs à 200 Eu / mois, même au Bangladesh.

Généralement un développeur offshore valable c'est au moins 800 Eu / mois.

Et bien, il va simplement falloir mettre à jour vos informations ainsi que vos tarifs

Lorsque l'on sort des chantiers battus, les prix sont très compétitifs!!! Et vous savez pas la meilleure? Même pas besoin de chercher, les offres vous arrivent sur le bureau sans avoir besoin de demander.

Et franchement parler d'un "développeur offshore valable"... VALABLE??? Vous croyez vraiment que c'est un argument pris en compte par un gars qui gère les coûts de l'entreprise à l'aide d'un tableau Excel?

Sachez, cher Monsieur, que lorsque l'on est un décideur, on commence par outsourcer avec des guignols à 200 euro/mois... C'est plusieurs mois après que l'on se rend compte de la différence entre un développeur valable et un non-valable...

[Pierre Louis Chevalier]

Je suis à jour, et j'ai bien précisé 'Valable" ce qui est une précision d'importance.
200 Eu / mois c'est pas un tarif c'est une escroquerie, pour ce prix rien d'utile ne sera développé, et le gogo "client" va payer pour rien
L'escroquerie la plus courante c'est de tricher sur le nombre d'heures réelles, faute de contrôle efficace, donc si le prestataire escroc déclare 4 fois plus que le nombre d'heure réelles on arrive bien à 200 * 4 = 800 Eu.
Si tu reçois un spam pour une offre de travail à domicile pour sois disant 10 000 Eu par mois, est ce que pour autant tu en conclu que toutes les secrétaires à domicile gagnent 10 000 EU par mois ?
Il ne faut pas confondre email de spammeurs escroc et vrai tarif du marché.

[free07]

Ça existe pas des développeurs à 200 Eu / mois, même au Bangladesh.

Généralement un développeur offshore valable c'est au moins 800 Eu / mois.

Je confirme, 800 Eu / mois c'est vraiment un minimum, de ce que j'ai vu dernièrement, le cout d'un developpeur offshore est entre 10 $US et 30 $US de l'heure selon l'experience et les compétences recherchés.

[NSKis]

... le cout d'un developpeur offshore est entre 10 $US et 30 $US de l'heure selon l'experience et les compétences recherchés.

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!!!!!!!!!

[Alcore]

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.

Celà dépend du contexte. Pour une application d'envoi de mass mailling un truc qui marche à 90% sera sans doute suffisant.
Une de mes conaissance travaille pour Siemens et ils fabriquent des scanners IRM (machines qui coutent plusieurs dizaines de millions d'€ l'unité...).
Dans ce cas, c'est la vie de personnes qui est en jeu et donc ils ne travaillent que avec des sociétés certifiées CMMI niveau 5 pour la gestion du risque, la gestion de la qualité du code, etc... Un truc qui marche à 99,999% des cas est pour eux une nécessité.

Il est cependant faux de s'immaginer que celà coute forcément cher de faire de la qualité.
Quelques bonnes pratiques, la mise en places de bonnes couvertures de tests et éventuellement de tests d'intégration sont déjà un pas.

Dans le monde Java, des outils comme Sonar et Jenkins sont très abordables.
Si dans votre projet la mise en place d'une couverture de tests à 100% est trop compliquée, identifiez les fonctionnalités principales (celles qui géreront la majorité de vos cas d'utilisation) et blindez celles-ci.

[Carhiboux]

La triste réalité, c'est que très très peu de projets ont un véritable suivi de la qualité.

Et par qualité, j'entends pas mal de choses :

Des normes de codages, pour que Jacques et Michel écrivent un code qui se ressemble, qui respecte les mêmes standards.

Un cahier des charges fonctionnel figé et détaillé au moment de la rédaction des spécifications techniques.

Un cahier des charges technique qui prévoit tous les cas. C'est bête dit comme ça, mais de ce que j'ai pu voir, c'est pas si évident que cela pour tout le monde.

Définir les jeux de tests AVANT le développement. Selon moi, on devrait les écrire au moment où l'on rédige la spec technique. Le risque des les écrire après, c'est qu'on va écrire les tests en fonction de ce qu'on a codé, et non en fonction du besoin.

Du budget.

Des ressources compétentes. Les écoles préparent assez peu à la qualité. Autre que le blabla administratif et le collage de post-it, pas forcément inutile, mais qui en soit, ne garanti pas un code sur et propre.

Bref, comme toujours, on en revient à la nature de notre métier, et c'est encore plus vrai en SS2I : les développeurs sont là pour faire du gain, pas de la qualité. J'ai entendu des managers reprocher à leurs équipes de faire de la surqualité! C'est presque surréaliste.

Le jour où les décideurs voudront des logiciels de qualité, les choses changeront. Mais tant qu'ils veulent des produits pas cher... ils auront des produits pas cher. On en a toujours pour son argent. Jamais plus.

[Aurelien Plazzotta]

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.

[abriotde]

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...