This article originally appeared in Information Week.
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 as a whole.
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? And 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 now 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 also 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 (which was 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 security 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 have an important role to play in security, too. 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.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
AWS Fargate Security: Runtime Defense with Twistlock 2.5Read the Blog
Cloud Native Forensics: Security Incident Response in Twistlock 2.5Read the Blog
Announcing Twistlock 2.5: GA Release NotesRead the Blog
GitOps 101: What Is GitOps, and Why Would You Use It?Read the Blog
DevSecOps Learning Resources: How to Learn to Do DevSecOpsRead the Blog