Icônes SCW
héros bg sans séparateur
Blog

Déplacement vers la gauche

Pieter Danhieux
Publié le 22 septembre 2017
Dernière mise à jour le 8 mars 2026

Si un développeur écrit une erreur de script intersite alors qu'il code en JavaScript et qu'il est capable de la détecter quelques minutes après la création de cette faille, il ne faudra probablement que quelques minutes ou secondes pour la corriger.

Alors que si ce défaut est découvert deux semaines plus tard par un testeur manuel, il sera ensuite saisi dans un système de suivi des défauts. Il va être trié. Il va être mis dans la file d'attente des bogues de quelqu'un.

En raison du retard dans son identification, il devra faire l'objet de recherches dans son contexte d'origine et ralentira son développement. Maintenant, vous risquez de perdre des heures pour corriger la même faille. Peut-être qu'une échelle de 10 ou 100 fois plus de temps est nécessaire

Je suis tout à fait d'accord avec Chris Wysopal (CTO, Veracode) dans son récent podcast avec O'Reilly Security Podcast, où il explique pourquoi il est essentiel de déplacer la sécurité vers la gauche (pour les développeurs au début du cycle de développement) dans un environnement agile pour maintenir le rythme et la rapidité.

La sécurité devrait être facilitée pour les développeurs en utilisant des plug-ins et des scanners IDE et en leur enseignant les compétences de base en matière de sécurité (hygiène). Les organisations ne doivent pas se fier uniquement à des experts en sécurité ou à une équipe de sécurité centralisée qui valide tous les changements.

Notre mode de fonctionnement habituel en matière de sécurité ne fonctionne pas (faites appel à un expert !) et nous devons intégrer la sécurité dans les équipes de développement pour garantir le maintien de la qualité tout en restant agiles.

https://www.oreilly.com/ideas/chris-wysopal-on-a-shared-responsibility-model-for-developers-and-defenders

Afficher la ressource
Afficher la ressource

Si un développeur écrit une erreur de script intersite alors qu'il code en JavaScript, et qu'il est capable de la détecter quelques minutes après avoir créé cette faille

Souhaitez-vous obtenir davantage d'informations ?

Directeur général, président et cofondateur

En savoir plus

Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez réserver une démonstration.
Partager sur :
marques LinkedInSocialLogo x
Auteur
Pieter Danhieux
Publié le 22 septembre 2017

Directeur général, président et cofondateur

Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Partager sur :
marques LinkedInSocialLogo x

Si un développeur écrit une erreur de script intersite alors qu'il code en JavaScript et qu'il est capable de la détecter quelques minutes après la création de cette faille, il ne faudra probablement que quelques minutes ou secondes pour la corriger.

Alors que si ce défaut est découvert deux semaines plus tard par un testeur manuel, il sera ensuite saisi dans un système de suivi des défauts. Il va être trié. Il va être mis dans la file d'attente des bogues de quelqu'un.

En raison du retard dans son identification, il devra faire l'objet de recherches dans son contexte d'origine et ralentira son développement. Maintenant, vous risquez de perdre des heures pour corriger la même faille. Peut-être qu'une échelle de 10 ou 100 fois plus de temps est nécessaire

Je suis tout à fait d'accord avec Chris Wysopal (CTO, Veracode) dans son récent podcast avec O'Reilly Security Podcast, où il explique pourquoi il est essentiel de déplacer la sécurité vers la gauche (pour les développeurs au début du cycle de développement) dans un environnement agile pour maintenir le rythme et la rapidité.

La sécurité devrait être facilitée pour les développeurs en utilisant des plug-ins et des scanners IDE et en leur enseignant les compétences de base en matière de sécurité (hygiène). Les organisations ne doivent pas se fier uniquement à des experts en sécurité ou à une équipe de sécurité centralisée qui valide tous les changements.

Notre mode de fonctionnement habituel en matière de sécurité ne fonctionne pas (faites appel à un expert !) et nous devons intégrer la sécurité dans les équipes de développement pour garantir le maintien de la qualité tout en restant agiles.

https://www.oreilly.com/ideas/chris-wysopal-on-a-shared-responsibility-model-for-developers-and-defenders

Afficher la ressource
Afficher la ressource

Veuillez remplir le formulaire ci-dessous pour télécharger le rapport.

Nous souhaiterions obtenir votre autorisation pour vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les transmettrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
icône de réussite scw
icône d'erreur scw
Pour soumettre le formulaire, veuillez activer les cookies « Analytics ». N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

