Post Syndicated from Bozho original https://techblog.bozho.net/how-to-create-secure-software-dont-blink-talk/
Last week Acronis (famous for their TrueImage) organized a conference in Sofia about cybersecurity for developers and I was invited to give a talk.
It’s always hard to pick a topic for a talk on a developer conference that is not too narrowly focused – if you choose something too high level, you can be uesless to the audience and seen as a “bullshitter”; if you pick something too specific, half of the audience may be bored because it is not their area of work.
So I chose the middle ground – an overview talk with as much specifics as possible in it. I tried to tell interesting stories of security vulnerabilities to illustrate my points. The talk is split in several parts:
- Purpose of attacks
- Front-end vulnerabilities (examples and best practices)
- Back-end vulnerabilities (examples and best practices)
- Infrastructure vulnerabilities (examples and best practices)
- Human factor vulnerabilities (examples and best practices)
- Thoughts on how this fits into the bigger picture of software security
You can watch the 30 minutes video here:
The point is – security is hard and there are a million things to watch for and a million things that can go wrong. You should minimize risk by knowing and following as much best practices as possible. And you should not assume you are secure, as even the best companies make rookie mistakes.
The security mindset, which is partly formalized by secure coding practices, is at the core of having a secure software. Asking yourself constantly “what could go wrong” will make software more secure. It is a whole other topic of how to make all software more secure, not just the ones we are creating, but it is less technical and goes through the topics public policies, financial incentives to invest in security and so on.
For technical people it’s important to know how to make a focused effort to make a system more secure. And to apply what we know, because we may know a lot and postpone it for “some other sprint”.
And as a person from the audience asked me – is not blinking really the way? Of course not, that effort won’t be justified. But if we cover as much of the risks as possible, that will give us some time to blink.
The post How to create secure software? Don’t blink! [talk] appeared first on Bozho's tech blog.