Shifting Compliance Left
A Letter to Compliance Teams
DevSecOps has left compliance in the dust. Developers can now move faster than their code can be evaluated for risk, by several orders of magnitude. Compliance teams often lack the engineering expertise or the tools needed to keep up with the pace of development. Meanwhile, developers don’t always understand the business value compliance brings—revenue often requires compliance. It’s frustrating, and many CISOs are forced to make a difficult choice: slow down product development to the speed of compliance or accept the risk. Through incidents like SolarWinds and CrowdStrike, we've seen that accepting risk and blindly trusting developers can have real consequences.
Compliance, like building codes, exists to prevent incidents. When developers move ahead without compliance guardrails, it’s like building a house without knowing the local building code. You dig the foundation, frame the house, add the roof, and install utilities—all by industry best practices. But just as the house is ready for handoff, you discover it’s in a floodplain and needs to be built on stilts. You might build something strong and efficient, but missing critical information can compromise everything.
This is the current state of software development in high-compliance environments. After transitioning from the military to the civilian world, my first job as a software developer was contracting for the Joint Special Operations Command. It was my dream job—I had tried, unsuccessfully, to earn my “long tab” as a US Army Special Forces member, but after two years in the qualification course, I knew that life wasn’t for me. Sometimes, though, life gives you lemons, and other times you get lucky. My luck was finding work with a tier-one organization, fighting terrorism with code.
It was around 2017, and the fight against ISIS was in full swing. I was tasked with deploying and adapting one of my team’s applications for a partner network. We needed to change the data classification model to support non-US countries. The changes were straightforward, tested, and approved by our authorizing official.
The next step was deploying the application to the partner network. The mission was critical, and urgency was high—so high that I was sent to Jordan the week before Christmas. I was on board, though my wife wasn’t thrilled. We’d just welcomed our first daughter, and she needed me. But my country needed me, too, and the mission and our financial situation won out.
Once I got to Jordan, I began coordinating the application install—but was stopped dead in my tracks. We didn’t have authorization to deploy on the parner network. It was a different commander from a different country, and our authorization package wasn’t compatible.
This was completely on the compliance team. As a developer, I had no idea what the compliance requirements were. Looking back, we did everything right: we used the right encryption, TLS was in place, and our AuthN/AuthZ and data security model was top-notch. But it didn’t matter. Our compliance team hadn’t generated or communicated any compliance requirements. I didn’t understand NIST 800-53 or that our software and development process had control validation requirements.
While this might sound like an exceptional failure story, it’s a pattern across organizations, regardless of their glamour or bureaucracy, if they have compliance requirements. Take FedRAMP, for example. FedRAMP is an excellent program—probably one of the most successful tech programs in the US government. It connects innovators with Federal missions and generates billions in revenue for companies with that stamp of approval.
However, compliance comes at a high cost. Every new feature or AI model a company adds now needs FedRAMP authorization. The current compliance processes and technologies can’t keep up with development. The companies that the government wants in the FedRAMP marketplace are the same ones trying to ship updates 100x daily to remain competitive. This disconnect is massive, with modern compliance processes barely able to produce an evaluation once a month.
According to a CloudBees survey 64% of executives say their teams see compliance as the “department of slow.” Further, C-suite leaders report spending over 37 days annually on compliance audits—time that could be better spent on innovation.
Let’s return to our story. The compliance team failed to understand and communicate the requirements of this new system, which resulted in the software development team's never-realized business goals. The code we spent months developing could never deliver value because it wasn’t compliant. We could have saved time, money, and lives by shifting compliance checks earlier in development.
So, can we have our cake and eat it too? Can organizations foster a culture of innovation and continuous delivery—the values driving commercial success—while competing in the Federal market, which prizes compliance over features? The answer is yes, and it’s our vision at TestifySec. Let me know if you’d like a sneak peek at what we’re building. It’s still raw but has already proven to accelerate time-to-market for compliance frameworks like FedRAMP with users such as AutoDesk.