.png)
Soyons réalistes : il n'y a qu'un nombre limité de listes de contrôle, de manuels de jeu et de politiques que vous pouvez lire avant que vos yeux ne se dessillent. C'est pourquoi nous terminons ce guide de la manière dont tout blog de développement devrait se terminer : avec une FAQ sarcastique et sans BS. Des réponses directes aux vraies questions que les équipes se posent lorsqu'elles essaient de faire fonctionner le développement sécurisé sans l'énergie du manuel de l'entreprise.
Image de remplacement : Description de l'image : Des notes autocollantes avec des questions de sécurité courantes sur un tableau blanc, certaines barrées, d'autres surlignées avec des annotations sarcastiques.
Comment convaincre mes développeurs que la sécurité ne fait pas que les ralentir ?
Dites-leur que cela leur évite des exercices d'évacuation à 2 heures du matin lorsque le produit est en feu, que cela rend les relations publiques plus sûres (moins de risques de retour en arrière) et que cela permet de décrocher des contrats d'entreprise juteux sans avoir à répondre à dix séries de questionnaires de sécurité. En outre, moins de paperasse et moins de réunions avec des gens en costume. Tout le monde y gagne.
Quelles sont les règles de codage sécurisées absolument essentielles à appliquer pour toute équipe ?
- Ne vous fiez pas (jamais) aux données fournies par l'utilisateur.
- Encodez la sortie comme si votre travail en dépendait (car c'est le cas).
- Ne divulguez pas de secrets (votre facture AWS vous remerciera).
Si vous respectez ces trois points, vous êtes déjà plus en sécurité que la moitié de l'internet.
Nous disposons d'une petite équipe et n'avons pas de personne dédiée à la sécurité. Comment pouvons-nous mettre en œuvre de manière réaliste un SSDLC ?
Commencez par ce qui est gratuit. GitLeaks dans les pré-commissions. Semgrep dans les PR. Trivy dans le CI. Faites d'un développeur le "champion de la sécurité" une heure par semaine. Automatisez ce que vous pouvez, déléguez ce que vous ne pouvez pas. Il ne s'agit pas de construire Fort Knox, mais de s'assurer que la maison a des serrures.
Quel est le coût de la mise en œuvre d'un CLSSD et des outils associés ?
Cela peut aller de "quelques pizzas et un hackathon du vendredi" à "plus que la prime de votre PDG". Mais sérieusement : commencez par vous alléger. Les outils open source sont excellents. La version gratuite d'Aikido vous permet de démarrer rapidement. Et le retour sur investissement ? Moins de bogues, des déploiements plus rapides et moins de temps de triage.
Quel cadre SSDLC (SAMM, SSDF, etc.) convient le mieux à une startup ou à une PME ?
Choisissez celui qui ne vous donne pas envie de vous arracher les cheveux. Le NIST SSDF est une base solide et pratique. OWASP SAMM fonctionne très bien si vous voulez plus de structure. Vous pouvez aussi voler les meilleurs éléments des deux et l'appeler "Our Awesome Secure Way of Doing Things™". C'est très bien.
Comment gérer efficacement la fatigue liée aux alertes des outils de sécurité ?
Cessez d'utiliser des outils qui considèrent chaque point-virgule comme une menace. Établissez des priorités sans pitié. Concentrez-vous sur ce qui est réellement exploitable. Utilisez des outils qui vous montrent le contexte, et pas seulement les identifiants CVE et les triangles rouges. (Astuce : Aikido fait exactement cela en donnant la priorité à ce qui est atteignable, corrigeable et en cours de développement).
Réflexion : Il n'est pas nécessaire d'avoir un doctorat en cybernétique pour créer des logiciels sécurisés. Il suffit d'avoir le bon état d'esprit, les bons outils et une équipe qui ne lève pas les yeux au ciel chaque fois que quelqu'un parle de "risque". Vous avez tout ce qu'il vous faut.
