On peut industrialiser la chose aussi avec ZAP, par exemple avec le plugin Jenkins qui va bien. Il est possible d'avoir une chaine qui fait par exemple (en 1 ou plusieurs Job):
Git Push
Tests unitaires
Analyse des failles de sécu des dépendances (plugin jenkins Check Dependancies ), et rapport dans Sonar
Génération du livrable
Déploiement de l'application dans un serveur de test (et initialisation du jeu de données)
Exécutions des tests d'intégration (Avec du Selenium, SOAPUI, Jmeter...). Si on est malin, on capture via un proxy ce qui se passe entre les tests orienté métier et ce qui ce passe coté http. Par exemple pour ré-injecter une capture Selenium vers du Jmeter pour mesurer des perfs.
Exécution de test ZAPproxy, soit de manière basique, soit, c'est encore mieux, en y ré-injectant ce qui a été enregistré coté test-fonctionnel.
Les résultats des tests de ZAPproxy sont envoyé dans Sonar également.
Perso, je suis partisant de tests courts à chaque commit/push (tests U, intégration avec jeux réduit) et de garder le ZAProxy+intégration complete + bench plutot 1 ou 2 fois par jours, car les déploiements /test peuvent être assez long avec en plus la reconstruction des jeux de données.
[^] # Re: VS ZAP et le reste ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . En réponse à la dépêche Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web. Évalué à 2.
On peut industrialiser la chose aussi avec ZAP, par exemple avec le plugin Jenkins qui va bien. Il est possible d'avoir une chaine qui fait par exemple (en 1 ou plusieurs Job):
Perso, je suis partisant de tests courts à chaque commit/push (tests U, intégration avec jeux réduit) et de garder le ZAProxy+intégration complete + bench plutot 1 ou 2 fois par jours, car les déploiements /test peuvent être assez long avec en plus la reconstruction des jeux de données.