Quelle mise en pratique du DevSecOps dans les équipes Tech ?

0:01 Merci Lucas pour cette introduction. Je suis ravie du coup avec Adnan et Stéphane de faire ce Ask Me Anything. Donc nous représentons le groupe de travail d'FC Cops de Tech.Rocks et nous avons des compères comme je pense à Camille, je pense à Ludovic, donc Camille de Blablacar et Ludovic de Décathlon. Et bienvenue, donc on va commencer par la première question et voilà, c'est la question, on va dire, qui est complètement d'actualité, c'est quoi la définition en fait du DevSecOps et pourquoi l'adopter? Donc ça, c'est la première question et je vais y répondre, puis Adnan, puis Stéphane, puis on va passer aux questions suivantes. Donc, c'est quoi la définition du DevSecOps? Déjà, commençons en fait par déterminer c'est quoi les trois composantes clés du DevSecOps. C'est évidemment le développement, c'est la sécurité et c'est tout ce qui est opération. Et en fait, le DevSecOps, il vient là comme une méthode pour faire en sorte de capitaliser sur ces trois piliers pour créer une approche holistique du développement.

1:08 Avant, et malheureusement encore beaucoup trop le cas dans plusieurs contextes, tout ça était en silo. Tout ce qui est équipe de développement, ça travaillait de son côté. Tout ce qui est équipe sécurité, de son côté. Et tout ce qui est équipe opération, de son côté. Les équipes développement et développer de nouvelles fonctionnalités les opérations et s'assurer que les environnements étaient bien et tout. Et les équipes sécurité au mieux, je dis bien au mieux, était dans la boucle pour faire vers, on va dire, la fin de la phase développement, juste avant le release. Et je dis au mieux parce que des fois, ce n'est même pas le cas. Il y avait beaucoup, beaucoup trop de release. Sans qu'il y ait un regard sécurité et sans qu'il y ait des checks sécurité. Et c'est malheureusement encore le cas dans plusieurs contextes. Donc, le DevSecOps, il vient là pour casser ces silos, pour s'assurer que la sécurité soit prise en compte dès le début. Phase conception, tout ce qui est phase développement, tout ce qui est phase test, tout ce qui est phase déploiement.

2:09 En fait, c'est l'idée de dire que la sécurité, c'est quelque chose de proactif. On le fait dès le départ, on y pense dès le départ, on fait au fil de l'eau, ce n'est pas quelque chose, on est en réaction et on le fait à la fin, quand on peut, si on veut, etc. C'est vraiment quelque chose qui est inhérent à ce qu'il faut faire en termes de travail, de développement. Donc, c'est cette idée-là sur laquelle repose le DevSecOps. Prenons un exemple concret, prenons l'exemple d'une application mobile. Dans le cadre de non-usage de DevSecOps, on développe la fonctionnalité, on travaille sur ça et puis à la fin, éventuellement, on fait des tests de sécurité et compagnie. Avec l'approche DevSecOps, c'est vraiment dès le départ, dès la phase de conception, qu'on se pose, qu'on détermine c'est quoi les mesures de sécurité à mettre en place et compagnie. Et après, ça en fait les tests de sécurité. au fil de l'eau. Et lorsqu'on arrive à la phase release, on a déjà fait tout ce qu'il faut en termes de sécurité. On s'est assuré de, on va dire, doser tous les efforts au fil de l'eau.

3:10 Et là, je passe la main à Adnan pour compléter. Tu as déjà un peu tout dit, mais bon, on va compléter. L'idée vraiment, c'est de se dire, d'aborder d'un point de vue agile, la mise en production de nouvelles fonctionnalités ou l'amélioration continue de votre application et d'intégrer finalement, comme il y a dix ans, on a intégré l'Obs dedans pour casser ce mur entre la prod qui n'a pas envie de toucher parce que moins ça bouge, plus c'est stable. Et etc. Donc là, l'objectif, c'est de rajouter la sécurité là-dedans. Alors, comment on peut faire ça? Typiquement, dans tout ce qui est pipeline de CICD, de rajouter, comme le disait Aroua, un maximum de tests, que ce soit du SAST, que ce soit du linting, que ce soit de la vérification sur l'infrascode pour vérifier, effectivement, est-ce qu'il n'y a pas des failles obvius de sécurité?

4:12 Genre, tiens, maintenant, il y a un truc qui fait un all-hall sur un 9-firewall. C'est peut-être pas ouf, etc. Et donc l'idée, c'est d'automatiser le plus possible, mais pas forcément que automatiser. Donc ça peut inclure aussi un peu de manuel, ça peut inclure de la remontée d'alerte. Ça peut inclure pas mal de choses. On pense à des outils comme, et souvent pour les startups, du sonar, ce genre de choses. Mais l'idée, c'est vraiment de pouvoir avoir un feedback en temps réel, live, sur l'état un peu de où est-ce qu'on en est. De la même manière que sur les tests automatisés il y a 10 ans, on aimait avoir dans ces pipes de CICD un état de mon application, à quel point j'ai cassé des choses ou pas. Le deuxième objectif de tout ça, c'est que le mettre le plus proche possible du développement, ça fait qu'on implique le développeur dans cette démarche de sécurité et de le sensibiliser, parce que ce n'est pas le problème de quelqu'un d'autre, beaucoup plus tard, qui va regarder.

