Information security is a changed game. Traditional security practices can’t keep up with the rapid acceleration of both infrastructure as code and cybercrime. It’s time for a new approach: continuous security testing throughout your development cycle.
Infrastructure is dynamic
DevOps is here to stay. In the last decade, how we build and deliver software and infrastructure has fundamentally changed, and there’s no going back. The days of siloed processes are over. By breaking down the barriers between development, IT, and operations, product delivery is faster and more cost effective, and the work environment is more engaged and collaborative.
In every industry—retail, manufacturing, software as a service, you name it—information infrastructure has transformed. Before, you managed individual servers; now you manage vast cloud platforms that rapidly scale and change.
The expectations of Security teams grow as infrastructure rapidly scales and changes. There’s more to protect, and the system is a moving target.
Infrastructure as code delivers speed and consistency
Infrastructure as code (IaC) is the managing and provisioning of information infrastructure using code instead of through manual processes. An example of a common IaC platform is Hashicorp’s Terraform, which lets you manage your public or private cloud deployments through code.
Cool. But what does it have to do with security?
By codifying your infrastructure, you make it easier to edit and distribute configurations. You also ensure that you’re provisioning the same environment every time, which helps you avoid undocumented, ad-hoc configuration changes.
But infrastructure as code, to a certain extent, has allowed information organizations to fail faster. It lets you repeat the same misconfigurations and vulnerabilities over and over. And it hasn’t really changed the way that organizations secure their information.
You can spin up infrastructure in seconds, but you probably still implement security as if you build your infrastructure manually. Infrastructure as code only increases the speed and agility that currently challenge Security teams.
Attacks are faster
Cybercrime, too, has accelerated and grown. Hackers can more easily automate attacks, and their attack infrastructure can quickly scale and adapt just like ours—or faster.
According to Statista: 
Testing the production environment is slow.
In many organizations, information security struggles to keep the pace. Scanning a production environment takes time, leaving known vulnerabilities and misconfigurations in place for weeks, months, and even years.
It can also take months for a Security team to discover an attack has occurred. Every day that a breach goes undetected means more loss for the organization. According to IBM, on average it takes: 
With the time required to detect and fix breaches in production exponentially larger than the time it takes to attack, how can Security teams protect our organizations?
Conflicts arise between DevOps and Security
Another problem is that Security teams are in a challenging position: they’re held accountable for maintaining a safe and compliant environment, but they’re not responsible for the underlying infrastructure.
DevOps faces the inverse challenge: they own the infrastructure but can’t access the security tools. Testing often relies on isolated tooling that aggregates data on the currently configured infrastructure. This security tooling is often available only to the Security team.
Security testing tools are known to generate a lot of noise and lack relevance to your specific systems. Their many disadvantages include:
Often, DevOps and Security teams do not see eye to eye immediately when a long list of errors are presented. Each team can have a different view of what is relevant to the organization. This disconnect can carry a high cost.
Security testing must be continuous
The divide between Security and DevOps and the agility of today’s infrastructure keep the information security testing process either reactive or passively proactive. With attacks coming faster and infrastructure growing, production scanning doesn’t protect against cybercriminals. You must test for known vulnerabilities and misconfigurations earlier in the development process. This is known as shifting left in security.
DevOps and Security teams need to work together to implement security measures during the entire development lifecycle. The goal of shifting security left is to design infrastructure with security scanning built in. You detect and fix potential security issues and vulnerabilities as early as possible in the development process. Security testing becomes continuous, making it easier, faster, and more affordable to address security issues.
What do we need in a continuous security testing solution?
So, what’s the goal? Ideally, it’s to catch misconfigurations and potentially stale artifacts before deployment. Because 99% of attacks are attributed to unpatched systems or misconfigurations, you can reach this goal with the right solution in place.
But what defines that right solution? What are our requirements for a continuous security testing environment?
Don’t halt production.
In many instances, we don’t want to suspend production in order to solve the problem.
Minimize friction.
Also consider that any infrastructure development change should introduce only minimal friction to existing workflows. For example, it must integrate into existing CI/CD pipelines.
Minimize the learning curve.
We also want to make sure that learning how to use the new solution isn’t cumbersome. If team members have to learn a whole new language or process, adoption will be low.
Dependabot got it right
GitHub’s Dependabot is an example of how a minimally-invasive tool improved software security for millions. Dependabot eased the workflow for software developers by notifying them when their software relied on packages with known vulnerabilities.
Our IaC code deserves the same benefit. We should know when our Docker images rely on vulnerable packages or our Terraform files reference insecure services.
Tool fatigue complicates and slows the process
Many security platforms focus solely on runtime, some on static analysis, while others don’t offer enough coverage. While all of these are important, historically we have found that policy written for them has been approached entirely differently.
Without a single security platform that covers all testing needs, many rely on a collection of security tools. For example, each of these checks requires you to implement, maintain, and monitor a different tool:
- Check Kubernetes manifests.
- Ensure that no privileged containers are being deployed.
- Verify that the container itself doesn't depend on a vulnerable upstream container.
- Affirm our Terraform code doesn't accidentally open up ports.
- Verify that the deployed Terraform infrastructure follows the organization’s policies on proper machine sizes and ensure that infrastructure is properly tagged.
- Check the running state of the production infrastructure.
All of these use cases require different software, different steps, and different ways of operating. Welcome to tool fatigue.
Mondoo can help
In essence, we plug all types of holes no matter their shape. For example, Mondoo can scan a Kubernetes pod and the running containers for compliance and security issues. And, unlike siloed tools, Mondoo can also check the container registry that the pod is pulling the images off of.
With Mondoo you can assess and discover both misconfigurations (based on a policy library that comes with Mondoo) and vulnerabilities on your entire fleet. Mondoo reduces the noise that plagues so many security testing tools. The information returned is relevant (or, if not, is easy to disable). Teams that are accountable for the underlying infrastructure have access to Mondoo platform tooling.
You can integrate Mondoo into git/pull requests to ensure that the incoming code passes IaC (such as Terraform or Kubernetes manifests) static file analysis. The static code analysis allows you to catch errors and misconfigurations before you codify them in a compiled object (such as a container, public cloud service, or SaaS service).
Mondoo helped Calligo
The data transformation experts at Calligo were fascinated by the idea of automation and what it could bring to their organization. Automation can be a lifesaver, but only when set up correctly. In their case, automation only allowed them to make bad things faster, and left them with no way to rectify the harm. They tried remediating with makeshift patches, which eventually grew into chaos.
This pain eventually led to their operations personnel spending all their time on unplanned work. It was a total time suck. And what caused every one of those minutes spent on unplanned work? Misconfiguration.
Before Mondoo, Calligo worked in a very binary fashion. Everything was either pass, fail, yes, or no, a tedious and slow process to reach the results they sought.
What excited Calligo was that they could truly fit Mondoo into their full lifecycle. Before, they could run checks only on elements that already existed in production. Now they can check compliance and vulnerability long before they release.
Shift left now
Mondoo makes security testing continuously available at every stage of your development lifecycle.
