DevSecOps promised us automation, speed, and security woven directly into development. But we're hitting clear limits, especially in terms of visibility and traceability. These are critical for automating compliance controls on developer actions. With "Shift Left" and DevSecOps, developers now have the ability to change production with every commit—potentially hundreds of times a day. Meanwhile, compliance teams, at best, manage monthly reporting in most organizations.

There's a huge disconnect between compliance teams and development teams. Developers will say compliance moves too slow. Compliance needs to figure out how to move faster. But as a developer by trade, I have to ask: What have we done to make it easier for compliance teams to understand the state of our software?

Compliance teams deliver value by allowing products to enter new markets. SOC 2, PCI DSS, HITRUST, and FedRAMP are all gateways to additional users of our software. Cash aside, isn't that what we want most? We want people to derive actual, real value from our software.

The Reality of "Shift Left"

So how does this work in practice? With "Shift Left," many high-performing organizations have integrated security checks into their development pipelines. If your dependency has a CVE (Common Vulnerabilities and Exposures), no merge for you.

And this is why developers hate security. We're focused on solving business problems—pushing code, pulling open-source packages. We have a solution and want to push our code, but we're blocked. One of the packages we pulled in to solve the problem, deliver the feature, includes a critical CVE, and there's no fix. But as the developer, I know this CVE is 100% out of scope. It doesn't matter, though. The compliance team will pick up the vulnerability and initiate a mountain of paperwork, if you don’t know what a POA&M is, consider yourself lucky.

The Compliance Team's Perspective

Let's flip the script and see it from the compliance team's perspective. FedRAMP is a huge market. You know this because your CRO (Chief Revenue Officer) has had it in their slide deck for the past three years. The task seems insurmountable. You're dealing with 45 microservices, 12 cloud services, a development team of over 300 spread across 16 time zones. You have six months to validate 180 NIST Controls across an unknown number of systems.

The diversity of systems and teams makes maintaining consistent governance and security practices a daunting task. The compliance team is under immense pressure to ensure everything meets regulatory standards, and any misstep could have significant repercussions.

Bridging the Gap

There's a massive disconnect here. Developers see compliance as a blocker, while compliance teams are overwhelmed trying to rein in rapid development cycles that outpace their ability to monitor and report.

76% of C-suite executives say compliance challenges limit their ability to innovate. Integrating compliance into development could bridge this gap without stifling creativity.

My co-founder and I developed Witness and Archivista to address this issue and donated them to the CNCF in-toto project. These tools have helped security and compliance teams at organizations such as Autodesk and Farmers Insurance keep pace with developers, enabling them to meet compliance requirements without slowing down development cycles.

As a developer, I believe we need to take some responsibility. What have we done to make it easier for compliance teams? We need to ensure that our processes are transparent and that we provide the necessary visibility.

A Path Forward

So, how do we fix this? We need to shift compliance left—just like we did with security. This doesn't mean piling more work onto developers. Instead, it's about integrating compliance checks into our pipelines in a way that doesn't disrupt our workflows.

Imagine if compliance evidence was automatically collected as part of our development process. No more chasing down developers for security scans, test results, or evidence of regulatory compliance. The data would be there, readily available, and up-to-date.

We can achieve this by:

• Implementing Observability into the SDLC: By observing developer actions and mapping them to compliance controls, we can understand compliance without impacting velocity.

• Automating Compliance Tasks: Tools can automatically collect necessary evidence, reducing manual effort and errors.

• Enhancing Communication: Improving lines and methods of communication between developers and compliance teams can bridge the gap.

Embracing Trusted Telemetry

By adopting trusted telemetry, we can collect data about what's happening in our development processes securely and reliably. This data serves as the evidence needed for compliance without placing additional burdens on developers.

• Developers can focus on coding, knowing that compliance evidence is being collected transparently in the background.

• Compliance teams get real-time visibility into the development process, reducing the need for manual reporting and endless paperwork.

Taking Action

As developers, we need to take the initiative here; we are the experts in our systems, and compliance is trying to do its job to protect the business from risk and help expand the use of your software into new markets. Let's:

• Adopt Tools and Practices that integrate compliance into our workflows without adding friction. I’ll make a note to write an article about the open-source automated governance toolsets that are out there.

• Collaborate with Compliance Teams to understand their needs and challenges.

• Promote Transparency in our processes to make it easier for compliance teams to do their job.

Compliance teams, on the other hand, need to embrace automation and integration. By leveraging technologies that provide observability and automation, they can keep up with the pace of development and reduce the burden on both sides.

Shifting compliance left isn't about shifting the burden; it's about building a collaborative environment where compliance and development work hand-in-hand. By integrating compliance into our development pipelines, we can reduce friction, speed up time to market, and ensure that our software not only solves business problems but also meets the necessary regulatory standards.

After all, we all want the same thing—to deliver valuable, secure, and compliant software to our users.