So I Did This Podcast…
I’ve been a long listener to podcasts for a while. My personal favorites of all time have got to be the Ted Radio Hour, Revisionist History, Freakonomics Radio, 30 for 30 Podcast and Real Sci-Fi with Wade and Willy. Of course, I’ve had a few others on my list that over time I just couldn’t take anymore, so I dropped them.
Recently, I was on the receiving end of a special invite to be a guest of Matt Watson of Stackify. I have been a fan of Matt for a couple of years now. I think his company is really impressive and doing more than their share of content marketing to educate the world in the land of APM and Java/.Net communities. Almost every day, I get Chrome notification about a new blog or post on the Stackify website. If you don’t read it already, I strongly recommend you do. When the invite came to be a part of his podcast, it was a no brainer in my mind.
Matt asked me to talk shop about Application Security in his developer podcast series called “Developer Things”. You can hear my appearance if you click on this link. Let me start off by saying, Matt’s a great interviewer. He was able to keep the conversation flowing. He’s perpetually ready to have follow-on questions and he’s just a “pro” about doing research.
It was great to talk shop. Since coming over to Contrast, I haven’t really had the chance to talk about why I made the move and why I’m such a believer in our product. In my last few years at Blackboard, I was super focused on Continuous Integration and quality oriented engineering. I wanted to figure out ways to make telemetry of our applications in development and production into sources of truth when it came to making tough decisions about refactoring and improving code quality.
Contrast has been my platform for the last 3+ years to help developers write more secure code and get immediate feedback on commit. When we learn about vulnerabilities and bugs in production, which we more than often do, our Protect product is there to help customers responsibly address their threats in real-time so they can go back and make the “right refactor” and not the “rushed refactor”.
What was cool about doing this podcast, is that for those who know me, my roots are in Performance Engineering, which is Matt’s wheelhouse as well. There are so many parallels between Performance Engineering and Application Security.
The number one parallel in my mind is measurement. I’m specifically referring to measuring code in the context of anti-patterns. As a performance engineer, my number one tool was a profiler. Profilers were great because they were measuring sticks for code. They could tell me how much something cost and could help me visualize an anti-patterns in a simple call stack.
Security profilers, like Contrast Assess essentially do the same thing. The difference is that we don’t focus on frequency and timings. We focus on design principals and anti-patterns in the code. We overlay evidence of security research in the 3rd party libraries that we often use as developers. We can show weaknesses in your code after simply executing it, as well as in the library code you leverage to simplify your development.
There are a ton of other parallels with performance engineering, but probably the 2nd most relevant parallel is that when code can’t scale it’s a bug. When a vulnerability is detected in code, it too is a bug. Performance issues and security threats aren’t black magic. They happen because the logic in one’s code is flawed and exposes a defect. So many developers see performance and security as “not their job”.
So probably the 3rd parallel between performance engineering and application security, is the frustration practitioners face when trying to educate and empower their developer communities. In 2006, AWS launched it’s EC2, cloud compute footprint. I personally didn’t jump on the AWS bandwagon until 2009/2010 timeframe. When I did, I found that my software colleagues using EC2 were very focused on performance. The reason why is so obvious. Every poor design decision or performance anti-pattern, subsequently cost more money.
The same can be said about security. I don’t want every developer to go through a breach in the same vein as a performance issue. There has to be some kind of experience to drive incentives…or so I think.
More to come later. I just wanted to put some thoughts down and share the journey. Keep in touch friends!