Your Approach to Security Compliance is Destroying Dev Culture

"If we foster a dev-sec mindset from the earliest lines of code, we’ll better prepare our developers for emerging threats and risks and make compliance processes a much lighter lift for our organizations."You can learn more from our CISO, Chris Koehnecke. ‍

Your Approach to Security Compliance Is Destroying Dev Culture

If we focus on security certifications and don’t embed controls on our actual tech stacks, user data and infrastructure, we’ll soon find the show’s over.

When we think about compliance processes, we often see these as top-down, business-driven processes that are unrelated to our code and tech stack, and mostly just an intrusive nuisance to developer workflows.

However, the reality is that good security posture and culture is more than 80% of the heavy lifting in compliance processes. So if we foster a dev-sec mindset from the earliest lines of code, we’ll not only better prepare our developers for emerging threats and risks, we will also make compliance processes a much lighter lift for our organizations.

In my 15 years of running compliance programs at KPMG (prior to joining Jit), I discovered that the companies that chase regulatory compliance and certifications without embedding a DevSecOps mindset to begin with destroy their engineering culture.

When security is driven by compliance, with a focus on the audits being the core driver for security without a process to institutionalize security tools and processes beforehand, eventually security practices start drifting as soon as the audit is over in more of a “theatrical security” mindset. Another downside is that this type of approach also foments a belief that security is a business metric and completely removed from engineering processes. There couldn’t be anything further from the truth.

Progressive engineering and security leaders would like to achieve real, continuous security, where compliance is simply an operational derivative and not the end goal. With the sheer scale of cloud operations and data today, the threat landscape is continuously growing and evolving, with would-be attackers becoming more and more sophisticated.

Security has become an equally important engineering discipline that can no longer be decoupled from our tech stacks and products. Like the meme “worked in dev, ops problem now” popularized in DevOps culture, security is no longer somebody else’s problem. Our code, our security.

But how does this all relate to compliance?

Compliance Is Not a Silver Bullet

Compliance processes have sprung up to provide a standardized way for operating in the modern, cloud native engineering landscape to help organizations reduce risk by thinking about both the technical, as well as operational and administrative, aspects of systems and data. That’s why many organizations in the government, health or financial services industries, among many others, make these a requirement to enable market access and product penetration.

That said, compliance completely decoupled from good security posture will not protect you from mitigating real-world risk, both from existing and emerging threats. What’s more, if your security is compromised, your compliance achievements will provide nominal value for your business.

This means there needs to be an early and fine balance between compliance and security, and you need to prioritize both. I’d argue that security should be embedded as early as the first line of code in a born-left security mindset.

There is a common misconception that compliance or security certifications like SOC2, ISO, FedRAMP and HITRUST are a silver bullet and once you achieve these certifications, you can rest easy and be confident that you have checked all the boxes toward reducing organizational risk.

This is not the reality. Compliance does not equal security. If you make the mistake of becoming single-threaded about achieving compliance, you may be missing potentially important areas of risk and vulnerabilities that aren’t part of the compliance process.

Robust Dev-Owned Security Enables Compliance

If you build your products with a strong security mindset from early in your development processes, you’ll ultimately find yourself driving compliance processes quite easily and with minimal friction in your organization. A robust security program is ultimately symbiotic to compliance.

If we take a look at the most common security and compliance certifications, they have quite a bit of overlap when it comes to the technical aspects they require. The interesting part is that the technical requirements are actually the large majority of the effort to get through these often- grueling processes.

When it comes to security certifications and compliance, they will all ask about:

• Secure software development life cycle.
• How your organization secures known vulnerabilities.
• How your organization tracks and responds to emerging threats.

New tools and DevSecOps are the key to simplifying and even enabling these efforts. When I chose to join Jit, after years of assisting some of the largest Fortune 500 companies with achieving compliance, it was because I understood that security-as-code would be the backbone and enabler for making this significantly easier for the entire industry.

With platforms that provide easy access to developers’ tools and controls and checks that secure their code, infrastructure, runtime, imports and third parties, we empower developers to take ownership of security. In the context of compliance, securing code is securing your software-delivery life cycle (SDLC) and software-delivery processes.

By ensuring cloud and CI/CD security, as well as managing integrations appropriately, we are taking measures to mitigate known threats and prevent future risk from being introduced into our systems — from the code and configuration through its supply chain. These examples are just a small sample of what can be achieved through excellent open source security tools and dev-owned security.

Unfortunately, I’ve also had the experience of seeing this process reversed. Many times, early-stage startups are focused on delivering their MVP and code as quickly as possible with little regard to how security is embedded in this process. As they start to scale and require market access, they receive demands to achieve security certifications from the business side.

What ends up happening is that security is applied as an afterthought, creating a lot of friction in development processes as new and unfamiliar tools are added to the stack, where mitigation processes are not well defined and embedding these changes delays delivery and frustrates developers who only want to be shipping code.

If you don’t start with security bottom up, you will find that it becomes a morale killer and quite detrimental to your engineering organization. This will create an environment that encourages developers to bypass these controls and will expose your organization to unnecessary risk and breaches.

DevSecOps Metrics as a Business Enabler

DORA metrics, widely adopted today, have measured through years of data that elite engineering teams become elite teams by focusing on four core capabilities. They can be divided into metrics for driving speed and reducing risk. In the context of DevOps, reducing risk is measured in mean time to restore (MTTR ) and change failure rate (how often changes introduced to production cause failure).

In the context of DevSecOps, reducing risk can be quantified in time to remediate and how often security vulnerabilities are introduced to production. Luckily, though, there are plenty of exceptional open source security tools that reduce security risk significantly that integrate natively into developer workflows, from helping with the scanning and remediation of known exploits, through preventing them from ever reaching production. Whether it’s in the code or config, the containers you’ve pulled or the packages you’ve imported, threats are everywhere.

If we solely focus on theatrical security in the form of security certifications and don’t ensure we embed security and controls on our actual tech stacks, user data and infrastructure, we’ll soon discover the show’s over. Real dev-owned security will enable the show to go on.

‍Originally posted on TheNewStack