Integrating with Gitlab CI/CD
Gitlab CI/CD is a great way to run SIPVicious PRO automatically and regularly against your target systems. To do this, you will need the following components:
- a Docker image with SIPVicious PRO
.gitlab-ci.ymlfile which defines a test plan
The following is an example of a
default: image: registry.gitlab.com/.../svpro-autotests timeout: 30m stages: - test svpro-tests: stage: test script: - sipvicious rtp bleed udp://demo.sipvicious.pro -p35000-40000 --duration 30s - sipvicious sip crack digestleak udp://demo.sipvicious.pro:5060 -e 2000 - sipvicious sip crack online udp://demo.sipvicious.pro:5060 -e 1000 -r 1000-2000 - sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060
The Docker image defined in the second line of the yaml file contains a copy of the SIPVicious PRO executable and is built from the svpro-docker example on Github. An example of a docker-compose file can be found on our Gitlab example repository which can serve as a starting point for your custom image and push it to your private Docker registry.
The Gitlab CI configuration in the example runs the following security tests:
When a security issue is detected by any of these tools, SIPVicious PRO returns an exit code of 40 which would be detected by the Gitlab CI and cause the pipeline to fail. Other errors will also generate a non-zero exit code, thus stopping execution and alerting the teams involved.
WarningWhen building your SIPVicious PRO docker image, do make sure that it stays private. When pushed to publicly accessible Docker registries, your copy of SIPVicious PRO is likely to be leaked.
For a more complete example, please visit the public Gitlab repository and observe the pipelines that are run periodically here: https://gitlab.com/sipviciouspro/ci-cd-demos/demo-server-monitor/-/pipelines. This CI/CD environment is regularly testing our demo server and making sure that it is still vulnerable. It serves as a practical example of how SIPVicious PRO can be used within a CI/CD pipeline with individual bash scripts for each test.
Heads upIn the case of the Demo Server Monitor on Gitlab, the scripts are making sure that the VoIP and WebRTC system stays vulnerable. You will probably need to do the opposite!