1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mars 2017
    Messages
    565
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2017
    Messages : 565
    Points : 15 082
    Points
    15 082

    Par défaut Les principaux obstacles à la sécurisation des logiciels aujourd’hui dans le cycle DevOps

    Les principaux obstacles à la sécurisation des logiciels aujourd’hui dans le cycle DevOps
    D'après une étude de Checkmarx

    Selon un nouveau rapport, la majeure partie des entreprises auraient encore du mal à mettre en œuvre la sécurité dans leurs processus DevOps, un terme qui fait référence à un mouvement en ingénierie IT et à une pratique technique visant à l’unification du développement logiciel (Dev) et de l’administration des infrastructures informatiques (Ops), notamment l’administration système.

    Ce rapport intitulé « Managing software exposure: time to fully embed security into your application lifecycle » (gérer l’exposition des logiciels : il est temps d’intégrer pleinement la sécurité dans votre cycle de vie applicatif) provient d’une étude menée par Checkmarx, un spécialiste de la sécurité des applications. Il examine les principaux obstacles à la sécurisation des logiciels aujourd’hui dans le cycle DevOps et regroupe les commentaires de 183 personnes originaires des quatre coins du monde, la majeure partie d’entre elles évoluant dans les domaines du développement logiciel, de la sécurité IT et de l’informatique en général.

    Cette étude met en lumière le fait qu’il existe un grand fossé entre ce qui est nécessaire et ce qui est réellement en place, relevant que 96 % des personnes interrogées estiment qu’il est « souhaitable » ou « hautement souhaitable » que les développeurs soient correctement initiés à la production de code sécurisé. En effet, les organisations sont de plus en plus nombreuses à adopter une démarche DevOps, il est donc impératif que les développeurs travaillant pour elles prennent la responsabilité de sécuriser eux-mêmes les nouveaux logiciels qu’ils conçoivent.

    Nom : 2.jpg
Affichages : 3096
Taille : 155,6 Ko

    Malheureusement, seulement 11 % des personnes interrogées ont déclaré avoir répondu de manière adéquate au besoin de formation des développeurs évoluant dans leurs organisations pour atteindre cet objectif. En outre, 41 % des sondées reconnaissent que la définition de la responsabilité et de la propriété en matière de sécurité des logiciels reste un défi majeur.

    Habituellement, des équipes opérationnelles spécifiques sont responsables au sein des organisations de la sécurité logicielle. Mais il existerait entre les développeurs et les équipes opérationnelles une relation conflictuelle qui génèrerait de problèmes au niveau de la communication et serait à l’origine d’une culture d’inefficacité. Même si la démarche DevOps est censée éliminer un grand nombre de barrières entre ces deux départements, 72 % des personnes interrogées estiment que les différentes équipes et disciplines au sein du département informatique hésitent encore trop souvent à se faire confiance.

    Nom : 1.jpg
Affichages : 2832
Taille : 57,6 Ko

    Ce rapport insiste également sur le fait qu’il est important d’éduquer et de motiver la haute direction à penser à la sécurité des logiciels en tant que risque commercial, indiquant que 44 % des répondants ont déclaré que les dirigeants ne se soucient pas des moyens mis en œuvre par les développeurs pour fournir rapidement, régulièrement et en toute sécurité des logiciels. Tout ce qui les intéresserait la plupart du temps, c’est que le travail soit fait.

    Le rapport de Checkmarx précise à ce propos que 57 % des sondées sont d’accord avec l’affirmation selon laquelle la sécurité des logiciels est désormais « un problème de salle de réunion » et 45 % des répondants trouvent qu’il est difficile de faire approuver le financement de la formation en sécurité des développeurs par la haute direction.

    Nom : 0.jpg
