Catégories
Start-up et applications

AppSec vs DevSecOps, et ce que cela signifie pour les développeurs

La sécurité des applications traditionnelle est différente de deux manières principales de ce qui est désormais connu sous le nom de DevSecOps. Premièrement, les éditeurs de logiciels modernes intègrent la sécurité des applications dans leurs pipelines DevOps, de sorte que la sécurité fait partie du flux. Deuxièmement, il s’agit également de l’intégration de DevOps dans la sécurité des applications.

Patrick Carey, qui dirige la stratégie produit au sein du groupe Software Integrity chez Synopsys, fournisseur de solutions de sécurité, a expliqué ces différences. En intégrant la sécurité des applications dans votre environnement de développement automatisé, a-t-il déclaré, la sécurité «est initiée par des événements, plutôt que nécessairement par une phase où quelqu'un en bout de ligne, dont le travail est de s'assurer que vous n'avez pas raté et codé une vulnérabilité », fait le test.

De l'autre côté de cette médaille, l'intégration de DevOps dans AppSec élimine les portes créées par les outils de test DAST ou de stylo traditionnels, créant à la place des garde-corps qui permettent à l'équipe d'avancer avec un frottement relativement faible mais de rester sur la bonne voie. Dans le système traditionnel de réussite-échec à clé, «si vous échouez, vous obtenez votre rapport de vulnérabilité qui vient de dire que vous savez qu'il y avait un tas de vulnérabilités, mais oh, au fait, nous ne pouvons pas vous dire exactement où elles se trouvent dans votre code; votre développeur va devoir résoudre ce problème. "

Intégrer DevOps dans AppSec, a-t-il poursuivi, signifie que vous devez disposer d'outils qui peuvent être utilisés plus tôt dans le flux de travail de développement, dans les IDE des développeurs, mais aussi dans leurs systèmes de gestion de code et leurs outils de construction. Carey a souligné que ce qui est vraiment important, c'est de faire une analyse basée sur les risques pour déterminer les bons types de tests à exécuter sur des parties spécifiques du code, au bon moment. «C'est ce qui le rendra vraiment compatible avec un flux DevOps haute vitesse.»

Carey a déclaré que l'état de l'industrie aujourd'hui consiste davantage à intégrer AppSec dans DevOps, en intégrant des outils traditionnels dans le pipeline. Mais, a-t-il souligné, comme les outils AppSec traditionnels n’étaient pas conçus pour ce modèle, les équipes se heurtent à trois problèmes principaux.

Le premier est ce qu'il a appelé la friction du pipeline, où un outil AppSec traditionnel, une fois connecté à un pipeline CI / CD, pourrait prendre deux heures pour effectuer une analyse, tandis que le pipeline de construction s'exécute généralement sur un bout en bout de trois minutes. construire. «Il existe donc une discordance inhérente en termes de débit, de sorte que les équipes se heurteront à l'endroit où elles mettront en place le script pour appeler une analyse, puis elles constateront que cela paralyse immédiatement leur pipeline. C'est un problème auquel les équipes sont confrontées et qui peut bloquer de nombreuses initiatives DevSecOps », a-t-il expliqué.

Le deuxième problème, a-t-il noté, est la lenteur de l'adoption par les développeurs des outils de test traditionnels en général. «On m'a demandé une fois, vous savez quoi, ce que les développeurs recherchent dans les outils de sécurité et mon commentaire immédiat était, eh bien, ils ne le sont pas», a-t-il déclaré. «Ils essaient généralement d'éviter (les outils de test) comme la peste», car ils reconnaissent que les outils ont toujours causé des frictions.

Enfin, il y a le problème de la surcharge de vulnérabilité, a-t-il déclaré. "Si vous connaissez les résultats des outils AppSec traditionnels, ils peuvent produire un taux d'incidents assez élevé de faux positifs", a-t-il déclaré. Choses que l'outil les drapeaux comme étant potentiellement des vulnérabilités, mais qui après enquête ne sont pas de «véritables tueurs» pour les équipes en raison du temps perdu.

«Si une friction de pipeline consiste en fait à paralyser la partie automatisée de DevOps, la surcharge de vulnérabilité paralyse la partie humaine de la charge de travail des développeurs», a expliqué Carey.

Pour amener les développeurs à adopter la sécurité dans leur travail, Carey a déclaré que les organisations sont en train de passer d'un modèle qui l'impose d'en haut, «s'éloignant du bâton et plus vers la carotte».

Il est important de permettre aux développeurs de faire leur travail de sécurité dans leurs IDE et autres outils DevOps. «Vous devez leur apporter la sécurité des applications», a déclaré Carey. «Ils ne veulent pas passer à l’interface utilisateur de quelqu'un d’autre, puis aller chercher dans cette interface pour faire l’analyse de sécurité, puis revenir à l’EDI. Vous devez les rencontrer là où ils sont; autant que possible, vous devez leur rendre l’analyse AppSec invisible. »

Synopsys s'attaque au problème avec son propre outil Code Sight, qui est un plug-in gratuit à l'EDI qui se connecte aux outils d'analyse statique et d'analyse de la composition logicielle de l'entreprise et à ses capacités d'apprentissage en ligne, qui offrent une sorte de formation professionnelle pour les développeurs n'ayant pas été formés à la sécurité logicielle.

Code Sight identifie les vulnérabilités et les bogues pendant le codage par le développeur. Il peut effectuer une analyse efficace en arrière-plan, et il mesure la quantité de CPU qu’il consomme pour ne pas être perçu comme un ralentissement des machines des développeurs.

«Montrons-leur simplement les problèmes de sécurité dont ils ont besoin pour résoudre le problème afin de ne pas souligner le fait qu'il s'agit de SCA et de SaaS, mais« Lorsque vous travaillez sur ce projet, voici les problèmes de sécurité que nous constatons. «  Et Code Sight peut orienter les développeurs vers la ligne de code qui pose problème, leur offrir des conseils de remédiation et même leur permettre de suivre un court cours via l'e-learning afin qu'ils puissent se familiariser avec ce type de vulnérabilité et comment y remédier. "

"Encore une fois", a déclaré Carey, "il essaie de le rendre transparent et intégré dans leur environnement existant plutôt que d'attendre une autre solution avec laquelle ils doivent interagir séparément."

Contenu fourni par SD Times et Synopsys

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *