When security teams find vulnerabilities they typically describe them to developers using words, for example in a PDF or via a bug tracker. Unfortunately in many cases developers may lack the security knowledge to understand or reproduce the problem. Also security teams often use tools which the developers do not have access to or have no experience with. And developers sometime fail to solve the underlying problems.
While it will still be necessary to describe vulnerabilities, Zest allows security teams to create reproducible test cases which they can then share with the developers. These test cases can be used by the developers to reproduce the issues and test their fixes.
Ideally security engineers will be able to use their favourite security tools to create Zest scripts while developers will be able to rerun those scripts using the tools that they are familiar with.
In this case the sequence of events could be:
- The security team discovers a vulnerability using specialist security tools
- They use those tools to create a Zest script which reproduces the problem
- They hand the script over to the developer
- The developer adjusts the script to match their local environment
- They run the script and see the vulnerability
- They fix the vulnerability
- They rerun the script to check that the vulnerability is fixed
- The fix is applied to the system that the security team is testing
- The security team rerun the script as an initial check
- They then perform any manual testing they think is necessary
Note that the developers could also include the script in the regression tests to make sure that it doesnt reoccur.
- Related links
- Zest Overview