Why Place Security (Partly) in the Hands of Developers

By empowering developers to expand the work they perform related to security, enterprises can ensure that security is front and center from the start.

Guest Commentary, Guest Commentary

July 24, 2018

4 Min Read

Developers’ jobs no longer start and stop with writing code. The DevOps movement, combined with the demands created by cloud-native technologies like containers and serverless, has significantly expanded the roles that developers play in the IT organization.

This change means not only that developers must assume greater responsibility for releasing secure code that is easy to manage and scale; it also places new expectations upon developers from a security standpoint.

How can enterprises ensure that their developers actually have the security skills required to help their teams create and deploy secure code? Beyond writing the code itself, what else should developers be doing to assist with security needs?

Let’s explore those questions with today’s cloud-native demands in mind.

How developer roles are changing

In years past, developers wrote application code. They then handed it off to other teams to test it, build it, deploy it, monitor it and secure it.

That practice has started to change at most organizations. One of the big reasons why is the advent of DevOps. DevOps encourages constant collaboration between developers and IT Ops teams. The driving idea is that when developers and IT Ops are in constant communication, they are better positioned to understand each others’ pain points and address them.

DevOps has spawned similar movements, too, such as QAOps, which emphasizes the integration of QA teams into the rest of the DevOps workflow, and DevSecOps, which integrates security testing and operations into the rest of the software delivery cycle.

Meanwhile, the emergence of new, cloud-native technologies has placed new responsibilities upon developers. In order to write applications that perform stably and securely in complex environments like containers and serverless platforms, developers need a deep understanding of the particular requirements of those environments. It’s no longer enough to write code and assume that IT Ops will be able to deploy it wherever needed; developers must be aware of deployment infrastructure and goals, and tailor their work accordingly.

Empowering developers to improve security

That’s how the work of the typical enterprise developer is changing in general. Now, let’s focus on security in particular, and how developers can expand the role they play in security operations in order to benefit the enterprise as a whole.

The first big step in involving developers in security is to embrace the DevSecOps model (described above). DevSecOps means not only requiring security engineers to work more closely with developers and IT Ops, but also increasing the expertise of developers from a security perspective.

Do your developers understand the particular security challenges that arise from the deployment technologies your organization uses? Are they aware of the security strategies, such as multi-layered defenses and whitelisting, that define best practices for IT security today? Do they understand the different types of security threats that may impact their applications?
If the answers to these questions are no, then it’s time to educate your developers about security. This is the only way to achieve a complete DevSecOps workflow.

At the same time, developers can assume a greater role in security by accepting more responsibility for security ownership. In other words, when a vulnerability happens, developers should be held accountable in addition to security engineers. If developers write the code, they must be responsible when the code contains security flaws. Organizations should use tools that integrate vulnerability and compliance checks directly into build pipelines, check every build, and allow enforcement of minimum security baselines. Even though security engineers should also be testing the code and monitoring it in production for problems, the burden of owning security should not be on them alone.

Finally, consider asking your developers to play a greater role in writing and executing the security tests and monitoring rules that the security team deploys. Even if security testing and monitoring is not the primary responsibility of developers, having developers play a hand in these processes will help to keep them more aware of the state of security for each application they write. It may also benefit your security team by providing additional perspective and coding expertise.

I’m not here to argue that developers should assume sole ownership of security, or that they should replace dedicated security teams. Any enterprise that has a large IT team should continue to employ security specialists.

Still, the fact is that we are living in a complex, cloud-native world where security engineers alone cannot adequately find and address all security risks. Developers, too, have an important role to play in security. By empowering developers to expand the work they perform related to security, enterprises can streamline security operations and ensure that security concerns are front and center from the very start of the application delivery pipeline.

John Morello is chief technology officer for Twistlock.

About the Author(s)

Guest Commentary

Guest Commentary

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT professionals in a meaningful way. We publish Guest Commentaries from IT practitioners, industry analysts, technology evangelists, and researchers in the field. We are focusing on four main topics: cloud computing; DevOps; data and analytics; and IT leadership and career development. We aim to offer objective, practical advice to our audience on those topics from people who have deep experience in these topics and know the ropes. Guest Commentaries must be vendor neutral. We don't publish articles that promote the writer's company or product.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights