If there is anything that keeps cloud development leaders up at night, it’s the fact that the risk of an impending security breach is scarily high. If I go around the room at any enterprise development meeting, devops engineers, cloud developers, and cloud architects all see a company-debilitating breach as inevitable.

Enterprise Strategy Group recently completed a cloud threat detection and response research project with interesting results. First, what we already understand: 80% of organizations have adopted a devops model, and 75% push new software builds to production at least once a week. The top challenges include not having enough visibility and control within the development process, software released without security checks, and inconsistent security processes across development teams. I would add supply chain concerns as well.

Now, the scary part. The survey found that in the past year, 99% of organizations experienced cyberattacks related to cloud-hosted applications and infrastructure. Most of you are thinking that you haven’t heard about a breach within your own enterprise, but they are often kept secret, even within the company.

The primary attack vectors are misconfigurations (something is just not configured correctly), general software vulnerabilities, and misuse of privileged accounts. These seem like easy problems to fix. However, for some reason, they have become more systemic. This report notes this, and I see it often.

What should be done?

What strikes me most is that we understand how to fix these vulnerabilities but have not taken steps to do so. Most of the CISOs I talk to offer the following excuses.

First, they are not given the budget to plug up these vulnerabilities. In some instances, this is true. Cloud and development security are often underfunded. However, in most cases, the funding is good or great relative to their peers, and the problems still exist.

Second, they can’t find the talent they need. For the most part, this is also legit. I figure that there are 10 security and development security positions that are chasing a single qualified candidate. As I talked about in my last post, we need to solve this.

Despite the forces pushing against you, there are some recommended courses of action. CISOs should be able to capture metrics demonstrating risks and communicate them to executives and the board. Those are hard conversations but necessary if you’re looking to take on these issues as an executive team and reduce the impact on you and the development teams when stuff hits the fan. In many instances, the C-levels and the boards consider this a ploy to get more budget—that needs to be dealt with as well.

Actions that can remove some of this risk include continuous security training for software development teams. This is your first line of defense. Then you can establish realistic security milestones and a security road map. Also, it’s OK to be creative, such as offering financial incentives for security improvement.

Most CISOs can’t tell you what the plan is for maturing their security posture, and that becomes a core weakness. I understand that it’s hard to plan, and hopefully something will come to you during the next cloud conference, but this needs to be urgent, proactive, and specific to your needs. If you follow the trends here, you’ll fail, period.

It’s all about automation

Efforts should focus on accelerating devsecops. Everyone needs to be speaking the same language, creating a unified culture, and pushing for automation and tools integration. Automation is really key to creating repeatable security risk mitigation processes, from checking source code supply chains, to examining code for vulnerabilities, to verifying configurations that are about to go into products. You know, devsecops 101.

To carry out this automation, we need to first understand that security should be part of the development process from the planning stage onward. It’s systemic to everything, including architecture, application design, development, testing, and deployment. The fundamental mistake that gets us in trouble is thinking of security as something bolted on at the end of the development and deployment process.

Finally, nothing should be pushed to production without passing very specific security tests driven by automation. Security should be drop-dead simple because we’ve automated all security development features and checks before code is released to deployment. Humans should be automated right out of the mix, especially since we have few qualified people around and they seem to be missing some steps.

We can fix this one.