Attributes of a Positive DevSecOps Culture

DZone 's Guide to

Attributes of a Positive DevSecOps Culture

Security becomes ingrained throughout the organization, there's more collaboration, and metrics are used of to determine progress.

· DevOps Zone ·
Free Resource

To understand the current and future state of DevSecOps, we gathered insights from 29 IT professionals in 27 companies. We asked them, "What are the attributes of a positive DevSecOps culture?" Here's what they told us:

Image title

Security is Ingrained

  • Developers think more about security the same way they think about deployment when writing software. With DevSecOps, developers don’t do insecure things. Developers are more likely to want to talk to security to come up with good designs. Security is involved with engineering to get feedback and identify better ways of doing things. Security works as partners with developers to develop features that are secure. Consider risks versus business value.
  • Infusing the mentality of proactive security across every team. Develop, design, and test in a sandbox. Ops working with security in mind. Product management is thinking about security. Automating whenever possible. Humans don’t scale. Look for ways to leverage automation to complete low-value, repetitive tasks. Take a bite-sized approach. Pick a few key goals and celebrate small victories to keep people excited and everyone is able to see the progress being made.
  • As container use matures, enterprises benefitting from deploying containers within CI/CD pipelines are recognizing the importance of securing their application container development environments from start to finish. Whereas before, DevOps may not have added security measures until the middle of development, there’s now a cultural movement toward DevSecOps, in which security and DevOps teams work together to “shift left:” implementing built-in security measures from the beginning of the development lifecycle. At the same time, enterprises are advancing container technology beyond proving grounds and into production. These live, containerized production environments must be secured, necessitating a “shift right” as well. As a result, DevOps team cultures are now commonly shifting to a DevSecOps mindset, embracing security solutions specifically designed to safeguard container environments across the full build-ship-run application lifecycle.
  • A positive DevOps culture is one where security is an enabler versus a blocker to shipping good things. Generally, folks want to be secure until being secure is difficult. Make important security things easy. Thread security throughout your processes. It’s not a central security team’s job to make sure developers write good code. Developers should want to write secure code as part of being excellent in their roles. Learning about secure coding, secure operations, secure deployment, etc. should be integral to success in a role, and not nice-to-have knowledge.
  • 1) A drive for excellence. Security is critical to modern applications but is often invisible to the customer and other developers. Without a culture of excellence, teams may be pressured to quickly implement a solution that’s less secure rather than take the time to implement a secure and maintainable solution. 2) Extensive automation - With automated deployment processes, security testing can be performed all along the development pipeline. Automation ensures that security requirements and testing are always performed consistently. Manual security processes insert delays and often motivate people to find ways around them.
  • Every step of the DevOps chain must be thoroughly applying security best practices.
  • 1) Get speed and agility. Automated security decisions are being made with the speed at scale. 2) Fostering a culture of security. Changing the security culture with more awareness into all phases of the SDLC. Developers make more considerations around risk versus value.
  • 1) You have to care. You have to know you live in a world where actors and nation states are breaking into everything they can – the democratization of malicious actors. It’s incumbent on DevSecOps to be aware of how easy it is to break in. 2) Think about how to make security part of the process up front and into every line of code and automation. It’s everyone’s responsibility.
  • When everyone on the team sees security as their own responsibility, and not as someone else’s problem, you have a positive DevSecOps culture. This is expressed by security being part of every user story completion criteria up-front, by security testing being an integral part of the continuous integration pipeline and production environment, and through executive support and understanding that security must not be compromised to reduce time to market.

Image title


  • Partnership
  • Developers, Ops, SecOps get into a steady state. If tools are going to slow down delivery velocity, they will not be integrated into the pipelines. Have tools that are not high touch, that doesn’t need to be managed on a daily basis. DevOps cannot deal with products that require a lot of management. Everyone is concerned about security. You cannot ignore security.
  • Collaboration - people have to behave differently especially security people. Many people are new to security. Guardrails should not be speedbumps. Move from the department of “no,” to an attitude of this is challenging how do we help you do that securely. When security teams are developing the right attitude the dev teams and SREs will work together to improve the process.
  • A positive DevSecOps culture is when there is trust and shared responsibility of security outcomes. This culture should be governed by shared Security KPIs and driven by bringing in the right people who recognize the value and interconnected nature of DevSecOps, with automation at its foundation. Another key attribute of a positive DevSecOps culture is one where security is always striving to reduce friction in the agile DevOps processes.
  • A positive DevSecOps culture is built upon collaboration and mutual trust. Without these two characteristics, the development and security teams continue to operate in the respective silos, unaware or unconcerned with the needs and goals of their counterparts. This kind of separation leads to the model of “throwing stuff over the wall” and fosters resentment among the team who may feel devalued or stymied by their counterparts. By contrast, teams that work closely together to achieve common business goals are more apt to leverage their unique strengths and avoid traditional conflicts.
  • 1) Integration of development, security, and operations is best initiated via collaboration and common goals between developers, security teams and operations staff. 2) Shared goals, a collaborative work environment with openness and transparency from the earliest stages of development. 3) “Shameless retrospectives” allowing for developers, security staff and SREs to learn from each other’s mistakes. 4) Continuous training and enablement to initiate and reinforce the culture change. One way to think of security is as an expression of quality: does the system do what it’s supposed to (and not do what it shouldn’t)? The engineering practices that lead to good quality also lead to good security. The more you see security woven into a team’s day-to-day engineering work, rather than considered a one-off, the more successful the team’s security efforts are likely to be.
  • 1) Implementing a successful DevSecOps strategy requires a team of players in different positions, including development, IT operations and security. It’s a collaborative and inclusive movement that not only encourages individuals to work with other teams and step outside the traditional channels, but also embraces automation and orchestration so they can work together more easily. 2) However, security has traditionally been viewed as a barrier to velocity and innovation, working separately from the development and IT teams due to cultural, and sometimes language, differences. Just as working individually isn’t a successful strategy on the field, it won’t work in DevSecOps, and the team you put together can either carry you to success or get stuck along the way and fall short of expectations.

