To the extent possible under law, Red Hat, Inc. has dedicated all copyright to any code or configuration snippets included in this work to the public domain worldwide, pursuant to the CC0 Public Domain Dedication. This software is distributed without any warranty. Learn more.

Security is from Mars, Developers are from Venus…...or ARE they?

It is a tale as old as time. Developers and security personnel view each other with suspicion. The perception is that a vast gulf of understanding and ability lies between the two camps. “They can’t possibly understand what it is to do my job!” is a surprisingly common statement tossed about. Both groups blame the other for being the source of all of their ills. It has been well-known that fixing security bugs early in the development lifecycle not only helps eliminate exposure to potential vulnerabilities, but it also saves time, effort, and money. Once a defect escapes into production it can be very costly to remediate.

Years of siloing and specialization have driven deep wedges between these two critical groups. Both teams have the same goal: to enable the business. They just take slightly different paths to get there and have different expertise and focus. In the last few decades we’ve all been forced to work more closely together, with movements like Agile reminding everyone that we’re all ultimately there to serve the business and the best interest of our customers. Today, with the overwhelming drive to move to a DevOps model, to get features and functionality out into the hands of our customers faster, we must work better together to make the whole organization succeed.

Through this DevOps shift in mindset (Development and Operations working more closely on building, deploying, and maintaining software), both groups have influenced each other’s thinking. Security has started to embrace the benefits of things like iterative releases and continuous deployments, while our coder-counterparts have expanded their test-driven development methods to include more automation of security test cases and have become more mindful of things like the OWASP Top 10 (the Open Web Application Security Project). We are truly on the brink of a DevSecOps arena where we can have fruitful collaboration from the groups that are behind the engine that drives our respective companies. Those that can embrace this exciting new world are poised to reap the benefits.

Red Hat Product Security is pleased to partner with our friends over in the Red Hat Developer Program. Our peers there are driving innovation in the open source development communities and bringing open source to a new generation of software engineers. It is breathtaking to see the collaboration and ideas that are emerging in this space. We’re also equally pleased that security is not just an afterthought for them. Developing and composing software that considers “security by design” from the earliest stages of the development lifecycle helps projects move faster while delivering innovative and secure solutions. They have recently kicked-off a new site topic that focuses on secure programing and we expect it to be a great resource within the development community: Secure Programming at the Red Hat Developer Program.

In this dedicated space of our developer portal you’ll find a wealth of resources to help coders code with security in mind. You’ll find blogs from noted luminaries. You’ll find defensive coding guides, and other technical materials that will explain how to avoid common coding flaws that could develop into future software vulnerabilities. You’ll also be able to directly engage with Red Hat Developers and other open source communities. This is a great time to establish that partnership and “reach across the aisle” to each other. So whether you are interested in being a better software engineer and writing more secure code, or are looking to advocate for these techniques, Red Hat has a fantastic set of resources to help guide you toward a more secure future!

Category

Secure

Tags

Security-Vulnerabilities

About The Author

Christopher Robinson

Reduces Cumberplexity while working with Brain Scientists performing Rocket Surgery

Comments

R. Hinton.

Community LeaderGuru8345 points

This would be a highly welcome pursuit. Anything worthwhile is generally not built rapidly, but over time, so it's understood this pursuit will be long term. Many Red Hat customers have to live implementing solutions with tight mandatory security controls such as "STIG" security controls ( https://access.redhat.com/discussions/2899931 and it's a misconception to thing STIG is only something government entities use, because it's wider than that).

Looking forward to seeing how the chips fall with this pursuit, and perhaps contributing if possible.

I very much approve of using the DevSecOps terminology, as that is the most appropriate way to describe the mindset and methodology to achieve solutions that work successfully. FSI space needs to embrace it.