Webinar: Are you ready to put the "Sec" in DevOps?
Anyone who has worked in software production is likely aware of the tension that can arise when it comes to factoring in security, mostly between developers and the security specialists scrutinizing their code.
In the old days, it wasn't uncommon for the development team to ship code as late as possible, deliberately shortening the window in which the security gurus could check for vulnerabilities - after all, this delayed releases if anything happened to be wrong, and there was already the desire to move on and start building the next awesome feature. However, this had an eventual negative impact, as when the code was eventually checked -- sometimes after an external breach had already occurred -- the code would still bounce back to the developers, their software babies were still called ugly by the security team, and they'd have to drop everything to hotfix code they'd last touched months ago.
This dysfunction continues today, but there is a huge problem: there is much more code being developed, and society is at far greater risk in the event of data breaches occurring. We no longer have time to keep fighting this ancient battle, and in 2020, it's time we all joined the same side against the bad guys.
We must get to a stage where security is seen as a shared responsibility across the entire organization, and throughout the SDLC. This is certainly possible when you commit to a fully-fledged, highly supportive DevSecOps environment. What's more, when you ignite the security fire in your development team with the right training and tools, they are a powerful force in not only squashing bugs, but taking the load off the security specialists who have been spread too thin, for too long.
I'd love you to watch one of my latest webinars, How to put the "Sec" in DevOps:
This was part of the AllTheTalks 24-hour summit event, and it takes a deep look into:
- Why older development methodologies made security best practice so much harder
- Why DevSecOps is the latest game-changer in stopping common security vulnerabilities
- What security as a shared responsibility looks like in an organization
- How you can empower developers to ship secure code with confidence, without sacrificing what they love (hint: it's building awesome features).
See you there!
Matias Madou, Ph.D.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Related Articles We Recommend
Related Articles We Recommend
Dive into onto our latest secure coding insights on the blog.
Our extensive resource library aims to empower the human approach to secure coding upskilling.
Get the latest research on developer-driven security
Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.
Webinar: Are you ready to put the "Sec" in DevOps?
Anyone who has worked in software production is likely aware of the tension that can arise when it comes to factoring in security, mostly between developers and the security specialists scrutinizing their code.
In the old days, it wasn't uncommon for the development team to ship code as late as possible, deliberately shortening the window in which the security gurus could check for vulnerabilities - after all, this delayed releases if anything happened to be wrong, and there was already the desire to move on and start building the next awesome feature. However, this had an eventual negative impact, as when the code was eventually checked -- sometimes after an external breach had already occurred -- the code would still bounce back to the developers, their software babies were still called ugly by the security team, and they'd have to drop everything to hotfix code they'd last touched months ago.
This dysfunction continues today, but there is a huge problem: there is much more code being developed, and society is at far greater risk in the event of data breaches occurring. We no longer have time to keep fighting this ancient battle, and in 2020, it's time we all joined the same side against the bad guys.
We must get to a stage where security is seen as a shared responsibility across the entire organization, and throughout the SDLC. This is certainly possible when you commit to a fully-fledged, highly supportive DevSecOps environment. What's more, when you ignite the security fire in your development team with the right training and tools, they are a powerful force in not only squashing bugs, but taking the load off the security specialists who have been spread too thin, for too long.
I'd love you to watch one of my latest webinars, How to put the "Sec" in DevOps:
This was part of the AllTheTalks 24-hour summit event, and it takes a deep look into:
- Why older development methodologies made security best practice so much harder
- Why DevSecOps is the latest game-changer in stopping common security vulnerabilities
- What security as a shared responsibility looks like in an organization
- How you can empower developers to ship secure code with confidence, without sacrificing what they love (hint: it's building awesome features).
See you there!