5:16 C'est le problème du développeur qui, si sa branche doit être merge, ça sera à lui probablement de corriger ce qu'il a fait. Je vais passer la parole à Stéphane. Merci Adnan, bonjour tout le monde. Effectivement, le but du jeu, c'est qu'on puisse intégrer toute cette gestion de la sécurité dans le flux, qu'on puisse continuer à avoir un flux continu de release et donc de production de valeur. Parce que si on ne fait pas ça, un jour, on aura un problème de sécurité et ça, ça coûte. Très cher et où même s'il n'est pas vu par les clients, ça fait vraiment arrêter tout le monde pendant longtemps pour tout corriger. Donc le but du jeu, c'est de continuer dans ce flux et donc de faire ce qu'on appelle du shift left, c'est-à-dire de remonter les exigences de sécurité au plus tôt. Donc ça veut dire les intégrer dans les pipelines avec des outils par exemple, effectivement. On peut aussi monter encore un cran plus haut, dès la définition du besoin et le raffinement avec les product owners, intégrer les contraintes de sécurité là-dedans.

6:17 Puisque, en fait, pour que ça fonctionne, il faut qu'on ait une adhésion de tout le monde dans ce process-là, pour que chacun comprenne la valeur ajoutée. Donc, il ne faut pas que les product owners se disent, tiens, pourquoi mes développeurs, là, ils sont en train de faire du sonar, à quoi ça sert? Ça sert ce truc. Et il ne faut pas que les développeurs non plus disent à quoi sert cet outil-là qui me remonte 50 erreurs, ça m'empêche d'avancer. Il ne faut pas que les développeurs se disent, moi, la culture, je n'y connais rien. Donc, il faut accompagner tout ça d'un vrai changement de culture. Il faut vraiment enraciner ça dans tout le processus de développement logiciel. Donc, du début, la collecte du besoin jusqu'à la prod. Et si on arrive à faire ça, on améliore la sécurité des applications. Tout le monde est impliqué et on met en prod des choses qui ont déjà un bon niveau de sécurité. Bat-up. Merci du coup à Adnan et à Stéphane pour ces compléments. On passe maintenant à la deuxième question. Donc, quel type d'automatisation peut-on intégrer dans un environnement DevSecOps?

7:18 Donc, comme l'a un peu déjà abordé Adnan, évidemment, tout ce qui est automatisation, c'est clé. Alors, disons déjà qu'en fait, pas tout est automatisable, pas forcément dans tous les contextes, pas forcément dans tous les repos, etc. Donc, il faut avoir une sorte d'étude préalable pour déterminer ce qu'on va automatiser ou pas. Mais une fois que ça s'est dit, clairement, l'automatisation est un des piliers du DevSecOps parce qu'en fait, ça permet de s'assurer que réellement, on est en train de faire régulièrement les tests de sécurité, par exemple. Et qu'est-ce qu'on met derrière le mot test de sécurité, check et compagnie? Par exemple, le SAST. Donc le SAST, c'est analyse statique du code et c'est par exemple regarder au niveau du code, est-ce qu'il y a des erreurs qui font que ça peut laisser des vulnérabilités pour des attaques. Il y a aussi ce qu'on appelle tout ce qui est check de dépendance. Check de dépendance, comme vous le savez, les hackers, ils sont friands.

8:19 De piéger des dépendances pour s'assurer que les efforts qu'ils font en termes de hacking aient, on va dire, une portée de milliers, de millions de personnes. Donc, c'est un de leurs vecteurs, on va dire, favoris pour s'assurer de s'introduire dans des entreprises. Et donc, du coup, partant de là, c'est important pour les entreprises de faire en sorte que les dépendances qu'elles utilisent dans le cadre de leur code soient mises à jour, soient bonnes, etc. Et donc, du coup, les checks de dépendance, comme des pannes d'abottes, comme plusieurs autres, s'assurent, regardent par rapport aux versions utilisées dans le cadre d'un code donné, et va les comparer avec les dernières versions, etc. Et s'il arrive qu'il y a une version qui n'est pas à jour, etc., ça peut créer des pull requests pour s'assurer qu'on soit au niveau, en termes de dépendance utilisée. Je passe la main à Adnan pour compléter. J'ai perdu le fil de la question, pardon. Par rapport à l'automatisation, Sarah, quel type d'automatisation peut-on intégrer dans un environnement d'FC Cops?

9:26 Donc, j'ai parlé par rapport à tout ce qui est... Oui, oui, j'ai compris ce que tu as dit, mais je... J'étais passionné par ce que tu as dit. Ah bah super! Effectivement, après, il y a d'autres types de tests qu'on ne considère pas forcément comme des tests de sécurité ou qu'on met parfois de côté. C'est tous les tests qui concernent les permissions dans l'application. Souvent, on considère que tester toutes les routes pour tous les droits ou tous les rôles, etc., c'est assez inutile et superflu. En vrai, c'est quelque chose qui ne coûte virtuellement rien du tout à faire. Et en plus, quand on a déjà des tests automatisés, et ça permet de s'assurer qu'on n'ouvre pas une petite porte déguisée de temps en temps. Parce qu'effectivement, les SaaS permettent assez facilement d'identifier certains types de problèmes comme les supply chain attacks ou les injections SQL, ça commence à être pas mal. Il y a pas mal de choses qui commencent à être vues. Les regex qui permettent de didos parce que la regex est un peu trop hier.

10:30 Mais il y a un certain nombre de sujets où les SAS ne sont pas très bons parce qu'il y a besoin de comprendre le contexte de est-ce qu'en fait on veut vraiment faire ça ou pas et ça le SAS il a plus de mal à définir ça. Et donc il ne faut pas hésiter à essayer d'être le plus complet possible. Un autre truc qui se met aussi de plus en plus en place, c'est la feedback loop avec la prod. C'est-à-dire qu'on a du DAST en production qui va faire aussi de l'analyse dynamique, on a des WAF qui vont faire un peu d'analyse dynamique, qui vont peut-être toper des trucs, mais qui doivent non seulement faire l'objet d'un fixe, mais idéalement un fixe égale aussi un test en plus pour s'assurer que ce n'est pas réintroduit d'une manière ou d'une autre. En tout cas, ça doit poser une certaine question sur« Ah, ok, j'ai eu peut-être ça à tel endroit, comment je m'assure que nulle part ailleurs j'ai ce type de problématique? Oui, c'est un peu ça. Et après, il y a la partie sur les autres outils. Donc, il n'y a pas que le code, il y a l'infra aussi. Et effectivement, il faut aussi... garder ça, peut-être mettre en place un certain nombre de garde-fous aussi en termes de...

11:35 Des flots de validation sur les merge requests. Là, tu es en train de toucher à un truc, ce n'est peut-être pas tout le monde qui peut approuver la merge request. On ne va peut-être pas laisser le stagiaire approuver les merge requests où il y a de l'infra avec du débranchement de firewall ou ce genre de choses. Donc, c'est un peu tout ça et c'est réfléchir à la fois au process, à la feedback loop et à ce qu'on peut mettre en place dans ce cadre-là. Il faut que je vous laisse, il faut que j'aille vérifier les droits de mon stagiaire. Non, je rigole. Effectivement, en fait, on en est... Ça arrive, ça arrive. Oui, mais là, j'imagine bien. On est un peu au même niveau pour les tests de sécurité et les outils de sécurité que pour les tests tout court et les outils de CI tout court. On a tous plusieurs milliers ou dizaines de milliers de tests qui tournent à chaque commit. Et c'est absolument nécessaire et essentiel. Mais il faut aussi, à côté de tout ça, rajouter de l'humain pour tout ce qui n'est pas forcément couvert par ces choses-là.

12:38 Donc, par exemple, quand on fait l'analyse de vulnérabilité dans un pipeline, On va se retrouver avec plein de CVE, peut-être deux ou trois chaque jour, tous les jours, et on ne peut pas toujours toutes les mettre à jour. Donc, une analyse d'impact pour voir si cette CVE impacte vraiment notre logiciel, ça, c'est quelque chose de très important. C'est donc quelque chose d'humain qui va compléter l'analyse automatique de la vulnérabilité. Et si on a un système un peu mature, on peut justement dans ce système-là mettre l'acknowledgement de cette vulnérabilité ne nous touche pas parce que telle et telle raison. Et comme ça, on peut garder le test automatisé qui sera vert et pas rouge. Et de la même façon que pour les tests classiques, les tests automatisés, ils sont bien complémentés par des testeurs humains. Ou des testeuses, chez Antidote Topics, on a des testeuses, qui trouvent plein de choses que les développeurs n'ont pas pensées. C'est pareil pour la sécurité. C'est important d'avoir des pen tests de temps en temps, donc des gens qui prennent la solution et qui essaient de la craquer.

13:42 J'aime bien aussi l'approche interne, un peu red team. On prend des gens d'autres équipes qui essayent de craquer le bout des autres équipes. Ça, ça permet de se prémunir de insider threats, c'est-à-dire des gens qui, à l'intérieur de votre société, pourraient devenir méchants, soit encore en tant que salarié, soit en partant. Et ça, justement, ça va dans la boucle de feedback. Comme les tests humains, si on arrive à en automatiser quelques-uns, c'est bien, on enrichit les tests automatiques. Donc voilà, il y a cette combinaison-là qui est très intéressante à mettre en place. Au top. Donc, du coup, maintenant, on passe à la troisième question. J'ai vu que Rémi a posé une question. Donc, du coup, une fois qu'on termine par rapport à la troisième, on passe à la question de Rémi. Donc, par rapport à la troisième question, c'est qu'est-ce qu'un security champion et comment sont-ils sélectionnés ou désignés? Donc, déjà, le security champion, c'est une personne au niveau d'une équipe.

14:42 Donc, ça peut être une équipe de dev, ça peut être une équipe de data, qui est là, on va dire, avec des connaissances en sécurité, ça peut être des connaissances en sécurité applicative, et qui est là pour sensibiliser, du coup, les autres membres de l'équipe. Elle est là pour les former. les sensibiliser, mais aussi pour s'assurer que les mesures de sécurité sont bien prises en compte au niveau de cette équipe-là. Pourquoi il y a cette notion de security champion? C'est qu'en fait, on a les équipes sécurité, ou l'équipe sécurité suivant la taille de l'entreprise, ou le RSSI tout seul dans le cadre d'une entreprise, ou pas de ressources du tout. Et on a, par exemple, les équipes dev ou les équipes data qui se retrouvent sans forcément quelqu'un au niveau de l'équipe pour savoir quoi faire exactement dans le détail en termes de sécurité. Et donc, la notion de Security Champion, elle vient combler ça. Elle vient faire la tridulian entre tout ce qui est, on va dire, les équipes sécu, le RSSI, où il n'y a rien à la base, versus les équipes en tant que telles.

15:51 Donc, typiquement, par exemple, un Security Champion dans le cadre d'une équipe de dev, il va former les autres, il va sensibiliser les autres, il va s'assurer, par exemple, s'il y a des SAST, des DAST, des YAST, des analyses de sécurité au niveau du plan CICD, il va s'assurer. Que les vulnérabilités qui ont été découvertes, surtout les critiques et compagnie, ont bien été résolues. Donc, du coup, le Security Champion, c'est un peu comme ça, une personne ressource au niveau d'une équipe donnée qui va être un peu le leader sur le côté sécurité pour former, inspirer, sensibiliser et faire en sorte que la sécurité soit parmi les priorités de cette équipe. Et je passe la main à Adnan pour compléter. Oui, c'est un peu ça. Après, il ne faut pas non plus voir ça comme le KGB qui infiltre toutes les unités de l'armée pour surveiller par tout ce qui se passe. Mais un peu quand même. Après, l'idée, c'est comment les trouver, ces gens-là.

16:53 Parce qu'effectivement, selon la taille de l'entreprise, soit on n'a pas les moyens, soit c'est compliqué, soit même si on a une grosse entreprise, si je débarque un profil complètement sécurisé, complètement sécurité, mais qui ne comprend rien à l'applicatif ou au business en question, ça va être compliqué, etc. Donc, il y a différentes approches. L'idée, c'est... Peut-être qu'au début de la démarche, vous n'aurez pas forcément des security champions partout qui seront des acharnés de la cybersécurité, capables de détecter des patterns rien qu'en lisant le code. L'idée, c'est plus de trouver les gens qui ont la bonne appétence au sujet. Pour qu'eux, entre guillemets, un peu comme chez les scouts, leur mettent un petit badge sur l'épaule pour qu'ils se sentent responsables de cette partie-là et que surtout cette partie-là ne soit pas quelque chose qui soit oublié au sein de l'équipe. Le fait d'avoir quelqu'un qui prend finalement cette responsabilité fait que, L'idée, ce n'est pas de lui taper dessus s'il ne s'est pas bien fait, mais l'idée, c'est que de lui-même, normalement, ça devrait l'inciter à être un peu plus attentif là-dessus.

17:58 Et après, ces security assumptions-là, Il faut les former. Alors, dans un monde idéal, on a des experts cyber qu'on est capable de parachuter dans chaque équipe qui, en deux-deux, vont comprendre le business et la tech mis en place et tout va bien se passer. Dans la vraie vie, je ne sais pas si ça arrive souvent, sauf si vraiment on a beaucoup de chance. Donc moi, ce que j'ai plutôt tendance à faire, c'est trouver des gens qui ont la bonne appétence, qui ont envie de faire ça, et de faire épauler ces gens-là par des gens un peu plus capés. Après, pour reprendre l'exemple que disait Rémi, de, on est une petite équipe et on est une dizaine de devs. Idéalement, tu n'as pas forcément un profil sécurité qui va faire que de la sécurité. Mais tu vois, moi, aujourd'hui, je suis dans une petite boîte qu'on a montée et donc on est une dizaine de devs. L'un des devs que j'ai pris, c'est quelqu'un qui, à la base, est plutôt un profil cyber. Alors, il fait plein d'autres choses.

18:58 Il fait du dev, il fait de la data, il fait de l'IA, il fait plein d'autres choses. Mais au moins il avait ce background là dès le départ et du coup entre guillemets, il nous fouette gentiment dès qu'on fait une bêtise. Et même moi, en bon CTO, je montre l'exemple. Et quand il met une règle en place, je la suis. Donc, il ne faut pas négliger ça. Ce n'est pas parce qu'on est une petite boîte qu'il faut mettre de côté la cyber. Ça ne veut pas dire qu'il faut en faire trop non plus. Mais plutôt, c'est un... intégrer dans les process et dans le mindset de l'entreprise, plus facile ça sera à maintenir et à faire progresser. Alors que si on dismisse ça pendant deux ans et qu'on essaye de s'y mettre, ça va faire très très mal quand on commence à s'y mettre. Ok. Effectivement, le training de la sécurité pour les Security Champions, comme un peu tout le monde, c'est un vrai...

20:02 Ce qui est important, je pense, à terme, c'est qu'on ait vraiment une culture de sécurité dans chaque équipe. Donc, on commence par initier ça avec des security champions. Moi, j'aime bien prendre des gens juste qui sont motivés, peut-être qu'ils ne comprennent rien et peut-être que c'est ça qui les motive ou peut-être qu'ils sont déjà très forts. Ils peuvent servir de relais avec leur équipe dans les deux sens, pour faire descendre les messages de sécurité, mais aussi pour remonter des questions. Moi, je travaille au marketing, je ne comprends pas ce que ça veut dire, quel est l'impact chez moi, etc. Et donc le but, c'est qu'on ait vraiment la sécurité dans les compétences de chaque équipe. On pourrait presque faire tourner les Security Champions de temps en temps. Et donc, ces Security Champions, effectivement, on peut les épauler par des gens qui ont un peu plus de compétences et aussi par des ressources en ligne. Donc, pour répondre à la question de Rémi, une des choses qu'on a mis en place chez nous, c'est quelque chose qui s'appelle OASP, ASVS. C'est des ressources en ligne avec beaucoup de choses très factuelles sur ce qu'il faut prendre en compte dans le développement d'une application.

21:03 Il y a plusieurs niveaux de sécurité, le 1, le 2, le 3. Déjà, en général, si on essaie d'atteindre le 1, ça occupe pendant un petit bout de temps. Très bien. Du coup, Sarah, on a répondu à la question 3 et aussi par rapport à la question de Rémi. Je complète, Sarah, par rapport à la réponse Rémi. Donc, pour la dire, c'est que nous avons déjà en place des bonnes pratiques au niveau de la CIA, SNIC, des Pandabot. On a des pentests réguliers, mais on reste une petite équipe d'une dizaine de devs. Quelle bonne formation de développement sécurisé existe pour former l'équipe en attendant de recruter un profil sécurité? Alors, en fait, il y en a plusieurs par rapport à tout ce qui est développement sécurisé. Il faut comprendre que lorsque c'est dans le cadre d'entreprise, le mieux, c'est que ça soit du full présentiel, soit du semi-présentiel, c'est-à-dire quelque chose d'hybride entre du e-learning et entre du présentiel ou par visio, en tout cas qu'il y ait une interaction et un suivi régulier.

22:07 Et moi, par exemple, lorsque j'effectue ce type de formation, j'utilise des ressources, je vais vous l'écrire, par exemple, celle-ci. Try Hakimi, qui intéresse pas mal tout ce qui est développeur, data et tout, parce qu'en fait, c'est des labs, en quelque sorte, où on peut, du coup, entre guillemets, tester ces connaissances, mais réellement de manière pratique, par exemple, par rapport au top 10. De l'OASP. Donc, du coup, on va passer à la quatrième question. Donc, la quatrième question, c'est comment gérer l'équilibre entre le shift left et la pression pour des livraisons rapides et fréquentes. Effectivement, la notion de shift left, Stéphane l'a déjà un peu abordée, c'est de s'assurer en fait que tout ce qui est sécurité ne soit pas abordé vers la fin, mais que ça soit abordé dès le départ.

23:11 Et effectivement, dans beaucoup trop de contextes, on se dit business first, ça n'en va pas, ça va faire de la sécurité dès le départ, on y pense lorsqu'on aura tout terminé et compagnie, et puis il faut tenir les délais, etc. Le point que c'est avec toutes les réglementations qu'il y a, avec les questionnaires de sécurité qui deviennent de plus en plus à rallonge, avec les preuves qui sont demandées actuellement avec les questionnaires de sécurité, on ne peut plus ne pas produire quelque chose de sécurisé. Ça, c'est devenu quelque chose, on va dire, entre guillemets, d'obligatoire, ne serait-ce que pour ne pas être vulnérable tout de même à des attaques, mais aussi pour gagner du business. Partant de ce principe-là, et partant du principe que la sécurité n'est pas quelque chose d'optionnel, mais quelque chose qui doit vraiment être réalisé, autant le réaliser dès le départ avec cette approche de shift left, parce qu'in fine, si par exemple, Au fil de l'eau, on s'assure, on anticipe les risques, on s'assure que s'il y a des vunes qui ont été découvertes, en fait, on va les corriger dès le départ, etc.

24:18 Avant qu'elles grossissent, qu'elles font en sorte qu'à la fin, elles deviennent beaucoup trop complexes, beaucoup trop complexes à gérer et compagnie. Donc, avec cette approche de shift left, finalement, on est plus rapide si on part du postulat qu'à la fin, on veut quand même avoir un produit sécurisé. Et je passe la main à Adnan. En fait, la problématique du shift left d'un point de vue d'FC Cops, c'est la même que la problématique du shift left dans la QE. C'est-à-dire que globalement, tu vas avoir des remontées, des alertes, un certain nombre d'indicateurs qui vont te dire ça, ça va, ça, ça ne va pas, ça, ça va, ça, ça ne va pas. manière que, on va dire, dans un mode de développement plus conventionnel, tu as la QA qui vient te faire 50 remontées chaque fois qu'il teste la release. Et finalement, vous allez faire le tri dans les remontées de dire, OK, ça, ça, ça, ça, ça, c'est must fix. Ça, ça, ça, ça, ça, c'est nice to fix. Ça, ça, ça, c'est soit du as design, soit c'est peut-être un jour, soit etc.