Affichages : 2779
Taille : 19,3 Ko

    La première étape pour renforcer la manière dont la sécurité est intégrée au cycle de livraison des logiciels consisterait donc à impliquer davantage la partie dirigeante des organisations concernées. La seconde étape serait probablement de mettre en place un cadre qui permettrait aux développeurs, aux testeurs, aux spécialistes de la sécurité et au personnel des opérations de travailler ensemble en harmonie.

    Source : CheckMarx

    Et vous ?

    Qu’en pensez-vous ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre émérite Avatar de marsupial
    Homme Profil pro
    DevOp, Tech leader
    Inscrit en
    mars 2014
    Messages
    818
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : DevOp, Tech leader

    Informations forums :
    Inscription : mars 2014
    Messages : 818
    Points : 2 574
    Points
    2 574

    Par défaut

    En résumé, la teneur de l'article tient dans 96% des professionnels sont d'accord pour sécuriser mais 0% des instances dirigeantes veulent investir dans de la formation ou dans le recrutement. Déjà le bât blesse. Mais lorsqu'on sait que la sécurité est un métier et qu'un des spécialistes, un ex de la CIA, a rapporté l'an dernier qu'il manquait 1,6 million de candidats rien que pour le marché des Etats-Unis, il serait peut être grand temps de mettre des billes dedans en formation. D'ailleurs, je ne sais même pas comment on fait en France pour tenir debout toutes les infrastructures. Les ESN spécialisées sont surbookées et en surcharge permanente. Et je pense que la situation est similaire partout dans le monde.

    C'est à dire que les équipes gèrent trop de clients différents. Au cas où un WannaCry impacte trop de clients, tous ne pourront être servis en même temps. Attention à la catastrophe.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  3. #3
    Provisoirement toléré
    Homme Profil pro
    Historien
    Inscrit en
    mai 2018
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Algérie

    Informations professionnelles :
    Activité : Historien

    Informations forums :
    Inscription : mai 2018
    Messages : 200
    Points : 22
    Points
    22

    Par défaut

    c'est surtouts un probleme d'attribution des compétences.

    je ne suis pas payé pour sécurité mais pour développer.
    je suis pas sécurité mais développeur, je code des features mais c'est tous. Il faut e payer plus ou payer quelqu'un d'autre pour faire du test ou de la sécurité.
    ce sont des domaines complexe et un développeur qui s'improvise testeur ou sécuriseur et très dangereux car il n'a pas les compétences requise pour cela, il au mieux des notions.

    La sécurité, le test sont des domaines qui demande des années d'expériences significatives.
    je préferaire donc payer un expert qui fera tout le process nécessaire pour sécurisé.

    a alger j'ai bien appris tous ce qui était chiffrement (rsa...etc), les attaques xss, injection sql...etc. mais ai-je de l'expérience la dedans ? non.
    si je connais bien la théorie je suis un 0 en pratique, le risque d'erreur est trop grave. Il vaut mieux payer un externe pour faire un audit de sécurité.

  4. #4
    Membre régulier
    Homme Profil pro
    Etudiant en alternance
    Inscrit en
    septembre 2015
    Messages
    26
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Etudiant en alternance

    Informations forums :
    Inscription : septembre 2015
    Messages : 26
    Points : 83
    Points
    83

    Par défaut

    Citation Envoyé par ShigruM Voir le message

    je ne suis pas payé pour sécurité mais pour développer.
    je suis pas sécurité mais développeur, je code des features mais c'est tous. Il faut e payer plus ou payer quelqu'un d'autre pour faire du test ou de la sécurité.
    ce sont des domaines complexe et un développeur qui s'improvise testeur ou sécuriseur et très dangereux car il n'a pas les compétences requise pour cela, il au mieux des notions.
    Donc si on suit ton raisonnement, un développeur web n'a pas à se soucier des injections SQL, failles XSS... ? La qualité d'un code passe par sa sécurité d’ailleurs, les failles sont souvent abordées des les cours/tuto.
    Quand j'ai appris le C l'une des premières chose qu'on m'a enseigné sur les tableaux est de bien faire attention à leurs tailles afin d'éviter les dépassement de tampons, je n'ai pas eu besoin de savoir comment ça fonctionnait pour comprendre que c'était un point qui posait problème et nécessitait de faire attention.

    Je ne pense pas que le développeur ait besoin d'être un expert en sécurité, il doit juste être conscient des potentiels points critiques de ses applications pour limiter la casse. Évidemment un audit de sécurité est toujours une bonne idée, quand on parle de sécurité mieux vaut trop en faire que pas assez.

  5. #5
    Membre actif
    Homme Profil pro
    Développeur .NET
    Inscrit en
    juin 2011
    Messages
    85
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2011
    Messages : 85
    Points : 234
    Points
    234

    Par défaut

    Citation Envoyé par ShigruM
    je suis pas sécurité mais développeur, je code des features mais c'est tous. Il faut e payer plus ou payer quelqu'un d'autre pour faire du test ou de la sécurité.
    Je ne suis pas du tout d'accord avec ça. Peut être que ça va bien si tu en es au début de ton apprentissage (à "pisser des lignes" comme on dit vulgairement), mais à un moment donné le développement vas plus loin :

    Faire du test ne dépend pas forcément que testeur, cf le TDD et le BDD. Le testeur a une plue value pour les parcours de bout en bout, on peut même faire appel à un automaticien, mais le fait de tester tes méthodes et avoir une bonne couverture de code ne dépend que de toi.

    Concernant la sécurité, au final un audit de sécurité va te dire "il y a une faille ici, ici" : il faut te dire comment résoudre tout et le faire à ta place ? Nous sommes des ingénieurs, nous sommes capables de réfléchir un minimum par nous même et d'anticiper les failles les plus communes (OWASP) et de les traiter pour laisser aux personnes faisant l'audit de sécurité de se concentrer sur des cas plus exotiques.

    Quant à la remarque "Il faut me payer plus"...

  6. #6
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    juin 2013
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2013
    Messages : 18
    Points : 74
    Points
    74

    Par défaut

    Citation Envoyé par ShigruM Voir le message
    je ne suis pas payé pour sécurité mais pour développer.
    je suis pas sécurité mais développeur, je code des features mais c'est tous. Il faut e payer plus ou payer quelqu'un d'autre pour faire du test ou de la sécurité.
    ce sont des domaines complexe et un développeur qui s'improvise testeur ou sécuriseur et très dangereux car il n'a pas les compétences requise pour cela, il au mieux des notions.

    [...]

    a alger j'ai bien appris tous ce qui était chiffrement (rsa...etc), les attaques xss, injection sql...etc. mais ai-je de l'expérience la dedans ? non.
    si je connais bien la théorie je suis un 0 en pratique, le risque d'erreur est trop grave. Il vaut mieux payer un externe pour faire un audit de sécurité.
    Les attaques XSS, injections SQL des domaines complexes ? Je ne veux pas être désagréable mais ça me rend fou de lire ça.

    En PHP (puisque nous sommes sur du web) :
    - htmlspecialchars ou htmlentities pour les failles XSS
    - utiliser correctement PDO contre les injections SQL

    Pas besoin d'un diplôme d'ingénieur pour faire ça, ni d'être payé plus.
    Sans parler de la quasi-totalité (si ce n'est tous) des frameworks qui gère déjà ces 2 notions de sécurité.


    Sauf application avec fonctionnalités bien particulières, (pour moi) un développeur doit savoir sécuriser son application, le contraire m'est juste inconcevable.
    En cas d'attaques, je veux bien savoir comment tu te justifies auprès de ton client.

  7. #7
    Membre averti
    Homme Profil pro
    Inscrit en
    décembre 2011
    Messages
    190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : décembre 2011
    Messages : 190
    Points : 377
    Points
    377

    Par défaut

    Un développeur est responsable de la sécurisation du code bien entendu !!
    Pour moi les devs doivent faire de la veille et connaitre les mécanismes de bases je dirais (au moins) et ensuite doivent être conseillés par une instance externe qui s'appelle en général la sécurité dans les boites.
    Sur mon projet la sécu avait dressé une liste de recommandations avec des points critiques et des nice-to-have (encryption, algo de chiffrement utilisé, failles diverses et variés sur les tokens, etc...) ça m'a pris une journée de vérifier point par point si on répondait aux critères (en utilisant des librairies solides j'avais déjà couvert 90% des recos), au final il me manquait pas grand chose et on a pu s'aligner sur la version suivante donc dire que ce n'est pas notre métier c'est du non sens.
    Nous sommes les premiers concernés justement et je trouve très enrichissant et gratifiant d'avoir une app sécurisé, si on vous appelle un jour et qu'on vous explique que votre app s'est faites hackée et qu'on vous demande des comptes ... honnêtement j'ai pas envie d'être dans ce genre de situation.

    Par contre clairement notre salut se trouve dans l'usage de librairies solides et éprouvés, on ne devrait jamais partir sur du code custom avec des features touchant à la sécurité, il faut donc éviter au maximum que ça arrive et se reposer sur les standards, en faisant ça comme j'ai expliqué on couvre 90% des failles.

  8. #8
    Membre expert
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 561
    Points : 3 751
    Points
    3 751

    Par défaut

    Citation Envoyé par xav67 Voir le message
    Donc si on suit ton raisonnement, un développeur web n'a pas à se soucier des injections SQL, failles XSS... ?
    Citation Envoyé par Beowulf59 Voir le message
    J Nous sommes des ingénieurs, nous sommes capables de réfléchir un minimum par nous même et d'anticiper les failles les plus communes (OWASP)
    Les failles les plus communes devraient en effet être prise en compte par le développeur.

    Citation Envoyé par XanatosAO Voir le message
    Les attaques XSS, injections SQL des domaines complexes ? Je ne veux pas être désagréable mais ça me rend fou de lire ça.
    Par contre il est illusoire de croire qu'en tant que dev on est en capacité de se prémunir de toute attaque, y compris les attaques XSS ou injection SQL, car oui le xss et l'injection sql sont des domaines complexe. Les frameworks ajoutent des fonctionnalités pour les limiter, mais ce n'est pas suffisant, comme le prouve chaque journée qui passe .
    Les hackeurs sont passionnés et trouveront toujours un détournement de fonction (que l'on qualifie de faille).
    C'est pourquoi j'ai de gros doute sur la généralisation de formations en expert sécurités, qui à mon avis seront juste un nid à charlatan comme on en trouve dans tous les métiers, et qui feront juste gonfler la note d'un projet.

  9. #9
    Inactif  
    Femme Profil pro
    Développeur informatique
    Inscrit en
    août 2018
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 24
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2018
    Messages : 18
    Points : 0
    Points
    0

    Par défaut

    l'argent et le temps sont bien les problemes.

    Moi dans mes projets ce qui morfle c'est la sécurité et les tests quand on est a cours de budget/temps.
    Je privilégie les fonctionnalités et l'UI qui sont les valeurs clients, car le client sera contant.
    le jour ou le système du client se fait hacker il ne vas s'en prendre à moi, il me contactera et me payera par contre pour l'accompagner à la sécurité de ces solutions.

    donc pour moi c'est un business model, le client nous presse pour avoir son soft, on lui livre un soft non testé et pas sécurisé, il nous repaye plus tard pour sécurisé sont parc applicatif.

    le mieux est quand on a accès a la BDD, on lui qu'un concurrent n'a utilisé que du md5 pour chiffré sa BDD (en réalité c’était moi, malynx ), du coup je diffame un concurrent et j'emporte la satisfaction client qui me prend pour un dieu avec mes termes compliqué et l'ajout de la sécurité.

    la sécurité, les bugs c'est important car c'est ce qui nous donne du pouvoir et du travail. On peu même créer un bug critique qui requiert notre service pendant un weekend pluvieux en automne/hiver, le client vas facturer très cher le dimanche pendant le week end on peut glander sur developpez.net et corriger le "probleme" dimanche à 16H en modifiant juste la ligne de code que l'on volontairement mal codé.

    dernnier point c'est la performance, on peut la aussi créer volontairemlent une sur consommation de ram du soft dans une version 1.0 afin de faire payer au client une V2 qui divise par 2 la consommation de ram.

    suffit simplement de génerer un gros tableau d'entier qui prend 1Go de ram et de supprimer cette ligne, 1 semaine payé juste pour supprimer 1 ligne elle est pas belle la vie ? et en plus la aussi tu passera pour un dieu en ayant /2 la ram.
    pour le cv tu peut ensuite raconter tes exploits, optimisation de code ultra bas niveau de la mort qui tue, sécurisation renforcé je suis un vrai agent du OWASP...etc. plus c'est gros plus sa passe, sont tellement bête de toute façon. si c'est un informaticien en fasse de toi tu reste vague, tu reste uniquement en surface sans rtentrer dans les détails, tu parle d'architecture cloud, palette de service...etc.

  10. #10
    Membre averti
    Avatar de Psycadi
    Homme Profil pro
    Chef de projet - Expert en message box
    Inscrit en
    juillet 2003
    Messages
    144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet - Expert en message box

    Informations forums :
    Inscription : juillet 2003
    Messages : 144
    Points : 330
    Points
    330

    Par défaut

    @mamadoudou, t'es pas un dev toi, t'es un charlatan o_O

    sinon pour parler du sujet, il est vrai que la sécurité est l'affaire des dev mais il faut aussi que les dirigeants (chef de projet, de département...) donnent les moyens de faire de la sécurité. En tant que chef de projet, j'ai souvent eu du mal à avoir plus de temps (donc de l'argent) pour sécuriser une application. En général, ça se termine par quelques devs experts qui font des heures supp. pour supprimer les failles les plus importantes/connues et le reste, on verra quand on sera en Prod.
    ρs¥

  11. #11
    Membre émérite
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    667
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 667
    Points : 2 937
    Points
    2 937

    Par défaut

    Certains commentaires sur ce fil montrent un manque de sensibilisation à l'écriture d'un code robuste qui contrôle les entrées des utilisateurs (dont le contenu des URL).

    Une injection SQL ne peut exister qu'en cas d'erreur de programmation. En effet, si on construit une requête SQL en concaténant naïvement des chaînes de caractères, dont une chaîne inconnue quelconque (donc qui peut être un bout de code SQL) en faisant comme si ce n'était pas une chaîne quelconque, alors c'est une erreur de programmation.

    Éviter les injections SQL, ce n'est pas faire des trucs mystiques spécifiques à la sécurité informatique : c'est seulement essayer d'écrire du code robuste.

    Et quand on cherche comment écrire du code robuste autour des requêtes SQL, on cherche sur internet et on tombe sur la réponse : utiliser des requêtes préparées.

  12. #12
    Membre habitué
    Homme Profil pro
    Architecte réseau
    Inscrit en
    avril 2018
    Messages
    96
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Architecte réseau
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : avril 2018
    Messages : 96
    Points : 184
    Points
    184

    Par défaut

    Citation Envoyé par Christian Olivier Voir le message
    Qu’en pensez-vous ?
    Je ne suis pas codeur.

    En revanche, je suis intéressé d'en savoir plus sur ce qu'on appelle "sécurité d'un code" et comme j'ai un peu la flemme de chercher
    Il doit exister des best practices je suppose ?

    -VX

  13. #13
    Expert confirmé
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    2 479
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 479
    Points : 5 656
    Points
    5 656

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Utiliser des requêtes préparées.
    Ouais, mais il se cache un truc très bête : "échapper toutes les entrées pour les transformer en chaîne de caractères"


    Citation Envoyé par vxlan.is.top Voir le message
    Je ne suis pas codeur.

    En revanche, je suis intéressé d'en savoir plus sur ce qu'on appelle "sécurité d'un code" et comme j'ai un peu la flemme de chercher
    Il doit exister des best practices je suppose ?
    En fait , c'est avant tout
    • de respecter les pré et les post conditions (par exemple, de limiter les caractères aux caractères textes lors de la saisie)
    • de tester toutes les entrées utilisateurs (ou à défaut de les transformer en chaîne de caractères)
    • de s'appuyer sur des bibliothèques qui ont fait leurs preuves (par exemple, OpenSSL)
    • de se maintenir au courant en terme de sécurité (par exemple, le MD5 est obsolète) et des retours d'expérience (par exemple, Sony qui ne chiffre pas leur base de données)


    En gros, essentiellement tous les petits "trucs" qui sautent parce que pas le temps/ pas nécessaire/ trop chiant à coder/ ...

  14. #14
    Membre du Club
    Profil pro
    Inscrit en
    novembre 2005
    Messages
    56
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2005
    Messages : 56
    Points : 63
    Points
    63

    Par défaut

    Citation Envoyé par mamadoudou Voir le message
    l'argent et le temps sont bien les problemes.

    Moi dans mes projets ce qui morfle c'est la sécurité et les tests quand on est a cours de budget/temps.
    Je privilégie les fonctionnalités et l'UI qui sont les valeurs clients, car le client sera contant.
    le jour ou le système du client se fait hacker il ne vas s'en prendre à moi, il me contactera et me payera par contre pour l'accompagner à la sécurité de ces solutions.

    donc pour moi c'est un business model, le client nous presse pour avoir son soft, on lui livre un soft non testé et pas sécurisé, il nous repaye plus tard pour sécurisé sont parc applicatif.

    le mieux est quand on a accès a la BDD, on lui qu'un concurrent n'a utilisé que du md5 pour chiffré sa BDD (en réalité c’était moi, malynx ), du coup je diffame un concurrent et j'emporte la satisfaction client qui me prend pour un dieu avec mes termes compliqué et l'ajout de la sécurité.

    la sécurité, les bugs c'est important car c'est ce qui nous donne du pouvoir et du travail. On peu même créer un bug critique qui requiert notre service pendant un weekend pluvieux en automne/hiver, le client vas facturer très cher le dimanche pendant le week end on peut glander sur developpez.net et corriger le "probleme" dimanche à 16H en modifiant juste la ligne de code que l'on volontairement mal codé.

    dernnier point c'est la performance, on peut la aussi créer volontairemlent une sur consommation de ram du soft dans une version 1.0 afin de faire payer au client une V2 qui divise par 2 la consommation de ram.

    suffit simplement de génerer un gros tableau d'entier qui prend 1Go de ram et de supprimer cette ligne, 1 semaine payé juste pour supprimer 1 ligne elle est pas belle la vie ? et en plus la aussi tu passera pour un dieu en ayant /2 la ram.
    pour le cv tu peut ensuite raconter tes exploits, optimisation de code ultra bas niveau de la mort qui tue, sécurisation renforcé je suis un vrai agent du OWASP...etc. plus c'est gros plus sa passe, sont tellement bête de toute façon. si c'est un informaticien en fasse de toi tu reste vague, tu reste uniquement en surface sans rtentrer dans les détails, tu parle d'architecture cloud, palette de service...etc.
    Au hasard , prie pour le ta clientèle , qui ce doit de faire de la veille sécuritaire , ne ce retourne pas envers l ' ANSSI et t ' adresse un mise en demeure pour une application ne tenant pas compte de leurs suggestion de construction ... il et vrai que si ce n 'est pas dans ton cahier des charges ... mais tu devrais le faire en connaissance de cause

  15. #15
    Membre habitué
    Homme Profil pro
    Architecte réseau
    Inscrit en
    avril 2018
    Messages
    96
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Architecte réseau
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : avril 2018
    Messages : 96
    Points : 184
    Points
    184

    Par défaut

    Citation Envoyé par foetus Voir le message
    En fait , c'est avant tout
    • de respecter les pré et les post conditions (par exemple, de limiter les caractères aux caractères textes lors de la saisie)
    • de tester toutes les entrées utilisateurs (ou à défaut de les transformer en chaîne de caractères)
    • de s'appuyer sur des bibliothèques qui ont fait leurs preuves (par exemple, OpenSSL)
    • de se maintenir au courant en terme de sécurité (par exemple, le MD5 est obsolète) et des retours d'expérience (par exemple, Sony qui ne chiffre pas leur base de données)


    En gros, essentiellement tous les petits "trucs" qui sautent parce que pas le temps/ pas nécessaire/ trop chiant à coder/ ...
    OK, merci.

    -VX

Discussions similaires

  1. Les États-Unis exhortent l'Australie à ne pas faire confiance à Huawei
    Par Christian Olivier dans le forum Actualités
    Réponses: 9
    Dernier message: 01/03/2018, 08h25
  2. Réponses: 26
    Dernier message: 13/09/2014, 17h41
  3. Réponses: 3
    Dernier message: 24/05/2005, 12h35
  4. [Débutant] Les opcodes sur les différents processeurs
    Par loverdose dans le forum Assembleur
    Réponses: 11
    Dernier message: 03/02/2005, 13h32
  5. faire un group by sur les différents niveau de code
    Par speed034 dans le forum Langage SQL
    Réponses: 4
    Dernier message: 07/10/2004, 16h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo