Was in der heutigen Zeit schon normal ist Regression Testing, aber eben nur auf den Environment und entsprechend nur auf den IST-Zustand dieser Systeme. Soweit so gut, was nicht praktiziert wird ist die Tatsache das man zwar vielfach auf CI/CD Pipelines Security Test durchführt aber eben keine Regression Test.

Aber genau das ist die Krux, wir fixen im agilen und nicht agilen Projekten selbstverständlich auch Security Issues, führen hier aber keine Regression eben auch auf die Security Issues durch. Ein fast fataler Ansatz, denn heutzutage ist die Sicherheit der Systeme genau darauf angewiesen.

Dieses Thema ist recht spannend, denn bisher kaum beachtet trotzdem eines der wichtigsten Aspekte die man in der heutigen agilen Entwicklung beachten muss. Gerade das Thema Hacking und Erpressung von Informationen sollte allgemein bekannt sein:

 

Die Entwickler und die Community von Owasp ZAP haben das Thema der security regression testing aufgenommenn und wollen dies in einem Google Summer of Code aufbröseln. 

Using the ZAP Desktop

The user can select specific alerts they wish to retest by selecting them in the Alerts Tab, or via clicking on the retest menu option and choosing the required alerts from the Retest dialog that appears(they can filter the alerts on the basis of the sites). They can choose to then click on retest and see the retest results in the dialog itself, or they can click on the “Generate Retest Plan” button in order to generate a retest plan, which could be used in the future. They can also load a previous retest plan from the retest dialog via the use of the “Load Retest Plan” button. Note that a retest plan can only be generated when the session is in memory, and that once a session is persisted, the alerts present in the session cant be retested anymore. However,a stretch goal of my project would be to allow the generation of retest plans from saved sessions as well.

 

Eine wissenschaftliche Betrachtung von Security Regression Testing findet man hier: