The inside of a grain silo

The New IT Silo

cloudcoreo George Moberly 0 Comments

The more things change, the more they stay the same. IT teams have battled siloing “forever.” In recent years, the term DevOps has been coined (followed by child terms such as SecOps, DevSecOps, NoOps) to express the nirvana idea was that there would finally be a wonderful place where there were no more silos. Individuals would be fully capable of doing development, operations, deployment, monitoring, cost, and security.

At CloudCoreo, we have seen many large AWS consumers who are blazing full speed ahead to combine most of these functions, but are struggling to keep up with security. These are often newer companies that have scaled to the point where they have realized they need a dedicated security role to work alongside their development teams in order to ensure the safety and security of their applications. But often the tools that are used by a security role operate “over the top,” providing scan results for everything in the cloud account regardless of where it came from or how it was provisioned. Naturally, the result is that remediation—actually fixing the issues security finds—is often hampered by lack of context and the sheer volume of the feedback provided. In isolation, these over the top scans leave security overwhelmed with a to-do list that often only gets larger with time and leave development overwhelmed with un-prioritized security requests that compete with their other business priorities. We’ve consistently heard that this approach does not scale and rarely results in a reasonable amount of time to address critical security issues that arise out of misconfigured cloud services discovered too late. The reality is that chasing down issues after the fact is costly and it slows organizations down.

The idea behind shift left testing is to test as early and often as possible.

The idea behind shift left testing is to test as early and often as possible.

To address this issue, we’ve come up with a different approach to cloud configuration auditing, one that shifts the problem left, into the developer toolchain.

Developers are the ones creating the issues, and developers are the ones who need training, guidance, and feedback, and they need it quickly—in real time responses to any changes they just made that can cause potential issues. That is the time to address a new issue, while the code is still fresh from the fingers, not months or years later when no one is still around who remembers what was done and why.

That is the time to address a new issue, while the code is still fresh from the fingers, not months or years later when no one is still around who remembers what was done and why.

We also know that doing this has to be transparent and not involve any change to the developer workflow—it needs to be inserted without disrupting code, processes, or tooling.

We’ve created a solution that allows easy and transparent insertion of cloud and application checks into the continuous delivery pipeline that provides an enhanced production pipeline. Unit testing and source code security scanning can already be integrated into your CI/CD pipeline, so why not cloud infrastructure testing? An automated pipeline is exactly the place you want to find out about issues with your cloud infrastructure—not days, weeks, or months later in an over the top security scan. We think it’s the right solution to the growing problem of cloud misconfiguration and we’re excited to share our approach.


Come visit us at Jenkins World 2017 to see a demo or learn more about our Jenkins plugin and how to add cloud infrastructure testing to your pipeline in just a few simple steps.

 

Leave a Reply

Your email address will not be published. Required fields are marked *