DEV Community

Software Engineering Unlocked

Episode 14: What developers should know about security with Troy Hunt

Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.

 

Have a look at Michaela's Code Review Workshops

Links:

Show notes

We start by talking about data breaches, and Troy tells me that he gets information about data breaches several times a day. More data on breaches than he can actually handle. 

When I asked him if people somehow got a data breach fatigue, he said, well, companies are nowadays more judged on how they handle the data breach than on whether they have one or not. 

So, it’s important that companies handle those well. Not like the negative examples from Uber and Equifax. 

Troy explains to me that from his experience he sees that often lawyers give the guidance to not react or publicly share information about a data breach. But that’s not a good strategy, Troy says. Because the ones that break into the website, they feel anonymous, so they will not keep it a secrete. They do not fear the consequences. But the companies will, so they should proactively manage data breaches. 

Then we talk about data privacy and Troy’s approach to sharing his personal data online. I have seen Troy in front of the camera with his son, for example, so I wonder if he has any restrictions on what he shares. Which things does he keep private?

Troy says, data privacy is very personal and that there is no right or wrong answer. Everybody should do what feels right to them, and also evaluate on a case per case basis.

After discussing this, we hop over to good security practices. I’m in particular interested in what Troy thinks software engineers should know about security, data privacy, etc. He tells me that the best thing is to start with the OWASP Top 10 web application security risks. 

But then, I tell Troy that, sometimes in my code review workshops, software engineers tell me that they do not need to look for security vulnerabilities or risks, because, that’s handled by others. By experts. So, I ask Troy if he encounters similar mindsets in his workshops, and how he handles such pushbacks. 

Troy tells me that he made a whole career out of this attitude and that he encounters this quite often. He thinks it has to do with complacency. He says that security is something that we all have to stay on top of and that’s relevant for everybody. Also, implementing good practices, like making code resilient to SQL injections does not take any more effort. Contrary, practices that help you make your code more resilient can save you time and money in the long run. 

Another area I ask Troy about is what he advises organizations to do to make sure they implement security throughout the whole development lifecycle. How can organizations get the new DevSecOps lifecycle right?

Troy also tells me that education, for example in form of workshops, such as his security workshops or also my code review workshop, is an excellent way to make sure developers are aware of best practices, and follow good and proven strategies. Another thing is automated analysis. 

After talking a bit about regulations and their effects – or non-effects- to enforce data privacy, we switch gears and I talk with Troy about how he started his career as a security expert and thought leaders.

I want to know, what started all, and did he foresee his success back then. 

Well, turns out Troy started writing his blog over four years before he made the move to self-employment. He says it took a lot of effort and time to build his online identity, but he knew that this gives him freedom and peace of mind in many cases.

He thought about, what if he does not like his job anymore, or the employer wants to get rid of him.

So he started blogging and building an online portfolio. And, four years later, it happened. Troy wasn’t happy anymore at his current job, and the company made a few roles redundant. So, he took the chance to start his own business and never looked back.

It was really inspiring to talk to Troy. I hope you enjoy this episode as much as I did.

Best,

McKayla.

Episode source