Running security tests as a part of your CI pipeline allows you to provide better and more relevant feedback to developers as quickly as possible (also known as the “Shift Left paradigm”/”DevSecOps” methodology).
Those slides are from a session at DevOpsDays TLV 2017 - how to use OWASP Zap to create valuable dynamic security tests. In those slide, I'm showing how we added those test to one of our open source project - Tweek (https://github.com/soluto/tweek)
28. What Zap does?
● Inspecting request and response
● Run passive scan rules:
○ Cookies misconfiguration
○ Security HTTP Headers
○ Mixed Content
○ And many more
52. Let’s use Docker
● Tweek is designed as a multi-container app
● Every microservice has an offical Docker image
● Tweek uses Docker-native CI (Codefresh)
● Test suites also run as docker containers
● Zap has an official docker image
87. Useful links
● Pull Request – adding security tests to Tweek
● Malicious Pull Request – The one show a few slides above
● Demo repo – Adding security tests to vulnerable app - Juice Shop
● Blog Post – how I added security tests to Tweek
@omerlh
@yshayy
Thank you for having me
Are you running tests in you CI? How? Why Can it be easy?
Who heard on the breach
Who heard without the breack
It will happen to you
Run tests in CI
What is security tests – tests that can test your code and how we did it
Talk about what is OWASP- non profit, wide and popular
Say this is hackin tool, I’ll explain in a minute how
I’m going to show the manual approach
Add Tweek Postman
2015
False positive filtering
Glue ease integration of security tools into CI
How?
Glue can take many security tools
<click>
This is just a sample, already more than 15 supported
And let you define filters <click> and reporters <click>
Filters let you filter issues raised by the tool, report control on how you visualize them
So you can write your own filters and reporters and they will apply to any new seuciryt tool that you will add to glue