Aller au contenu
Black Fox Security

05 / Conseil et réponse

Une formation au code sécurisé sur du code qui ressemble au vôtre

Des ateliers pour les développeurs sur les failles que nous trouvons en testant des applications : comment les reconnaître dans son propre code et les corriger durablement.

Présentation

Pourquoi une liste de règles ne suffit pas aux développeurs

La plupart des vulnérabilités n'ont rien d'exotique. Ce sont toujours les mêmes classes, par exemple l'injection, le contrôle d'accès défaillant et une gestion de session fragile, réécrites dans une nouvelle fonctionnalité par quelqu'un à qui l'on n'a jamais montré à quoi elles ressemblent dans son langage. Une liste de règles n'y change pas grand-chose. Voir la faille dans du code réaliste et la corriger soi-même, si.

Black Fox construit sa formation au développement sécurisé à partir de ce que nous trouvons en test d'intrusion et en revue de code. Nous l'adaptons aux langages et frameworks de vos équipes, pour que les exemples soient écrits dans un code que vos développeurs reconnaissent et que les corrections utilisent les outils de la stack qu'ils connaissent déjà.

La formation reste défensive du début à la fin. Les participants voient comment une faiblesse est exploitée seulement dans la mesure où cela aide à comprendre pourquoi elle compte. L'essentiel du temps va à la reconnaître, à la corriger et à écrire le test qui l'empêche de revenir.

À qui s'adresse ce service

Les équipes de développement qui construisent des applications web, des API ou des back-ends d'applications mobiles, les équipes dont les tests d'intrusion retrouvent sans cesse les mêmes classes de failles, les nouveaux arrivants dans une équipe technique, et les organisations dont le référentiel ou les clients attendent une formation régulière des développeurs au développement sécurisé, comme c'est courant dans les démarches PCI DSS et ISO/IEC 27001.

Le travail, du cadrage aux preuves.

Ce que nous faisons

  1. Classes de vulnérabilités courantes

    Les failles derrière la plupart des constats réels, par exemple celles du Top 10 OWASP : entre autres l'injection, le contrôle d'accès défaillant, le cross-site scripting, la désérialisation non sûre et la falsification de requêtes côté serveur.

  2. Authentification et sessions

    Stockage des mots de passe, authentification multifacteur, jetons de session, cookies, réinitialisation de mot de passe et contrôles d'autorisation, avec les erreurs que nous voyons le plus souvent.

  3. Traitement des entrées et sorties

    Validation, requêtes paramétrées, encodage des sorties, téléversement de fichiers et analyse de données non fiables, avec les mécanismes sûrs que votre framework fournit déjà.

  4. Dépendances et frameworks

    Choisir et mettre à jour les bibliothèques, lire les avis de sécurité, gérer secrets et configuration, et utiliser les fonctions de sécurité des frameworks comme prévu plutôt que de les contourner.

  5. Conception sécurisée et revue de code

    Penser aux frontières de confiance et aux cas d'abus avant d'écrire le code, et des habitudes de revue qui repèrent les problèmes de sécurité dans les pull requests.

  6. Écrire des tests de sécurité

    Des tests unitaires et d'intégration qui vérifient le contrôle d'accès, le traitement des entrées et d'autres comportements de sécurité, pour qu'une faille corrigée le reste.

Déroulement de la mission

  1. Lancement

    Nous rencontrons vos responsables techniques, convenons du public, des sujets, du format et de la langue, et signons d'abord un accord de confidentialité si vous le souhaitez.

  2. Adaptation

    Nous examinons vos langages, vos frameworks et le type d'applications que vous développez, et adaptons les exemples et les exercices en conséquence.

  3. Ateliers

    Des sessions interactives en ligne ou sur site, en français, en anglais ou en allemand, qui alternent courtes explications et exercices pratiques sur du code réaliste.

  4. Exercices

    Les participants trouvent et corrigent des failles dans du code préparé dans votre stack, puis écrivent des tests qui prouvent que la correction tient.

  5. Suivi

    Une synthèse de ce qui a été couvert, des questions soulevées et des suggestions sur ce qu'il faut pratiquer ou approfondir ensuite.

Ce que vous recevez

  • Plan de formation adapté à vos équipes et à votre stack
  • Ateliers avec exercices sur du code réaliste
  • Supports de formation et code d'exercice pour vos archives
  • Feuilles de présence comme preuve d'audit
  • Rapport de synthèse avec recommandations pour la suite

Questions

Quels langages et frameworks couvrez-vous ?

Nous adaptons la formation à votre stack, par exemple Java et Spring, C# et ASP.NET Core, Python et Django, JavaScript ou TypeScript avec Node.js et React, PHP ou Go. Dites-nous ce qu'utilisent vos équipes et nous vous confirmerons ce que nous pouvons couvrir.

Est-ce la même chose que votre formation DevSecOps ?

Non. La formation au développement sécurisé porte sur le code que les développeurs écrivent et relisent. La formation DevSecOps traite de la sécurité dans la chaîne CI/CD et le processus de livraison. Les deux peuvent être combinées.

Les développeurs apprendront-ils à attaquer des systèmes ?

Seulement dans la mesure où cela les aide à comprendre une faille dans leur propre code. L'accent est mis sur la reconnaissance des faiblesses, leur correction et le test de la correction, pas sur l'attaque de systèmes qui ne leur appartiennent pas.

Pouvez-vous utiliser notre propre code dans les exercices ?

Oui, si vous le souhaitez, sous accord de confidentialité et avec un accès que vous contrôlez. Sinon, nous utilisons du code préparé dans vos langages et frameworks.

Corrigez la faille avant qu'elle ne soit écrite

Dites-nous quels langages utilisent vos équipes et ce qu'ont trouvé vos derniers tests. Nous vous proposerons une formation adaptée à votre code.

Demander un rendez-vous

Envoyez-nous une demande pour organiser une réunion : vous nous présentez votre projet, et nous vous présentons notre équipe et notre expérience comme il se doit.

§ A

Préférences de lecture

Adaptez l’apparence et la lisibilité de ce site. Vos choix s’appliquent immédiatement et ne sont conservés que sur cet appareil.

Ligne témoin

Une bonne ingénierie se démontre, elle ne se proclame pas. Jugez vos réglages sur cette ligne.

§ A.1Texte

Taille du texte
Interligne
Espacement des lettres et des mots
PoliceAtkinson Hyperlegible a été conçue pour les personnes malvoyantes, OpenDyslexic pour certains lecteurs dyslexiques.
Aligner le texte à gaucheSupprime la justification et la césure.

§ A.2Aides à la lecture

Aide à la lectureSuit votre pointeur pour vous aider à garder votre ligne.
Mettre les liens en évidence
Mettre les titres en évidence
Contour de focus renforcéPour la navigation au clavier.

§ A.3Couleur et contraste

Contraste
Saturation des couleurs
Masquer les motifs décoratifsRetire les motifs gravés derrière le contenu.

§ A.4Mouvement et pointeur

Arrêter les animationsLes animations sont déjà réduites si votre système le demande.
Grand pointeur