Main menu


Our approach to security compliance is destroying our development culture – the new stack

When we think about compliance processes, most often these are top-down, business-driven processes that have nothing to do with code or tech stacks, and are mostly cumbersome for a developer’s workflow.

Chris Koenecke

Chris is Jit’s VP of Security Engineering and CISO, with over 20 years of experience in cybersecurity. Chris focuses on cloud security, security program development, security strategy, and cyber risk assessment and management. Chris is a Cisco Certified Network Associate (CCNA), Certified Information Systems Security Professional (CISSP), Certified Ethical Hacker (CEH), Archer Certified Consultant (ACC) and holds his clearance in TS/SCI Security.

But in reality, more than 80% of the heavy lifting in the compliance process falls on a good security posture and culture. So, cultivating developer mindset from the very first line of code not only better prepares them for new threats and risks, but also makes the compliance process a much lighter lift for the organization. You can also

In my 15 years of running compliance programs at KPMG (before I joined Jit), companies seeking regulatory compliance and certification without embedding a DevSecOps mindset start by disrupting their engineering culture. I discovered that

When security is driven by compliance, there is no process to institutionalize security tools and processes in advance, and audits are focused on being a core driver of security, ultimately, as soon as audits are finished, Security practices will start drifting like “theatrical security”. way to think. Another drawback is that this type of approach encourages the belief that security is a business metric and is completely removed from the engineering process. Nothing is farther from the truth.

Progressive engineering and security leaders want true continuous security, where compliance is merely an operational derivative and not the end goal. The scale of today’s cloud operations and data is enormous, the threat landscape is continuously growing and evolving, and attackers are becoming more sophisticated.

Security has become an equally important engineering discipline that is inseparable from the tech stack and products. Security is no longer someone else’s problem, much like the “it worked in development, now it’s a question of operations” meme pervasive in the DevOps culture. Our code, our security.

But how does all of this relate to compliance?

Compliance is not a silver bullet

Compliance processes were born to provide a standardized way to operate in a modern cloud native engineering environment. This enables organizations to reduce risk by considering both operational and administrative aspects, as well as technical aspects of systems and data. As such, many organizations, including governments, healthcare, and the financial services industry, have made them a requirement to enable market access and product penetration.

Yet compliance, completely decoupled from a good security posture, cannot mitigate real-world risks from both existing and emerging threats. Additionally, achieving compliance provides little value to the business if security is compromised.

A common misconception is that compliance or security certifications such as SOC2, ISO, FedRAMP, and HITRUST are silver bullets and peace of mind.

This means that an early and delicate balance must be struck between compliance and security, and both must be prioritized. I would argue that the innate security mindset requires embedding security in the first line of code.

There is a common misconception that compliance or security certifications such as SOC2, ISO, FedRAMP, HITRUST are silver bullets. Earning these certifications gives you peace of mind and confidence that you’ve ticked all the boxes to reduce risk for your organization.

This is not real. Compliance is not the same as security. Making the mistake of being single-threaded in achieving compliance can miss potentially important areas of risk and vulnerability that are not part of the compliance process.

Robust developer-owned security enables compliance

If you build your product with a strong security mindset early in the development process, you’ll eventually find it much easier to drive compliance processes with minimal friction within your organization. A robust security program ultimately lives with compliance.

Looking at the most common security and compliance certifications, there is considerable overlap regarding the technical aspects required. What’s interesting is that the technical requirements actually make up the bulk of the effort to get through these often difficult processes.

Questions about security certifications and compliance include:

  • A secure software development life cycle.
  • How an organization protects against known vulnerabilities.
  • How organizations track and respond to emerging threats.

New tools and DevSecOps are key to simplifying and even enabling these efforts. After years of helping some of the largest Fortune 500 companies achieve compliance, I chose to join Jit because security as code is what it means to the industry as a whole. We understood that it would be the backbone and enabler to greatly facilitate

Empower developers to take ownership of security with a platform that provides easy access to developer tools, controls, code, infrastructure, runtimes, imports, and checks that protect third parties. In the context of compliance, securing code means securing the software delivery life cycle (SDLC) and the software delivery process.

Securing cloud and CI/CD and managing integrations appropriately to mitigate known threats and prevent future risks from being introduced into systems through the supply chain through code and configuration. I am teaching. These are just a few examples of what can be achieved with good open source security tools and developer-owned security.

It turns out that not starting from the bottom up in security is a moral killer and very detrimental to engineering organizations.

Unfortunately, I have also had this process reversed. Early-stage startups are often focused on delivering MVPs and code as quickly as possible, with little consideration for how security is baked into this process. As you grow in size and need access to the market, you will need to obtain security certification from your business.

What ends up happening is that when security is applied as an afterthought and new and unfamiliar tools are added to the stack, there is a lot of friction in the development process, and mitigation processes are not well defined, and these changes embedding delays delivery and frustrates the developer alone. I want to be the shipping code.

Not starting from the bottom up with security can prove to be a moral killer and very detrimental to engineering organizations. This creates an environment that encourages developers to bypass these controls, exposing your organization to unnecessary risks and violations.

DevSecOps Metrics as Business Success Factors

Widely adopted today, the DORA metric measures, through years of data, what elite engineering teams become elite teams by focusing on four core capabilities. They can be divided into driving speed and risk mitigation indicators. In the context of DevOps, risk mitigation is measured by mean time to restore (MTTR) and change failure rate (how often changes introduced into production cause failure).

In the context of DevSecOps, risk mitigation can be quantified by the time it takes to remediate and the frequency with which security vulnerabilities are introduced into production. Luckily, a great open source that integrates natively into developer workflows to help scan and remediate known exploits and prevent them from reaching production, greatly reducing security risks There are many security tools. Threats are everywhere: your code, your configuration, the containers you pull, the packages you import.

If you focus solely on theater security in the form of security certifications, and don’t guarantee to build security and control into the actual tech stack, user data, and infrastructure, you’ll quickly realize you’re done with the show. ‘s developer-owned security keeps the show going.

The New Stack, a wholly owned subsidiary of Insight Partners, has invested in the following companies mentioned in this article: Jit, Real.

Feature image via Pixabay.