Does adhering to compliance standards necessarily mean that your DevOps are secure?

No. 

Security and compliance are two elements on a Venn diagram. There is often a lot of overlap between them. But one can be 100% compliant and be insecure, or quite secure but non-compliant.

Our stance would be compliance to standards means less post deployment corrections. And perhaps less simple security issues. It definitely does not mean DecOps are secure. I would consider them cousins. They both need to be at the party

This makes me think of a quote, "The reasonable man adapts himself to the world. The unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." That kind of goes against some of the philosophy that the best thing to do is to get a consensus. But, at the same time, you have to try to push the barriers of what people think is reasonable. If you don't make that effort, if you're not trying to put improvements in place, if you're not expanding what people think about, when they're trying to build applications, to add in the security now rather than after the fact, then they're not going to think about it. The consensus of, "This is good enough," will prevail. You end up not making any progress. If you've got a company that's going for compliance, you have to push them to go a step farther and really think about it, and engage with it, and turn that into a security practice, instead of, "Let's get enough check boxes done that maybe our customers will give us money and go away."

Compliance does not equal security. Security has got to be so much more. However, if you get three different security professionals in the room and ask them to define “what is secure”, you'll probably get four or five different opinions. So, at a certain point, customers, users, stakeholders, everyone needs to understand where the security controls, processes, etc., sit. Compliance allows you a tool to measure and report that. Compliance can also help weed out the riff raff. For example, you have to have a clean report to get to your CMMC level three if you want to do business with the defense department. That creates a barrier and a line where the companies that just use security as an afterthought may not make it through. You have to have compliance in there, otherwise, what is it? You have needs, you have criteria, but what are you measuring people against? How can you compare two different organizations, when you're looking at them?

I view compliance as non nonfunctional requirements that have to go into every single backlog. Security, on the other hand, needs to go into every single item within the backlog. So it's not like a checklist at the end when you're done something, it is part of everything that you do. Stepping out a little bit more, the architecture is key. People get wrapped around the axle with tools, and they want to build these pipelines for the latest and greatest things. All of a sudden, they think, "We're going to turn this thing on, and we're going to be so much more efficient." But then they forget that their code is not as agile as their pipeline. A one-line change can easily take two hours to build inside of a pipeline, because your code is not as efficient as the pipeline. But it’s the same thing with security architecture, there needs to be consideration for how to build that in, into some type of way that services and optimizes the development in itself. That's how it's far different from compliance. It has to be built in. You have to take a step back and realize where you need to build that in, just as much as you need to build the agility into your code base.