DEVOPSdigest

"A stitch in time saves nine." We've all heard this proverb at least once or twice, usually from a parent or a teacher pointing out how we should have corrected a problem early to avoid having it grow into a bigger problem over time.

DevOps organizations have taken this lesson to heart. Most have adopted a "shift-left" mentality to catch code issues well before they reach production and get released into the wild. Organizations test earlier and embed security teams throughout an expanded DevSecOps process so they can build faster and be confident in the quality of the outputs.

"Shift left" is a worthwhile concept. It has encouraged organizations to think more proactively about software development. But, in practice, it has a few bugs of its own that still have to be worked out.

A recent survey commissioned by CloudBees revealed that shift-left strategies are popular — but at the same time problematic — for organizations. Overall, 83% of C-suite executives say the approach is important for them as an organization, and 77% say they are or probably are implementing a shift-left security and compliance approach currently.

The problem? 58% of C-suite executives report that shift left is placing a burden on their developers.

While anyone would agree that it's important to unearth defects and check that software meets customer requirements, putting more testing on developers' shoulders is reducing the time they can spend on value-added activities. Executives say their teams are spending 48% of their time on risk and technical debt, and less than 30% on innovation.

Part of the issue is that code development and testing processes have changed.

Today, companies write less than a third of the new code they use. Applications are built largely on open source, and environments, requirements and standards change quickly. There's a lot to sort out. Developers also have to run a lot more testing tools and deal with a growing stream of alerts. They have to separate real issues from false positives, figure out how to respond and prioritize their work. It's becoming harder and harder for teams to handle their tasks.

Security and compliance were also singled out as barriers to innovation. The CloudBees Global C-Suite Security Survey found that about half of the executives believe compliance and security processes (56%) and knowledge related to security and compliance (47%) is what is stopping their development team from spending more time on the activities they believe should be the priority. Specifically, they believe that security (75%) and compliance (76%) requirements hinder innovation.

What's needed is a new mindset and a fresh approach, one where security and compliance are continuous and actually speed innovation. This requires a system that runs continuously across the entire organization and software development lifecycle (SDLC), including production, comparing the digital estate against those policies and regulatory requirements.

The C-suite security report had some other interesting findings. Here are a few:

■ Risk management teams have it covered – Nine in ten C-suite executives say their risk management team has the tools, knowledge and expertise to build and/or maintain a secure software supply chain.

■ When it comes to tools, it's a mixed bag – Three in five executives say they have all, or mostly all, external tools for security and compliance issues, and 29% say they have a mix of internal and external tools.

■ When given the choice between speed and security, security wins – More than three quarters of C-suite executives say it is more important to be secure and compliant than fast and compliant.

To a great degree, companies' success will depend largely on their ability to deliver quality software. Among the many challenges they will face, one of the most important will be reconciling the promise of shift left with the needs for security, compliance and, most of all, innovation.