25:24 Alors, la difficulté, c'est comment trouver le juste point d'équilibre parce qu'on ne peut pas juste dire, ah ouais, mais... Là, il y en a trop, on ne va pas faire et tant pis. Mais c'est toujours un trade-off qui revient au même genre de trade-off que celui de la QA, mais qui demande un peu plus de compréhension des impacts de chaque élément. En tout cas, l'impact est parfois plus difficile à comprendre que dans de la QA basique, que le bouton ne marche pas ou ce genre de choses. Mais pour moi, c'est vraiment la même chose et il faut aborder la problématique de la même manière. Tout à fait, c'est vraiment la même chose. Et en fait, on peut avoir à gérer une dette de sécurité comme on peut avoir à gérer une dette technique ou une dette de qualité. Et donc, on peut avoir à un moment donné l'obligation de se dire, je ne vais pas faire de release parce que là, il y a un problème de sécurité grave. Mais aussi, dans l'autre sens, il faut que j'amène cette feature-là, j'ai des engagements, il y a une vulnérabilité.

26:29 Pas très grave, est-ce que je mets à jour ou est-ce que je ne mets pas à jour? Et donc, on peut de temps en temps avoir à faire des décisions de privilégier un côté ou l'autre. Comme pour les autres dettes, ce qui est important, c'est de la gérer, de la mesurer. Et donc, si on décide de mettre en ligne et qu'il y a une vulnérabilité, il faut savoir rapidement corriger la vulnérabilité. Et là, bien sûr, plus on saura mettre à jour souvent son application, mieux on sera. Parce que s'il y a un jour tous les six mois, ce n'est pas pareil que s'il y a un jour tous les jours. Et si on a tout ça, on peut prendre des décisions éclairées et discuter avec toutes les parties prenantes et faire en sorte de prendre la bonne décision. Au top. Donc, du coup, là, je rebondis sur le commentaire de Geoffrey qui dit que c'est un trade-off entre sécuriser son business et prendre vite ses parts de marché. La clé est de se mettre d'accord sur la stratégie et prendre un risque dans tous les cas, dur dur, clairement. Et ça rejoint en plus la question qui nous a été posée, c'est comment impliquer le management dans la démarche d'FC Cops.

27:36 Donc, du coup, par rapport à ça, comme partout, en fait, c'est important d'impliquer le management, mais d'autant plus lorsque, voilà, on est une startup scale-up et qu'on doit avancer. Quand je dis management, je ne parle pas uniquement du CTO. Je parle du CEO, je parle du CRO et compagnie. C'est-à-dire que moi, qui interviens beaucoup dans tout ce qui est startup et scale-up, je peux vous dire, je vous raconte un cas où le CTO, il était motivé pour la partie sécurité, mais son CRO et son CEO, ils étaient un peu en mode freinage. Parce qu'eux, ce qu'ils souhaitaient, c'était faire passer les fonctionnalités une par une, répandre le plus rapidement possible aux demandes de nouvelles fonctionnalités des clients et compagnie. Et le CTO était bien embêté parce qu'il voulait régler ses dettes de sécurité, il voulait avancer aussi sur des questions de refactoring, etc. Mais il avait ses propres enjeux, mais il y avait les enjeux business. Et le jour où les deux se sont alignés, du coup, ce que voulait le CTO et ce que voulaient les CRO et le CIO, en fait, ça a été directement visible en termes de,

28:43 on va dire, production au niveau de l'équipe, parce qu'avant, le CTO, il ne pouvait pas trop donner de temps dans les sprints, dans ce que faisaient les devs aux aspects sécurité. Mais une fois que le CIO a reçu de plus en plus de demandes par rapport aux questionnaires, par rapport à la sécurité, et qu'il a vu qu'en fait, lorsqu'il avait les rendez-vous avec les clients, etc., la partie sécurité était de plus en plus posée sur la table, il est allé voir le CTO, il lui a dit, OK, prends le temps nécessaire, vu que ça devient quelque chose d'important aussi pour le business. Donc, du coup, toujours... Faire comprendre aux autres stakeholders que la partie sécurité, c'est aussi bon pour le business et de plus en plus avec toutes les réglementations qui vont venir et je passe la main à Adnan. En fait, ce n'est pas trop une problématique généralement de grands groupes. Généralement, la plupart des grands groupes comprennent que, Il faut quand même faire attention à la sécu parce qu'elles comprennent que le risque associé est potentiellement important.

