Posted on by Tom Smith

DevSecOps Additional Considerations

To understand the current and future state of DevSecOps, we gathered insights from 29 IT professionals in 27 companies. We asked them, "What have I failed to ask you that we need to consider with regards to implementing DevSecOps Trend Report?" Here's what they told us:

"DevSecOps"

  • The DevSecOps term is kind of funny, but I believe it should just be DevOps with security built in. If security is not built into DevOps, DevOps is failing.
  • I really don’t love the name. I would call it DevOps and say security is part of both the Dev and Ops domain. If we keep putting every responsibility people should do in the name, we’ll run out of room for the hashtag. #DevSecITSMTestAutomationMonitoringObservabilityPeopleFinanceMarketingQAOps.

Culture

  • Just like DevOps, think of DevSecOps as a culture shift first with the tools and processes next. Start with the security professionals to embrace automation to move at the pace of DevOps.
  • One final thought: tools don’t make DevSecOps. It’s a shift in behavior and mindset. The journey will be different for each organization based on cultural momentum. Collaboration is becoming even more important. That will create natural friction because of differences in opinion. Accept that as part of the change that will be necessary to inject security into DevOps.
  • When organizations are thinking about how they deliver software to their customers, it’s important for all developers to remember that they are in the business of delivering value to the business and the customer. Delivering secure code without vulnerabilities is one of the most valuable things they can do to be more valuable. Everything matters. You assume the apps on your phone are secure.
  • It may seem obvious that the reason development teams should care about DevSecOps is because they want (or should want) more secure software released quickly and with fewer blockers and hassles, resulting in a better working relationship with their security organization. But prioritizing DevSecOps might help development organizations with another goal — adoption of DevOps in the first place. Security and compliance requirements are often mandatory and well-defined, making the first steps of workflow automation clear to implement. Shifting security “left” might be an effective forcing function for an organization-wide adoption of basic DevOps practices, justifying the time and tool investments and making further iterations simpler. In that way, DevSecOps might actually be a shortcut to a broad and consistent DevOps practice.
  • The cultural aspect of DevSecOps is crucial. Discussions focused on security tools and how to apply those tools is important, however, it’s worth stressing that collaboration, shared responsibility and common KPIs needs to become a bigger focus to ensure teams implement DevSecOps successfully. Special emphasis also needs to be paid to thinking about which DevSecOps team structure works for your organization. Embedded security engineers, security trained Developers or cross-functional teams are all valid approaches to team formation. The same DevSecOps shoe does not fit everyone and it is important to think about what will provide the most benefit in your organizational and technology culture.
  • The most important takeaway is that DevSecOps is going to become mainstream and that solutions exist already to facilitate and enable companies to embark on this journey. Organizations must do their due diligence and pick a vendor that provides a comprehensive offering instead of building something that is outside of and detracts from their core business. Regardless of the approach, take this seriously, formulate a practical plan and execute it one step at a time.

Tools

  • 1) If you’re not confident in your own security group there are a lot of companies with expertise in security and the security pipeline, so rent it and bring it in. Bring forward security in your own pipeline and mature your current security group to form a cross-functional product team. Use outside resources to help. 2) If you have a CI pipeline and haven’t implemented a code scanner yet, you need to do that tomorrow!
  • It’s interesting to look at how tools can help this process. Tools can be important in keeping a process sustainable on a team. The same way you think about CI/CD is how you should think about security. Implementing a tool to analyze security can be a great addition to DevSecOps. The more you can automate the tedious or repetitive elements of the security n to the SDLC the more they will stick with the process and not hinder productivity.
  • How to implement tools. The c-level and how they get involved. Changing the culture starts at the top. Others in the organization start to feel DevSecOps is important. People need to understand what security means in their day to day roles and responsibilities.

Other

  • This is a great story. I can’t emphasize enough that time, resources (+expertise) and money are critical in delivering true DSO. This is not academic — this is the reality.
  • Don’t get overconfident. There is value in traditional security. Don’t forget about your IAM set up. Don’t forget the fundamentals.
  • Help developers differentiate the signal from the noise. At KubeCon, there were three or four different service mesh technologies. How to choose the right technology. Help developers understand the difference. Get war stories about what does and doesn’t. Show your DevOps trump card.
  • Using technology helping to secure the data and integrity that leverages blockchain.
  • Node has become popular, the open source supply chain for the code will become more fragile. Really understanding your code supply chain will be critically important. Just because something is intangible doesn’t mean you don’t need to understand where it comes from. We have not seen the full impact of insecure code. The other thing any time a new project hits the PMO office, the security team is tightly aligned with the product management office to get visibility sooner rather than later and helps get the security team involved earlier.
  • There is huge potential in the area of infrastructure security and security considerations for Operations teams when monitoring products that can be discussed in more detail. Also, how AI and ML can help identify issues before they happen based on patterns is a very important part of the DevSecOps journey, that could be discussed in further detail.
  • Benefits of consistency and best practices for developers, CI/CD, and operations.
  • 1) We often see companies adopting DevOps processes to deliver new code fast and they find success right away. However, proving compliance/security in an everything-as-code world isn’t easy, because the people with security expertise simply are not coders. 2) The more DevSecOps teams can show their work to the rest of the business, the easier it will be to comply with internal and external regulation. There will be fewer manual walk-throughs and compliance hurdles down the road, too.
  • Perhaps the more important question you did not ask: Where is regulatory compliance headed next?

Here's who provided their insights: