This is the overview and outline for a chapter in our upcoming book, "Epic Failures in DevSecOps". Each chapter is a unique voice, telling us a story about an epic failure that has been encountered as part of a personal DevOps/DevSecOps transformation.
Would you like to proofread a chapter and give us feedback? If so, look at the bottom right of this page and confirm you'd like to be a proofreader. (If you don't see the box, leave a comment.) This will put you on the "keep me up to date on the project" list, and we'll reach out when ready for your help. There are going to be eight chapters.Keep an eye out for the others. -- Mark Miller, Executive Editor
This is the story of David vs Goliath, or how a few security people can make an impact. I was the senior person in charge of securing this application and it was quickly becoming overwhelming. It was one of the largest and most cutting-edge projects I've ever been on. It started with one squad, one microservice and a bunch of support people. Within months there were 15 microservices, countless node modules and a team of over 120 people.
Code was being produced at a stunning rate and new endpoints popped up left right and center. The challenge was not just the sheer team output but keeping up with changes to existing code. How can a team ensure that what was secure in the past, is still secure today?
Challenges we wanted to solve were, security unit tests couldn't cover most of the concerns and we didn't want to scatter security tests into each microservice, which would be difficult to maintain for us and security champions. Additionally, we wanted to be able to cover testing OTP, HTTP headers, rate limiting and many other things across environments. And we wanted to do this in a central repository.
Additionally, we wanted to find a way to get security test coverage. E.g how can we ensure that once we have tested an endpoint, it is always in a secure state.
The goal was to automate security integration tests and hand it over to the development team to run and maintain. Lot's of time was spent on creating a very good solution but in the end, it was not used. Lesson learned, no matter how cool or revolutionary you think a solution is, if you solve for yourself, and don't get the team and dedicated champions involved from the very beginning, it's not going to be a success.
One of the industry's foremost experts in Application Security, Agile Security, and DevSecOps, Stefan Streichsbier has been enabling secure application delivery for the FSI, Government, Software, Education and Infrastructure sectors in both Europe and Asia, for the past 14 years.
Stefan began his career in Security Assurance in 2003 and has since performed intrusive security testing across hundreds of corporate networks and business-critical applications. Afterward, Stefan has been focused on secure application development for web and mobile applications, using his skills as both a developer and security expert to champion Source Code Analysis and Secure Application Coding best practice. Recently, Stefan has been dedicated to enabling organizations to rapidly deliver applications without creating a security bottleneck through application security programs and DevSecOps implementations.
Stefan is extremely well known in the security industry ‚Äì having co-authored the A7700 technical standard for web application security, the first certifiable norm in the EU area for web application security. Stefan is also a regular on the speaking circuit, appearing at high profile events such as DevOpsDays, Agile Singapore, and GovWare. He is also a frequent speaker at local Singaporean security Meet-Up groups and the founder of DevSecOps Singapore. Stefan is also one of the core organizers of DevOpsDays Singapore, DevOpsDays Jakarta, DevOpsDays Bangkok and DevSecCon Asia.
Want to be a proofreader for the book? Fill in your email address in the box on the right. (If you don't see the box, leave a comment). We'll get back to you within the next three weeks with a chapter for your review.