29:49 Alors, peut-être pas tous au même niveau, mais je veux dire, il y a quand même un peu plus de compréhension sur ces secteurs-là. Et généralement, il y a un peu plus de... de moyens aussi pour pouvoir adresser ces sujets. Ça ne veut pas dire qu'ils font un meilleur travail, mais en tout cas, la problématique d'impliquer le management, généralement, est un peu plus facile. Dans les startups et dans les PME, ça peut être plus difficile selon les... Le board selon la santé financière de la boîte, selon les objectifs à court terme. Et il y a aussi un deuxième problème, c'est que pour beaucoup de non-tech, tout ça paraît un peu abstrait. Donc, ils se disent, ouais, mais de toute façon, même si on sécurise, on sera troué, ou là, aujourd'hui, on a autre chose à faire, etc. Après, c'est toujours une quantification du risque. Donc, il faut essayer d'expliciter ce risque, de donner des exemples le plus possible concret de qu'est-ce qui pourrait se passer si on ne fait pas ça, de choisir un peu, peut-être au début,

30:55 les quelques combats, parce qu'on ne pourra pas tout adresser de front dès le départ, et de rendre ça tangible le plus possible pour le management. Après, il y a un deuxième sujet, c'est que vous êtes quand même C-level, vous êtes normalement C-level, feature, pas feature, etc. Au final, personne ne va imposer aux équipes quoi faire, à part vous. Donc, il faut garder conscience quand même que si vous êtes à ce rôle de responsabilité, vous avez aussi normalement le pouvoir qui va avec. Et de la même manière qu'ils vont vous dire, non, non, mais il faut pousser les features, il faut pousser les features, rien ne vous empêche de dire à vos équipes, vous poussez des features, mais vous gardez tant de temps pour faire ça ou vous fixez des règles dans les process petit à petit. Pour vous assurer qu'on y remédie petit à petit. De toute façon, même votre management, CEO, CFO, CRO, whatever, ils ne vont pas se poser à côté du dev à lire les lignes de code pour comprendre est-ce que le dev est en train de patcher un truc de sécu ou est-ce que le dev est en train de rajouter un bouton dans un formulaire.

32:02 Donc, là où c'est plus compliqué parfois, c'est quand il y a besoin d'acheter ou de faire des dépenses externes. Il y a besoin d'un nouvel outil, il y a besoin de rajouter du WAF en front des serveurs, il y a besoin de ceci, cela. Après, il faut toujours essayer de tempérer le risque par rapport aux bénéfices. Et effectivement, comme le disait Aroua, un des leviers souvent qui touche, alors plus les startups ou les PME qui font du B2B que du B2C, c'est que la plupart des grands comptes, grands groupes et de sociétés qui commencent à avoir une taille importante ou qui sont sur des marchés qui sont suffisamment réglementés, devrait vous inonder de demandes d'un point de vue sécurité pour justifier A, B, C, D, E, F, G. Donc à force peut-être de recevoir ce type de demande et de perdre potentiellement des contrats, ça rendra ça très tangible même pour un CRO. Voilà. Clairement, si on n'est pas au niveau, en termes de sécurité, et qu'on fait du B2B, on va se retrouver vite coincé.

33:12 Le fait d'être au niveau en sécurité, ce n'est pas forcément quelque chose qui aide à vendre, mais si on n'y est pas, ça bloque les ventes. Puisque en particulier, tous les gens qui sont certifiés vont vérifier que leurs fournisseurs le sont aussi ou qu'ils sont au niveau attendu. Et si on fait du B2B, on a aussi des choses comme l'acné, etc. En face. Donc, ça dépend du niveau de maturité de l'entreprise. Est-ce qu'on a déjà des clients ou est-ce qu'on est en train de chercher un produit? Est-ce qu'il y a déjà du grand public en face? Et effectivement, il faut faire du risk assessment pour voir qu'est-ce qui se passe si jamais ça, ça sort, ça, ça lique, etc. Ou qu'est-ce qui se passe si je n'ai pas le niveau de sécurité attendu? Est-ce que ça va bloquer ma croissance ou pas? Je suis tout à fait d'accord avec Adnan, quand on est CTO, ça fait partie des responsabilités. Et donc, c'est toujours mieux d'emmener tout le monde avec soi, mais sinon, c'est la même façon qu'on ne va pas justifier comment on travaille tous les jours et de faire la scie, etc. On intègre la sécurité dedans. Et pour évangéliser les gens, on peut toujours essayer de leur faire lire des livres, des ressources.

34:16 Donc, il y a un livre qui commence à être un peu vieux, mais que moi, j'adore, c'est le Phoenix Project. Il n'est pas complètement sur la sécurité, mais il est sur ce processus de flux. Et ça, ça se lit comme un roman ou comme une série. Et c'est vraiment l'histoire de... C'est une entreprise où c'est la catastrophe. À force de ne pas avoir investi dans toutes ces choses-là, ils sont complètement coincés, ils n'arrivent plus à bouger. Et en mettant en place des processus en flux, des processus continus, petit à petit, ils sortent la tête de l'eau. Donc, on peut aussi essayer d'évangéliser comme ça avec des choses, je ne vais pas dire grand public, mais un peu moins technique. En plus, toi Stéphane, tu peux témoigner par rapport à ton co-founder qui est CEO, que lui aussi, il est au taquet côté sécurité. Oui, j'ai un co-founder qui est très technique, donc j'ai de la chance. On n'a pas de bataille sur ça, mais j'imagine bien que des fois, c'est plus compliqué. Mais même s'il n'était pas très technique, moi, je vois tous les sales ou les pre-sales qui arrivent avec tous les questionnaires de sécurité, effectivement. Et des fois, si c'est des très grosses sociétés, ce n'est pas un lot de questionnaires de sécurité, c'est plusieurs lots de plusieurs...

