If you didn’t have the chance to be at the AppSecEU 2017 conference in Belfast or you didn’t make it to my talk there, here’s the official recording:
OWASP Juice Shop is a “shooting star” among broken web applications. To make sure it does not end as a “one-hit wonder”, the project embraces principles and techniques that enhance its sustainability, e.g. Clean Code, TDD, CI/CD, Quality Metrics and Mutation Testing.
In this session you will see how
– a complete and reliable test suite eliminates the “fear of change”
– automation is a key to increased productivity – even for small open source projects
– free-for-open-source SaaS tools can improve your development process
Where is light, there is shadow! You will also learn
– about some limitations in the automation processes
– why some 3rd party services had to be dropped
If the Internet gods are with us, we will even perform a production release of OWASP Juice Shop during the session!
You can find the original HTML5 slide deck at http://bkimminich.github.io/juice-shop/appseceu_2017.html. The slightly less fancy PDF-version is available on SlideShare:
During the AppSecEU 2017 conference I was interviewed by Mark Miller for the Less than 10 Minutes Series of the OWASP 24/7 Podcast:
I recommend to subscribe to the podcast, even though Mark deliberately butchers the project’s name as “Juice Box” in this and at least one other episode…
“Good names – for classes, functions and variables alike – are a simple but powerful way of creating understandable code. Understandable code gives you improved maintainability. Bad names on the other hand are a heavy burden that the whole development team has to carry. Bad names hide the authors intent, leave false clues and often obscure the meaning of code. And all this calls for a certain action that developers should never have to apply lightly: The Batman Mode™. Forced into detailed detective work, developers try to find the meaning and correct pronunciation of class names like GyqfaChBppResDao. They investigate the difference between intended and entrenched meaning of variable names like ssd, sd and cd. They argue with code-villains about Encodings, Hungarian Notation and if an interface name should start with an I or not. Putting a little bit of extra care into name choices and following some simple concepts such as the “Scope Rule” and “Newspaper Metaphor” can have huge positive effects on your code. By choosing Supernames™ your team might even prevent the Dawn of Legacy Code for its own project!
You can find the original presentation slides here: http://batman-v-supername.kimminich.de
Recording of the presentation that I gave for the Netherlands OWASP Chapter Meeting on 22nd September 2016 at the Radboud University in Nijmegen.
“Comments are – at best – a necessary evil” (Uncle Bob, “Clean Code”) – Over the years I gathered quite a collection of examples for bad code comments. The most precious gems among them I would like to share with you. You will listen in on developer monologues and dialogues, try to analyze cryptic bylines, experience different levels of UnCamelCasing(tm) skill and fight your way through a redundant, useless and misleading inline thicket. You will also hear about well-meant tools and plugins that should not even exist if the motto “No Comment!” would be valued as it should be.
You can find the original presentation slides here: http://no-comment.kimminich.de
Some comments on // No Comment! from Clean Code Days 2015:
Juice Shop is an intentionally insecure web application that is available on GitHub under MIT license. You might ask now: “Why would anyone create a broken application on purpose?”
Basically it is a controlled environment to do web security related exercises in or demonstrate certain vulnerability types. Possible use cases for Juice Shop include:
- security awareness trainings for business and IT staff
- pentesting trainings for security staff (or students)
- application security trainings for software developers
- target dummy for open source and commercial security scanners
A typical follow-up question might now be: “Why create such an application when there are already dozens of those available?”
I hope that by now you’ve gone like: “Hm, sounds interesting! Where can I get it and how do I make it run?”
That’s an easy one: Just visit http://bkimminich.github.io/juice-shop and flip through the info deck provided there. It contains the links to the source code on GitHub and links to installation instructions in all kinds of flavors:
- Local installation and execution with node.js
- Running as a fully prepared Docker container
- Using a pre-packaged ZIP (on Windows machines only)
- Deploying it on an Amazon EC2 instance
Should the FAQ and Readme not be sufficient to get Juice Shop running in your environment, feel free to ask a question in the GitterIM chat channel or open an issue on GitHub!
If you just want to have a look, you can also visit the demo instance on Heroku: https://juice-shop.herokuapp.com
Tools for unit testing, building applications, analyzing software quality and planning release scopes are an essential aspect of modern software development. With GitHub and “pluggable” external services there are lots of options to move these aspects into “the Cloud”. For open source projects this is a viable alternative to on-premise solutions. In these slides I present the CI lifecycle of some of my recent projects hosted on GitHub where I tried to integrate modern tools (e.g. Gradle, npm, bower) and external services (e.g. Travis-CI, Code Climate, Coveralls, HuBoard, AmazonSNS, NMA). I am not affiliated with any of the providers mentioned, so this is no marketing slide deck! Instead, you will hopefully learn about some enhancements to try out with your own GitHub projects!
You can view or download the PDF version on Slideshare or you can view the original HTML-based presentation here: