DevSecOps and Developers

DZone 's Guide to

DevSecOps and Developers

Developers need to consider their productivity, the OWASP Top 10, education, processes, and best practices.

· DevOps Zone ·
Free Resource

Image title

To understand the current and future state of DevSecOps, we gathered insights from 29 IT professionals in 27 companies. We asked them, "What do developers need to keep in mind with regards to DevSecOps?" Here's what they told us:


  • The personal benefit for developers is that it means less work for them. DevOps working with security spend 50% less time going back to address security issues. Developers trained in cybersecurity are rare therefore more valuable. We will pay and reward those people. The more they can learn about and work with security to develop products with security in mind is more valuable.
  • Security is critical to the business. Incorporating security throughout the development and deployment processes is less disruptive and gives better results than ignoring security until the end.
  • The more valuable, successful, and efficient developers care about how their applications are deployed. Most developers need to think about how their apps will be deployed. Develop in an environment that mirrors the real world production and deployment environment. Not hardcoding secrets in code using K8s secret management. Everything is just done correctly. The earlier you pay attention to security the less likely security breaches will occur down the road.
  • Security is your friend! Seriously! Developers are the true sentries of product security, as not introducing accidental weaknesses in the first place is always much better than even the fastest hotfix process later on. DevSecOps practices that make developers into security champions — automatically and with minimal extra effort — are a huge win for your customers and your company and will actually make your job easier and smoother. Security can be just like documentation or any other supporting function of development — once it’s integrated into the software delivery life cycle it starts to feel like it belongs there.
  • DevSecOps can be viewed as a shift in time and place that eventually results in reducing the net costs of having secure products and infrastructure. Developers and Operations Engineers value velocity, quality, and performance. With a good DevSecOps implementation, security is enabling the business to achieve these same shared goals, with earlier, seamless and more cost-efficient integration of security.
  • Whether you are within a DevOps team or a dev team, security should be one of your top two considerations. If you’re not delivering secure software, you are doing yourself and your customers a disservice. It’s your job to deliver code and a product that will meet the market need and the market needs security.


  • If you are starting with an organization without DevSecOps, know that security is everyone’s responsibility, don’t expect someone to pick up the slack if you are doing something in an irresponsible way. Review the OWASP Top 10 and stay abreast of what’s going on. Use breaches as learning opportunities. Integrate security throughout the SDLC, deploy, planning. Being secure is just as important as being bug-free. Take it seriously for your own development as a professional. Keeping a good mind about security goes hand-in-hand with other development best practices. Malfunctions of software are an avenue for attack. Doing DevOps well equates to doing security well. If you level up your software development skills, you will improve your security. Think about adversarial models around bugs and security to create more robust systems in general.
  • Start with OWASP to learn security best practices. Top 10 list is a good intro to web application security. Understand how your code can be vulnerable and how to secure it. Learn how to defend against attackers through e-learning, and read free resources.
  • You have a responsibility to develop secure code. There is too much of a mess out there already. Start getting involved in local chapter meetings, working groups, and training sessions. Look at something simple like OWASP Top 10 and see how you can implement that in your own practice.

Education/Best Practices

  • 1) Mentality change if you want the opportunity to automate security you need to follow a process and embrace it to deliver trusted computing experience. It’s part of writing good code. 2) As soon as you embrace it you’ve opened up a whole world of automation and can turn the security team to educate the rest of the dev team. 3) Really, really learning the best practices, getting metrics, improving, getting the playbook for how other teams should do it.
  • Know what the CI/CD pipeline looks like, start with the simple building blocks and then deeper discussions on tools, guidelines of how stuff works. There is a lot of cross-references to other important articles.
  • It all starts with education – reading and hands-on trials. Once you do hands-on trials it gives you a sense of what the outcomes look like. Keep sufficient bandwidth to learn hands-on and keep your Dev and DevOps in practice and in shape.
  • Require ongoing education and training. Budget time to evolve and learn skills. Companies need to give individuals time to develop and learn. Think about the evolving world, threats, technology, and budget time to learn and act on them. A front end developer needs to learn how to prevent SQL injection attacks.
  • 1) Start with the easy things, invest in some code scanning or RASP tools to get some protection. Something is better than nothing. 2) Secure coding is not taught at any university. If developers really care they need to take it upon themselves to learn how to code securely. It may be uncompensated time to understand SQL injection, code injection, and the OWASP Top 10.
  • “Everyone is responsible for security” is the mantra for DevSecOps.
  • The team must be trained to consider security implications throughout the entire delivery process, from the inclusion of security considerations while refining user stories and tasks, through writing and testing the code, and embedding security testing in the continuous integration build process. They should adopt static code analysis tools and techniques to uncover issues as they write the code, include vulnerability testing as part of the build and deployment processes, and ensure that they monitor the test results and fix defects as soon as they are detected. A user story should only be considered "done" if it has been assessed for security issues, which must include a consideration of the final production environment, not just internal development and testing environments. Dynamic security testing and penetration testing must extend into production, to ensure that the software continues to be secure after it has been deployed.


  • Know that security professionals are not trying to slow the process down and be unreasonable.
  • Include security colleagues earlier. Do not wait for a crisis. DevOps doesn’t care about security until a breach happens. Build empathy and relationships with your security counterparts. Security has to be willing to partner.
  • Developers themselves need to shift to a DevSecOps mindset, operating with security in mind throughout development rather than treating it as an afterthought and another team’s problem. Currently, many enterprises feature multi-development teams with the authority to upgrade applications on their own – developers in this position must be mindful of the connections and protocols they’re using and the security implications. Developers should play a role in ensuring that their enterprise’s security solution adapts to changes in the application it protects, such as any increases in scale or changes in functionality that arise.
  • Developers should understand secure coding is their responsibility; it is no longer a fix to run a security scan that is run in pre-production environments. They have to ensure that their code is continuously scanned for security vulnerabilities, ensure they use packages that are not vulnerable (and include the packages in scans) and have security audits enabled in their development IDE to make secure coding a mindset than an activity.
  • Users are hostile. The internet is hostile. Other services are hostile. Security is quality, and availability is security. That sounds like a lot because it is. You need defensive code practices, penetration testing, threat models, game days, coordinated disclosure, not to mention the actual implementation details for your language and specific domain.
  • Security, like quality assurance, needs to be integral to the process. Security, like quality assurance, needs to be integral to the application development process. And just like how developers have to collaborate with the QA engineers we must also collaborate with security professionals.
  • 1) Developers need to think about the different components of their applications as being security-relevant or not. They need to trust DevSecOps to help them choose the right tools to build those security-relevant components. 2) Developers don’t roll their own encryption. Even if they could, it’s undifferentiated heavy-lifting. Similarly, security is often hampered by having every DevOps team build their own solutions to security components. It’s time to standardize some tooling and build best practices to secure it. 3) Bottom line: Unless security is your IP, don’t waste cycles trying to invent it.
  • Be aware of the data you’re leveraging in your environments. Security is a shared responsibility and that starts with the end user asking themselves if they think sensitive data is being used. DevSecOps should have a DevOps initiative.
  • 1) One of the great benefits of DevSecOps is its “democratizing” effect on security, but there’s still a need for security subject matter experts. Blended teams allow everyone to contribute to security, but there are some topics – cryptography, secrets management, and secure coding, to name just a few – that are difficult to master and easy to foul up. Developers should pay special attention to the handling of unencrypted and untokenized sensitive data (secrets) within the code, both during code design and peer reviews – even scanning code before checking in changes using standard security scanners available as IDE-plugins. Part of the art of assembling an effective DevSecOps culture involves building the right mixture of skills on your team. 2) The biggest thing that not only developers need to deal with is the changes that are happening and in some cases the speed of those changes. This might include processes, tooling and even personal knowledge. Part of this shift left is that everyone now has to be at least familiar with all aspects, this might include network security, application security, IT, performance, etc. Often this can be overwhelming to a developer and leads to cutting corners.
  • Remember that security needs to be part of the process. DevOps isn’t enough anymore, which is the entire reason “Sec” has been squeezed right in the middle. Development teams need to keep that in mind and accept this is a collaborative effort for everyone’s benefit. We’ve been so focused on speed and velocity of software delivery that security has gotten lost, but when everyone works together, teams will be able to figure out how to make security work at the speed of DevOps.

Here's who provided their insights:

devops, devsecops, education, owasp top 10, security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}