35:19 Département de cette société-là. Et en fait, franchement, si on n'a pas cette culture au fond de la société, on ne peut pas répondre. Ou alors, il faut mentir, ce que je ne peux pas imaginer. Au top. Et pareil, c'est à initier très tôt et potentiellement avec des choses qui peuvent parler à tout le monde, même une RH, quelqu'un du marketing, whatever. Nous, typiquement, dès le début, c'était si tu partages des infos perso sur Slack, tu payes le petit-déj le lendemain matin. Si tu ne verrouilles pas ton PC, tu payes le petit-déj le lendemain matin. Ça paraît bête, mais au bout de 6 mois, 1 an, ça met quand même du temps avec les gens intègres, mais au bout de 6 mois, 1 an, malheureusement, on n'a quasiment plus de petit-déj tous les matins. On est à un petit déj toutes les deux semaines en moyenne de quelqu'un qui a fait un loupé. Et c'est important que le management joue aussi le jeu. C'est-à-dire que la règle, elle s'applique aussi pour le CEO, elle s'applique aussi pour tout le monde, elle s'applique aussi pour vous.

36:22 Parce que si vous, vous n'appliquez pas les propres règles que vous définissez, les gens ne vont pas les appliquer à terme. Mais ce genre de choses les aide petit à petit et vous pouvez renforcer ça par des nouvelles petites règles. On fait des tests de phishing automatisés et c'est pareil. Maintenant, test de phishing, tu t'es fait avoir, c'est petit déj. Alors, ça peut sembler coercitif, mais ça marche pas mal. Oui, complètement. Geoffrey rebondit, il dit que les campagnes de phishing, ça aide pas mal parce que c'est concret et que ça permet aux gens, lorsqu'ils introduisent leur identifiant mot de passe, clairement, ils comprennent qu'ils ont fait des bêtises. Du coup, on a parlé par rapport aux questions qui nous ont été posées. Là, on va compléter un tout petit peu. Je me permets juste à Roi, je me permets de te couper. Il nous reste encore 4 minutes.

37:22 Donc, merci en tout cas à tous les trois. On peut peut-être encore prendre le temps. En effet, je vous laisse compléter peut-être sur la... Peut-être une dernière question. Et n'hésitez pas, bien sûr, aujourd'hui, vous êtes une dizaine avec nous. Donc, sur ces quatre, trois dernières minutes, n'hésitez pas à Geoffrey, Rémi, si vous avez encore des questions, et tous les autres. Mais je vous laisse, je te laisse bien sûr compléter. Et s'il y a des questions entre temps, pareil, de les prendre. Oui, avec plaisir. Donc, en attendant, s'il y a une question complémentaire, c'était juste pour parler un peu du groupe de travail. DevSecOps, donc dans le cadre de Tech.Rocks. Donc, comme je l'ai un peu évoqué en début, là, on est un groupe, ça fait plus d'un an, là, ça fait presque plus d'un an et demi qu'on bosse ensemble, qu'on se réunit à peu près tous les mois. Au départ, c'était pour faire des articles, on a fait cinq ou six l'année dernière, et on échange cette année autour de nos enjeux respectifs.

38:29 Donc, n'hésitez pas, si vous avez des enjeux en termes de DevSecOps, si vous voulez les faire challenger par des CTO comme vous, ça va venir nous rejoindre. Ok, merci. Sur cette partie, c'est vrai, merci à Roi de l'avoir mentionné. En fait, on va passer, aujourd'hui, le canal est privé sur le Slack. Et en effet, ça faisait suite à une demande, l'année dernière, on a avancé en petit groupe. Mais là, suite au format, après ce matin, on va le passer en public. Donc, c'est l'occasion en tout cas que vous puissiez nous rejoindre et puis que ce soit un terrain de jeu pour partager votre veille, vos problématiques, etc. Et en tout cas, il y a une bonne inertie qui est déjà bien lancée. Donc, voilà, c'est super. Mais n'hésitez pas à nous rejoindre. Pour respecter l'horaire, je pense qu'on est bon, Sarah, pour terminer dans les clous. Oui, super. Écoutez, merci à tous les trois. C'était super, en tout cas, d'avoir vos retours. d'avoir vos retours et vos réactions sur ça.

39:29 On est... Normalement, on aurait dû être en format un petit peu plus workshop, mais à coup de pas de notre côté, côté Tech.Rocks, on prend la responsabilité, mais on fera un prochain format pour sûr. Avec cette dimension-là, il y a quelques questions, vous êtes plus d'une dizaine, donc il y a un bon signal, n'hésitez pas à nous rejoindre, moi je communiquerai sur le Slack le replay et la marche à suivre pour nous rejoindre, et sinon on se dit à très vite, et merci encore à Nan, à Roy et Stéphane. Pour votre temps, pour la communauté. Et on se dit à très vite. Merci. Au revoir. Bonne journée tout le monde. Merci.