Страна: New Zealand
Kim is the founder of BinaryMist Ltd and PurpleTeam-Labs, he is a published author of many information security books specifically targeting Software Engineers, DevOps Engineers and Architects. He has hosted and been a guest on many podcasts involving information security, including being a host for Software Engineering Radio.
He has written over 100 blog posts covering software engineering and information security topics. Spoken at many international conferences and run many workshops helping Software Engineers understand and improve their information security.
Kim Pioneered the InfoSecNZ Slack. Served as the OWASP New Zealand Chapter Lead for Christchurch for eight years, and co-pioneered the Christchurch Hacker Conference. Kim continues to consult with Software Engineering Teams on a daily basis to improve their security, quality and reduce their time to delivery.
Purple Teaming With OWASP PurpleTeam
PurpleTeam is a Developer focussed security regression testing CLI and SaaS targeting Web applications and APIs. The CLI is specifically targeted at sitting within your build pipelines but can also be run manually. The SaaS that does the security testing of your applications and APIs can be deployed anywhere.
Kim will briefly discuss the four-year journey that has brought PurpleTeam from a proof of concept (PoC) to a production-ready Developer first security regression testing CLI and SaaS.
An overview of the NodeJS micro-services with many features allowing a Build User (DevSecOps practitioner) to customize their Test Runs without having to write any tests by simply configuring a Job file.
Allowing multiple options to deal with false/true positives.
Setting alert thresholds in multiple places and for multiple testers (app-tester, tls-tester, server-tester) allows the Build User to define what constitutes a successful or failed Test Run.
# Why would I want it in my build pipelines?
In this session, Kim will discuss the problems that PurpleTeam solves, such as training the Build User with advice and tips on security defects as you fix the defects that PurpleTeam highlights.
As well as the huge cost savings of finding and fixing your application and infrastructure security defects early (as you’re introducing them) as opposed to late (weeks or months later with external penetration testing) or not at all.
# OK, I want it, how do we/I set it up?
Kim will walk you through all of the components and how to get them set up and configured
# Great, but what do the workflows look like and how do I use them?
Let’s walk through the different ways PurpleTeam can be run and utilized, such as:
* Running PurpleTeam stand-alone (with UI)
* Running PurpleTeam from within your pipelines as a spawned subprocess (headless: without UI)
* Running all of the PurpleTeam components, including debugging each and every one of them if and when the need arises