{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"La peur et la haine de DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nous avions 2 analyseurs de code, 4 outils de test dynamique, nos propres cr\u00e9ations et 250 scripts. Ce n'est pas que tout cela \u00e9tait n\u00e9cessaire dans le processus actuel, mais comme j'ai commenc\u00e9 \u00e0 int\u00e9grer le DevSecOps, il fallait aller jusqu'au bout.<\/p>\n

\"La
\n
\nSource<\/a><\/noindex>. Les cr\u00e9ateurs des personnages : Justin Roiland et Dan Harmon.<\/i><\/p>\n

Qu'est-ce que SecDevOps ? Et DevSecOps ? Quelle est la diff\u00e9rence ? La s\u00e9curit\u00e9 des applications - de quoi s'agit-il ? Pourquoi l'approche classique ne fonctionne-t-elle plus ? Toutes ces questions ont des r\u00e9ponses. Youri Chabaly<\/b> de\u00a0Swordfish Security. <\/b>Youri r\u00e9pondra \u00e0 toutes ces questions et analysera les probl\u00e8mes de transition du mod\u00e8le classique de la s\u00e9curit\u00e9 des applications vers le processus DevSecOps : comment bien int\u00e9grer le processus de d\u00e9veloppement s\u00e9curis\u00e9 dans le processus DevOps sans rien casser, comment passer par les principales \u00e9tapes de test de s\u00e9curit\u00e9, quels outils peuvent \u00eatre utilis\u00e9s, en quoi ils diff\u00e8rent et comment les configurer correctement pour \u00e9viter les pi\u00e8ges.
\n<\/a><\/noindex>
\n

\r\n \"Lire\r\n
<\/div>\r\n <\/div><\/center>
\n\u00c0 propos de l'intervenant :<\/b> Youri Chabaly - <\/b>Chief Security Architect dans l'entreprise Swordfish Security<\/b>. Il est responsable de l'impl\u00e9mentation du SSDL, de l'int\u00e9gration g\u00e9n\u00e9rale des outils d'analyse d'applications dans un \u00e9cosyst\u00e8me unifi\u00e9 de d\u00e9veloppement et de test. 7 ans d'exp\u00e9rience en s\u00e9curit\u00e9 informatique. A travaill\u00e9 chez Alfa-Bank, Sberbank et Positive Technologies, qui d\u00e9veloppe des logiciels et fournit des services. Intervenant lors de conf\u00e9rences internationales telles que ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

S\u00e9curit\u00e9 des applications : de quoi s'agit-il ?<\/h2>\n

\nS\u00e9curit\u00e9 des applications<\/b>\u00a0\u2014 est un domaine de la s\u00e9curit\u00e9 qui est responsable de la s\u00e9curit\u00e9 des applications. Cela ne concerne pas l'infrastructure ou la s\u00e9curit\u00e9 du r\u00e9seau, mais sp\u00e9cifiquement ce que nous \u00e9crivons et sur quoi travaillent les d\u00e9veloppeurs \u2014 il s'agit des d\u00e9fauts et des vuln\u00e9rabilit\u00e9s de l'application elle-m\u00eame.<\/p>\n

Direction SDL ou SDLC<\/a><\/noindex>\u00a0\u2014 Cycle de vie de d\u00e9veloppement de la s\u00e9curit\u00e9<\/b>\u00a0\u2014 a \u00e9t\u00e9 d\u00e9velopp\u00e9 par Microsoft. Sur le sch\u00e9ma se trouve le mod\u00e8le canonique SDLC, dont l'objectif principal est d'impliquer la s\u00e9curit\u00e9 \u00e0 chaque \u00e9tape du d\u00e9veloppement, des exigences jusqu'\u00e0 la sortie en production. Microsoft a r\u00e9alis\u00e9 qu'il y avait trop de bogues dans le produit, que leur nombre augmentait et qu'il fallait faire quelque chose \u00e0 ce sujet, et a propos\u00e9 cette approche, qui est devenue canonique.<\/p>\n

\"La
\n
\nLa s\u00e9curit\u00e9 des applications et le SSDL ne visent pas \u00e0 d\u00e9tecter les vuln\u00e9rabilit\u00e9s, comme on le pense souvent, mais \u00e0 pr\u00e9venir leur apparition. Au fil du temps, l'approche canonique de Microsoft a \u00e9t\u00e9 am\u00e9lior\u00e9e et d\u00e9velopp\u00e9e, offrant une immersion plus profonde et d\u00e9taill\u00e9e.<\/p>\n

\"La
\n
\nLe SDLC canonique est fortement d\u00e9taill\u00e9 dans diff\u00e9rentes m\u00e9thodologies - OpenSAMM, BSIMM, OWASP. Les m\u00e9thodologies diff\u00e8rent, mais dans l'ensemble, elles se ressemblent.<\/p>\n

Mod\u00e8le de Maturit\u00e9 pour la S\u00e9curit\u00e9 Int\u00e9gr\u00e9e<\/h3>\n

\nCe qui me convient le mieux BSIMM<\/b>\u00a0\u2014 Mod\u00e8le de Maturit\u00e9 pour la S\u00e9curit\u00e9 Int\u00e9gr\u00e9e<\/a><\/noindex>. La base de la m\u00e9thodologie consiste \u00e0 diviser le processus de s\u00e9curit\u00e9 des applications en 4 domaines : Gouvernance, Intelligence, Points de Contact SSDL et D\u00e9ploiement. Dans chaque domaine, il y a 12 pratiques, repr\u00e9sent\u00e9es sous forme de 112 activit\u00e9s.<\/p>\n

\"La
\n
\nChacune des 112 activit\u00e9s a 3 niveaux de maturit\u00e9<\/b>: d\u00e9butant, interm\u00e9diaire et avanc\u00e9. Les 12 pratiques peuvent \u00eatre \u00e9tudi\u00e9es par sections, en s\u00e9lectionnant les \u00e9l\u00e9ments importants pour vous, en apprenant comment les int\u00e9grer et en ajoutant progressivement des \u00e9l\u00e9ments, tels que l'analyse statique et dynamique du code ou la revue de code. Vous \u00e9laborez un plan et travaillez tranquillement dans le cadre de l'impl\u00e9mentation des activit\u00e9s choisies.<\/p>\n

Pourquoi DevSecOps<\/h2>\n

<\/p>\n

DevOps est un grand processus global, dans lequel il est n\u00e9cessaire de se soucier de la s\u00e9curit\u00e9.<\/p><\/blockquote>\n

\n\u00c0 l'origine DevOps<\/b><\/a><\/noindex> de pr\u00e9visions de s\u00e9curit\u00e9. En pratique, le nombre d'\u00e9quipes de s\u00e9curit\u00e9 \u00e9tait beaucoup plus faible qu'aujourd'hui, et elles intervenaient non pas en tant que participants au processus, mais comme un organe de contr\u00f4le et de supervision, qui impose des exigences et v\u00e9rifie la qualit\u00e9 du produit \u00e0 la fin de la sortie. C'est l'approche classique, o\u00f9 les \u00e9quipes de s\u00e9curit\u00e9 \u00e9taient s\u00e9par\u00e9es du d\u00e9veloppement et n'intervenaient pas dans le processus.<\/p>\n

\"La
\n
\nLe probl\u00e8me principal est que la cybers\u00e9curit\u00e9 est s\u00e9par\u00e9e du d\u00e9veloppement. Cela prend g\u00e9n\u00e9ralement la forme d'un certain cadre de cybers\u00e9curit\u00e9 comprenant 2-3 grands et co\u00fbteux outils. Une fois tous les six mois, le code source ou l'application \u00e0 v\u00e9rifier arrive, et une fois par an des tests de p\u00e9n\u00e9tration<\/a><\/noindex>. Tout cela conduit \u00e0 des retards dans le passage \u00e0 la production, et un grand nombre de vuln\u00e9rabilit\u00e9s issues des outils automatis\u00e9s s'accumulent sur les d\u00e9veloppeurs. Il est impossible de tout d\u00e9chiffrer et de corriger, car les r\u00e9sultats des six mois pr\u00e9c\u00e9dents n'ont m\u00eame pas \u00e9t\u00e9 analys\u00e9s, et une nouvelle s\u00e9rie arrive.<\/p>\n

Dans le cadre de notre travail, nous constations que la s\u00e9curit\u00e9 dans tous les secteurs et industries reconna\u00eet qu'il est temps de s'adapter et de s'aligner sur le d\u00e9veloppement dans un m\u00eame cycle - dans l'\u00a0Agile<\/b><\/a><\/noindex>. La paradigme DevSecOps s'int\u00e8gre parfaitement \u00e0 la m\u00e9thodologie de d\u00e9veloppement agile, \u00e0 l'impl\u00e9mentation, au soutien et \u00e0 la participation \u00e0 chaque version et it\u00e9ration.<\/p>\n

\"La
\n<\/p>\n

La transition vers DevSecOps<\/h2>\n

\nLe mot le plus important dans le cycle de vie du d\u00e9veloppement s\u00e9curis\u00e9 est \u00ab processus \u00bb<\/b>. Vous devez comprendre cela avant de penser \u00e0 acheter des outils.<\/p>\n

Il ne suffit pas d'int\u00e9grer des outils dans le processus DevOps \u2014 l'interaction et la compr\u00e9hension entre les participants au processus sont cruciales.<\/p><\/blockquote>\n

<\/p>\n

Les gens sont plus importants que les outils<\/h3>\n

\nSouvent, la planification d'un processus de d\u00e9veloppement s\u00e9curis\u00e9 commence par le choix et l'achat d'un outil, puis se termine par des tentatives d'int\u00e9gration de l'outil dans le processus existant, qui n'aboutissent souvent qu'\u00e0 des \u00e9checs. Cela conduit \u00e0 des cons\u00e9quences malheureuses, car chaque outil a ses sp\u00e9cificit\u00e9s et limitations.<\/p>\n

Un cas fr\u00e9quent est celui o\u00f9 le d\u00e9partement de s\u00e9curit\u00e9 choisit un bon outil co\u00fbteux avec de grandes capacit\u00e9s et vient voir les d\u00e9veloppeurs pour l'incorporer dans le processus. Mais cela ne fonctionne pas \u2014 le processus est construit de mani\u00e8re \u00e0 ce que les limitations de l'outil d\u00e9j\u00e0 achet\u00e9 ne s'int\u00e8grent pas dans la paradigme actuel.<\/p>\n

Commencez par d\u00e9crire quel r\u00e9sultat vous voulez et \u00e0 quoi ressemblera le processus. Cela aidera \u00e0 comprendre le r\u00f4le de l'outil et de la s\u00e9curit\u00e9 dans le processus.<\/p><\/blockquote>\n

<\/p>\n

Commencez par ce qui est d\u00e9j\u00e0 utilis\u00e9<\/h3>\n

\nAvant d'acheter des outils co\u00fbteux, regardez ce que vous avez d\u00e9j\u00e0. Chaque entreprise a des exigences de s\u00e9curit\u00e9 qui s'appliquent au d\u00e9veloppement, il y a des v\u00e9rifications, des pentests \u2014 pourquoi ne pas transformer tout cela en une forme compr\u00e9hensible et utile pour tous ?<\/p>\n

En g\u00e9n\u00e9ral, les exigences sont un long document qui tra\u00eene sur une \u00e9tag\u00e8re. Il y a eu un cas o\u00f9 nous sommes all\u00e9s dans une entreprise pour examiner les processus et avons demand\u00e9 \u00e0 voir les exigences de s\u00e9curit\u00e9 pour le logiciel. Le sp\u00e9cialiste responsable a cherch\u00e9 longtemps :<\/p>\n

\u2014 Maintenant, je sais qu'il y a quelque part dans mes notes le chemin vers ce document.<\/i><\/p>\n

Au final, nous avons obtenu le document apr\u00e8s une semaine.<\/p>\n

Pour les exigences, les v\u00e9rifications et autres, cr\u00e9ez une page, par exemple sur\u00a0Confluence<\/b>\u00a0\u2014 c'est pratique pour tout le monde.<\/p>\n

Il est plus facile de reformater ce qui existe d\u00e9j\u00e0 et de l'utiliser comme point de d\u00e9part.<\/p><\/blockquote>\n

<\/p>\n

Utilisez des Security Champions <\/h3>\n

\nEn g\u00e9n\u00e9ral, dans une entreprise moyenne, pour 100-200 d\u00e9veloppeurs, il y a un sp\u00e9cialiste de la s\u00e9curit\u00e9 qui remplit plusieurs fonctions et qui ne peut physiquement pas tout v\u00e9rifier. M\u00eame s'il fait de son mieux \u2014 il ne peut pas inspecter tout le code g\u00e9n\u00e9r\u00e9 par le d\u00e9veloppement tout seul. Pour de tels cas, le concept de Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Les Champions de la S\u00e9curit\u00e9 sont des personnes au sein de l'\u00e9quipe de d\u00e9veloppement qui se soucient de la s\u00e9curit\u00e9 de votre produit.<\/p><\/blockquote>\n

\"La
\n
\nLe Champion de la S\u00e9curit\u00e9 est un point d'entr\u00e9e dans l'\u00e9quipe de d\u00e9veloppement et un \u00e9vang\u00e9liste de la s\u00e9curit\u00e9 en une seule personne.<\/p>\n

En g\u00e9n\u00e9ral, lorsque quelqu'un de l'\u00e9quipe de d\u00e9veloppement vient avec un expert en s\u00e9curit\u00e9 et signale une erreur dans le code, il re\u00e7oit une r\u00e9ponse \u00e9tonn\u00e9e :<\/p>\n

\u2014 Et vous \u00eates qui ? Je vous vois pour la premi\u00e8re fois. Tout va bien pour moi \u2014 mon senior a valid\u00e9 lors de la revue de code, nous continuons !<\/i><\/p>\n

C'est une situation typique, car il y a beaucoup plus de confiance envers les seniors ou simplement les coll\u00e8gues avec qui le d\u00e9veloppeur interagit constamment au travail et lors des revues de code. Si c'est un Champion de la S\u00e9curit\u00e9 qui indique une erreur et ses cons\u00e9quences, sa parole aura plus de poids.<\/p>\n

Les d\u00e9veloppeurs connaissent \u00e9galement mieux leur code qu'un expert en s\u00e9curit\u00e9. Pour une personne ayant au minimum 5 projets dans un outil d'analyse statique, il est g\u00e9n\u00e9ralement difficile de se souvenir de toutes les nuances. Les Champions de la S\u00e9curit\u00e9 connaissent leur produit : ce qui interagit avec quoi et quoi surveiller en premier \u2014 ils sont plus efficaces.<\/p>\n

R\u00e9fl\u00e9chissez donc \u00e0 la possibilit\u00e9 d'impl\u00e9menter des Champions de la S\u00e9curit\u00e9 pour \u00e9largir l'influence de l'\u00e9quipe de s\u00e9curit\u00e9. Pour le champion lui-m\u00eame, c'est \u00e9galement b\u00e9n\u00e9fique : d\u00e9veloppement professionnel dans un nouveau domaine, \u00e9largissement des connaissances techniques, am\u00e9lioration des comp\u00e9tences techniques, manag\u00e9riales et de leadership, augmentation de la valeur sur le march\u00e9. C'est un \u00e9l\u00e9ment de l'ing\u00e9nierie sociale, vos \u00ab yeux \u00bb dans l'\u00e9quipe de d\u00e9veloppement.<\/p>\n

\u00c9tapes de test<\/h2>\n

\nLa r\u00e8gle des 20 sur 80<\/a><\/noindex>\u00a0stipule que 20 % des efforts g\u00e9n\u00e8rent 80 % des r\u00e9sultats. Ces 20 % concernent les pratiques d'analyse des applications qui peuvent et doivent \u00eatre automatis\u00e9es. Des exemples de telles activit\u00e9s sont l'analyse statique \u2014 SAST<\/b>, l'analyse dynamique \u2014 DAST,<\/b> et\u00a0le contr\u00f4le Open Source<\/b>. Je vais expliquer plus en d\u00e9tail les activit\u00e9s, ainsi que les outils, et les sp\u00e9cificit\u00e9s auxquelles nous faisons g\u00e9n\u00e9ralement face lors de leur int\u00e9gration dans le processus, et comment le faire correctement.<\/p>\n

\"La
\n<\/p>\n

Probl\u00e8mes principaux des outils<\/h3>\n

\nJe vais mettre en \u00e9vidence les probl\u00e8mes pertinents pour tous les outils qui n\u00e9cessitent une attention particuli\u00e8re. Je vais les examiner plus en d\u00e9tail pour ne pas avoir \u00e0 me r\u00e9p\u00e9ter.<\/p>\n

Longue dur\u00e9e d'analyse. <\/b>Si le temps \u00e9coul\u00e9 entre le commit et le passage en production est de 30 minutes pour tous les tests et la compilation, alors les v\u00e9rifications de s\u00e9curit\u00e9 prendront une journ\u00e9e. Personne ne fera tra\u00eener le processus. Prenez en compte cette sp\u00e9cificit\u00e9 et tirez-en des conclusions.<\/p>\n

Niveau \u00e9lev\u00e9 de faux n\u00e9gatifs ou de faux positifs. <\/b>Tous les produits sont diff\u00e9rents, chaque \u00e9quipe utilise diff\u00e9rents frameworks et son propre style de codage. Sur diff\u00e9rentes bases de code et technologies, les outils peuvent montrer un niveau vari\u00e9 de faux n\u00e9gatifs et de faux positifs. Donc, regardez ce qui est pertinent dans\u00a0votre<\/b> entreprise et pour vos<\/b> applications qui montrera un bon et fiable r\u00e9sultat.<\/p>\n

Pas d'int\u00e9grations avec les outils existants<\/b>. Examinez les outils en fonction des int\u00e9grations avec ce que vous utilisez d\u00e9j\u00e0. Par exemple, si vous utilisez Jenkins ou TeamCity, v\u00e9rifiez l'int\u00e9gration des outils pr\u00e9cis\u00e9ment avec ce logiciel, et non avec GitLab CI que vous n'utilisez pas.<\/p>\n

Absence ou complexit\u00e9 excessive de personnalisation. <\/b>Si un outil n'a pas d'API, \u00e0 quoi bon ? Tout ce qui peut \u00eatre fait dans l'interface doit \u00eatre accessible via l'API. Id\u00e9alement, l'outil devrait permettre de personnaliser les v\u00e9rifications.<\/p>\n

Pas de feuille de route pour le d\u00e9veloppement du produit. <\/b>Le d\u00e9veloppement ne stagne pas, nous utilisons toujours de nouveaux frameworks et fonctionnalit\u00e9s, et r\u00e9\u00e9crivons l'ancien code dans de nouveaux langages. Nous voulons \u00eatre s\u00fbrs que l'outil que nous ach\u00e8terons supportera de nouveaux frameworks et technologies. Il est donc important de savoir que le produit a une v\u00e9ritable et correcte feuille de route<\/a><\/noindex> de d\u00e9veloppement.<\/p>\n

Particularit\u00e9s du processus<\/h3>\n

\nEn plus des particularit\u00e9s des outils, prenez \u00e9galement en compte les sp\u00e9cificit\u00e9s du processus de d\u00e9veloppement. Par exemple, g\u00eaner le d\u00e9veloppement est une erreur classique. Voyons quelles autres particularit\u00e9s doivent \u00eatre prises en compte et sur quoi l'\u00e9quipe de s\u00e9curit\u00e9 doit se concentrer.<\/p>\n

Pour ne pas retarder les d\u00e9lais de d\u00e9veloppement et de mise en production, cr\u00e9ez diff\u00e9rentes r\u00e8gles<\/b> et diff\u00e9rents show stoppers\u00a0<\/b>\u2014 des crit\u00e8res d'arr\u00eat du processus de compilation en cas de vuln\u00e9rabilit\u00e9s \u2014 pour diff\u00e9rents environnements<\/b>. Par exemple, nous comprenons que la branche actuelle est destin\u00e9e \u00e0 un environnement de d\u00e9veloppement ou UAT, donc nous ne devons pas arr\u00eater et ne pas dire :<\/p>\n

\u2014 Vous avez ici des vuln\u00e9rabilit\u00e9s, vous n'irez nulle part !<\/i><\/p>\n

\u00c0 ce stade, il est important d'informer les d\u00e9veloppeurs qu'il existe des probl\u00e8mes de s\u00e9curit\u00e9 auxquels il convient de pr\u00eater attention.<\/p>\n

La pr\u00e9sence de vuln\u00e9rabilit\u00e9s n'est pas un obstacle \u00e0 des tests ult\u00e9rieurs.<\/b>: manuel, int\u00e9gration ou manuel. D'un autre c\u00f4t\u00e9, nous devons somehow am\u00e9liorer la s\u00e9curit\u00e9 du produit, et pour que les d\u00e9veloppeurs ne n\u00e9gligent pas ce que la s\u00e9curit\u00e9 trouve. C'est pourquoi parfois nous proc\u00e9dons ainsi : sur le stand, lorsque cela est publi\u00e9 dans l'environnement de d\u00e9veloppement, nous informons simplement le d\u00e9veloppement :<\/p>\n

\u2014 Les gars, vous avez des probl\u00e8mes, veuillez y pr\u00eater attention.<\/i><\/p>\n

\u00c0 l'\u00e9tape UAT, nous montrons \u00e0 nouveau les avertissements sur les vuln\u00e9rabilit\u00e9s, et \u00e0 l'\u00e9tape de lancement, nous disons :<\/p>\n

\u2014 Les gars, nous avons averti plusieurs fois, vous n'avez rien fait \u2014 nous ne vous laisserons pas sortir avec \u00e7a.<\/i><\/p>\n

En parlant de code et de dynamique, il faut montrer et avertir uniquement au sujet des vuln\u00e9rabilit\u00e9s des fonctionnalit\u00e9s et du code qui viennent d'\u00eatre \u00e9crits dans cette fonctionnalit\u00e9. Si le d\u00e9veloppeur a d\u00e9plac\u00e9 un bouton de 3 pixels et que nous lui disons qu'il a une injection SQL et qu'il doit donc corriger cela imm\u00e9diatement \u2014 c'est incorrect. Regardez uniquement ce qui a \u00e9t\u00e9 \u00e9crit maintenant, et le changement qui arrive dans l'application.<\/p>\n

Supposons que nous ayons un certain d\u00e9faut fonctionnel \u2014 comment l'application ne doit pas fonctionner : l'argent n'est pas transf\u00e9r\u00e9, en cliquant sur le bouton, il n'y a pas de redirection vers la page suivante ou le produit ne se charge pas. Les d\u00e9fauts de s\u00e9curit\u00e9<\/b>\u00a0\u2014 ce sont des d\u00e9fauts similaires, mais non pas dans le cadre du fonctionnement de l'application, mais de la s\u00e9curit\u00e9. <\/p>\n

Tous les probl\u00e8mes de qualit\u00e9 logicielle ne sont pas des probl\u00e8mes de s\u00e9curit\u00e9. Mais tous les probl\u00e8mes de s\u00e9curit\u00e9 sont li\u00e9s \u00e0 la qualit\u00e9 du logiciel. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\n\u00c9tant donn\u00e9 que toutes les vuln\u00e9rabilit\u00e9s sont des d\u00e9fauts similaires, elles doivent se trouver l\u00e0 o\u00f9 se trouvent tous les d\u00e9fauts de d\u00e9veloppement. Donc oubliez les rapports et les PDF effrayants que personne ne lit.<\/p>\n

\"La
\n
\nQuand je travaillais dans une entreprise de d\u00e9veloppement, j'ai re\u00e7u un rapport d'outils d'analyse statique. Je l'ai ouvert, j'ai \u00e9t\u00e9 horrifi\u00e9, j'ai pr\u00e9par\u00e9 un caf\u00e9, j'ai feuillet\u00e9 350 pages, je l'ai ferm\u00e9 et je suis retourn\u00e9 travailler. Les grands rapports sont des rapports morts<\/b>. Ils ne vont g\u00e9n\u00e9ralement nulle part, les emails sont supprim\u00e9s, oubli\u00e9s, perdus ou les affaires disent qu'elles acceptent les risques.<\/p>\n

Que faire ? Les d\u00e9fauts confirm\u00e9s que nous avons trouv\u00e9s sont simplement transform\u00e9s en un format adapt\u00e9 au d\u00e9veloppement, par exemple en les rassemblant dans le backlog de Jira. Nous priorisons et corrigeons les d\u00e9fauts selon leur priorit\u00e9, en parall\u00e8le avec les d\u00e9fauts fonctionnels et ceux des tests.<\/p>\n

Analyse statique - SAST<\/h2>\n

\nIl s'agit d'une analyse du code \u00e0 la recherche de vuln\u00e9rabilit\u00e9s.<\/b>, mais ce n'est pas la m\u00eame chose que SonarQube. Nous v\u00e9rifions non seulement selon des motifs ou un style. Lors de l'analyse, plusieurs approches sont appliqu\u00e9es : selon l'arbre des vuln\u00e9rabilit\u00e9s, par\u00a0DataFlow<\/a><\/noindex>, par l'analyse des fichiers de configuration. C'est tout ce qui concerne directement le code.<\/p>\n

Avantages de l'approche<\/b>: d\u00e9tection des vuln\u00e9rabilit\u00e9s dans le code \u00e0 un stade pr\u00e9coce du d\u00e9veloppement<\/b>, lorsqu'il n'y a pas encore de stands et d'outils pr\u00eats, et\u00a0possibilit\u00e9 de scan incr\u00e9mental<\/b>: scanner la partie du code qui a chang\u00e9 et uniquement la fonctionnalit\u00e9 sur laquelle nous travaillons actuellement, ce qui r\u00e9duit le temps de scan.<\/p>\n

Inconv\u00e9nients<\/b>\u00a0\u2014 c'est l'absence de support pour les langages n\u00e9cessaires.<\/p>\n

Int\u00e9grations n\u00e9cessaires, <\/b>qui, \u00e0 mon avis subjectif, doivent \u00eatre dans les outils :<\/p>\n