triggering automated OWASP check on succesful build


So, I'm trying to set up a simple build configuration that uses the OWASP ZAP proxy to check all pages in a site after it has been built. This configuration should be triggered after a succesful build in one of its dependencies. The only parameter this OWASP check needs is the name of the site it needs to check, the rest is already functional. 

So, lazy as I am, I created a build configuration that has an entire root project with a few dozen sub projects as a snapshot dependency. The build configuration of these sub projects have a parameter that should override the OWASP site name with the one that is provided by the sub project, using the reverse.dep.*.<property_name> construction.

In theory this OWASP check should fire after a succesful build of one of these snapshot dependencies. Each snapshot dependency has a parameter that passes its siteName property to reverse.dep.*.siteName, so the siteName parameter of the OWASP should be set correctly.

This doesn't happen though. The OWASP check isn't started after a succesful build, and the reverse.dep.*.siteName isn't filled. I have the feeling I'm missing something very obvious here. 

Comment actions Permalink

Hello Sander,

A reverse.dep.*.* parameter is used to change a parameter inside of a dependency build. Let us say you have a build A which depends on build B; when you start A, B is also triggered (unless a matching successful build was found). Now, if you would set up a reverse.dep.B.<some_parameter> on A, B`s some_parameter would be updated correspondingly. See the details here:

In this case, the parameters would have to flow other way around (from dependency to dependent build). For this sake, you may use dep.*.* parameter (but the issue with your workflow is that you would have to check on the dependent build level which dependency was actually executed). Details are here:
Further on, simply setting up a build as a dependency will not cause the dependent build to start when a dependency is done (unless a corresponding trigger is set up, like Finish Build trigger or VCS Trigger which listens for the changes on snapshot dependencies). 

With all of the above in mind, I would like to suggest two alternative approaches.


For the first one, OWASP check can be saved as a meta-runner step ( This will allow you to save OWASP configuration as a custom step you may add as a last step for the configurations with ease. This effect can also be achieved by creating a build template out of OWASP check configuration and then basing existing site builds on it (both are mixing normally separate logic into a single build, though). 


The second one is cleaner but requires some additional setup. You can use Finish Build trigger ( in order to start OWASP check whenever any of the site builds are done; this will also mean that property would be populated for the OWASP build instance. (and would contain something like "Finish Build Trigger; ChainProject / Configuration, build #80" where ChainProject / C is the project and build configuration ID and #80 is the build number, respectively). With this, you could run the below REST API request to get the build instance:


It will fetch the build with build number 80 under ChainProject_Configuration and return a list of build parameters with the values as defined by the end of build. You can then get the siteName out of the configuration and use it correspondingly in the check.
Some general details on REST API usage are available here:


I hope that the above helps; for any questions or concerns, please let me know and I will gladly assist.

Comment actions Permalink

Hi Fedor,

The REST API option sounds like the more powerful feature, although maybe the new conditional build step feature that appeared in the latest Teamcity version might come in handy if we add the OWASP check as steps in the build. But I'll fiddle with the REST API for now, it seems to me like a fun way to create interesting builds.

I'll let you know how this goes :D


Please sign in to leave a comment.