Si un développeur écrit une erreur de script intersite alors qu'il code en JavaScript et qu'il est capable de la détecter quelques minutes après la création de cette faille, il ne faudra probablement que quelques minutes ou secondes pour la corriger.

Alors que si ce défaut est découvert deux semaines plus tard par un testeur manuel, il sera ensuite saisi dans un système de suivi des défauts. Il va être trié. Il va être mis dans la file d'attente des bogues de quelqu'un.

En raison du retard dans son identification, il devra faire l'objet de recherches dans son contexte d'origine et ralentira son développement. Maintenant, vous risquez de perdre des heures pour corriger la même faille. Peut-être qu'une échelle de 10 ou 100 fois plus de temps est nécessaire

Je suis tout à fait d'accord avec Chris Wysopal (CTO, Veracode) dans son récent podcast avec O'Reilly Security Podcast, où il explique pourquoi il est essentiel de déplacer la sécurité vers la gauche (pour les développeurs au début du cycle de développement) dans un environnement agile pour maintenir le rythme et la rapidité.

La sécurité devrait être facilitée pour les développeurs en utilisant des plug-ins et des scanners IDE et en leur enseignant les compétences de base en matière de sécurité (hygiène). Les organisations ne doivent pas se fier uniquement à des experts en sécurité ou à une équipe de sécurité centralisée qui valide tous les changements.

Notre mode de fonctionnement habituel en matière de sécurité ne fonctionne pas (faites appel à un expert !) et nous devons intégrer la sécurité dans les équipes de développement pour garantir le maintien de la qualité tout en restant agiles.

https://www.oreilly.com/ideas/chris-wysopal-on-a-shared-responsibility-model-for-developers-and-defenders

Afficher le webinaire
Veuillez commencer
En savoir plus

Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.

Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez consulter le rapportVeuillez réserver une démonstration.
Télécharger le PDF
Afficher la ressource
Partager sur :
marques LinkedInSocialLogo x
Souhaitez-vous obtenir davantage d'informations ?

Partager sur :
marques LinkedInSocialLogo x
Auteur
Pieter Danhieux
Publié le 22 septembre 2017

Directeur général, président et cofondateur

Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Partager sur :
marques LinkedInSocialLogo x

Si un développeur écrit une erreur de script intersite alors qu'il code en JavaScript et qu'il est capable de la détecter quelques minutes après la création de cette faille, il ne faudra probablement que quelques minutes ou secondes pour la corriger.

Alors que si ce défaut est découvert deux semaines plus tard par un testeur manuel, il sera ensuite saisi dans un système de suivi des défauts. Il va être trié. Il va être mis dans la file d'attente des bogues de quelqu'un.

En raison du retard dans son identification, il devra faire l'objet de recherches dans son contexte d'origine et ralentira son développement. Maintenant, vous risquez de perdre des heures pour corriger la même faille. Peut-être qu'une échelle de 10 ou 100 fois plus de temps est nécessaire

Je suis tout à fait d'accord avec Chris Wysopal (CTO, Veracode) dans son récent podcast avec O'Reilly Security Podcast, où il explique pourquoi il est essentiel de déplacer la sécurité vers la gauche (pour les développeurs au début du cycle de développement) dans un environnement agile pour maintenir le rythme et la rapidité.

La sécurité devrait être facilitée pour les développeurs en utilisant des plug-ins et des scanners IDE et en leur enseignant les compétences de base en matière de sécurité (hygiène). Les organisations ne doivent pas se fier uniquement à des experts en sécurité ou à une équipe de sécurité centralisée qui valide tous les changements.

Notre mode de fonctionnement habituel en matière de sécurité ne fonctionne pas (faites appel à un expert !) et nous devons intégrer la sécurité dans les équipes de développement pour garantir le maintien de la qualité tout en restant agiles.

https://www.oreilly.com/ideas/chris-wysopal-on-a-shared-responsibility-model-for-developers-and-defenders

Table des matières

Télécharger le PDF
Afficher la ressource
Souhaitez-vous obtenir davantage d'informations ?

Directeur général, président et cofondateur

En savoir plus

Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez réserver une démonstration.Télécharger
Partager sur :
marques LinkedInSocialLogo x
Centre de ressources

Ressources pour vous aider à démarrer

Plus de publications
Centre de ressources

Ressources pour vous aider à démarrer

Plus de publications