Image title


  • You begin making data-driven decisions around risk. Security would have a meeting to show how the exploit works. With DevSecOps, you no longer have to host a meeting, you just focus on the data about how the infection happened and give guidance and an update on how to fix the problem. Let’s not have a meeting. Here’s the problem, here’s the solution, just keep going.
  • The key attributes of a positive DevSecOps culture are to measure security at each stage of the engineering lifecycle. As the saying goes, if you cannot measure something, you cannot improve it. Having a security-first design culture among all the stakeholders helps identify and prevent issues early.
  • A positive DevSecOps culture is one where: 1) Everyone from executives to project teams is on the same page regarding the importance of security. 2) There is a focus on partnerships rather than blame. 3) The security workload is balanced across multiple teams. 4) There are clear security driven metrics (MTTR, time to move from dev to prod, vulnerability escape rate). 5) Software is designed for security (fail-safe defaults, defense in depth). 6) Security teams are invited to post-mortems. 7) Business interests are driven through the SDLC via compliance and risk requirements.
  • Besides the obvious ones - strong collaboration across departments, a willingness to learn, and alignment on shared goals - it’s important to develop a culture of visibility. Security practices don’t belong in the dark any more than development practices do. In the same way development culture has massively benefitted from shared code repositories, pipeline as code, code reviews, and sprint demos, security teams should build both formal and informal channels for sharing ideas, methods, and implementations with their colleagues in both security and development. Security teams should also leverage a GitOps mindset to maintain their security tests and automation, benefitting from the collaboration and iterative improvements made possible by bringing security “out of the basement.”


  • It’s more than incorporating a security or open source scan that’s part of the CI/CD tooling. Recognize you can automate non-functional requirements. If you have to do a threat model, you can do that manually just Include this as part of the process. If you wait until the end the things you uncover you want to fix security problems early so you don’t have to rearchitect or entirely change the way you approach the problem. Include the steps in the process every step of the way, threat modeling, scans, make the entire team security smart while they are moving forward.
  • It is wrong to think culture is most important. The most important part is technology. Without technology, a security culture cannot exist. Our culture is a culture of networking. It goes away without technology. We build culture as we are creating the internet and things connected to it. We live in a networking culture. We created a culture of object-oriented programming. If we take that away, we’ll go back to Cobalt and have a revolt. If testing takes many hours what kind of rapid development will you have? None. Culture is built on top of existing technology. You have to start with the right technology to test at speed for rapid delivery. If a test takes eight hours you can’t have rapid releases. You cannot build a culture of communication if you do not have communication devices. Manual code review is not a replacement for automated testing. This myth is why DevSecOps is still in the trough of disillusionment. Don’t be mistaken by the myth. Culture is a follower, not the lead.
  • Faster speed, higher quality. It took a while to convince doubters to test automatically in a CI/CD pipeline. Not all testing can be fully automated but most of the stupid mistakes can be found much faster and manual deep penetration testing becomes more interesting. Now automated tools flag bad code or new open source vulnerabilities. Application testing can focus on more sophisticated tests.
  • Ensure true separation of duties and integrity. InfoSec embedded with data security and good processes for the architect and development team to develop good code.
  • We’re seeing the collapse of the technology stack dealing with infrastructure. The movement toward DevSecOps encourages organizations to break down barriers and simplify the tech stack to take advantage of the transition. DevSecOps is a four-stack endeavor with teams wearing many different hats.
  • 1) Instead of saying no, a positive DevSecOps culture responds to security challenges with a paved-road approach – open/closed source solutions that are developer-friendly and that are implemented in a way that makes them easy to get right. 2) DevSecOps works best by anticipating the security needs of DevOps and providing a “paved-road” for securely building applications within the bounds of programmatic policy. If those guardrails are too tight, then DevSecOps teams should also provide clear directives that enable DevOps teams to build their own solutions that meet the security requirements.
  • An understanding of its importance for securing data. In this brave new world of distributed data in virtual environments with limited existence, new exposure points will be created and continue to challenge security teams’ ability to detect and protect.

Here's who provided their insights:

collaboration, devops, devsecops, security

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}