Cloud native adoption increasing security concerns

Cloud native adoption has both transformed the way organizations build modern applications and resulted in increased security threats and concerns, according to a research by Snyk.

Most notably, the report found that:

• More than half of companies surveyed experienced a security incident due to misconfiguration or a known vulnerability in their cloud native applications
• Developers are three times more likely to view security as their responsibility versus their security peers and,
• Deploying automation makes it 17 times more likely that security tests run daily or more frequently.

“We’re at a pivot point in terms of the evolution of both the developer’s role as well as a transformation within the security industry as a whole,” said Guy Podjarny, President, Snyk.

“As this latest research demonstrates, enterprises that choose to empower their development teams with the right security tools will ship their applications faster and safer than their competition, best positioning them to lead their industries in the coming decade.”

56% experience misconfiguration or known vulnerability incidents

Cloud native adoption changes the way organizations defend against cloud threats, with misconfigurations and known vulnerabilities distinctly emerging as primary concerns. Key findings show:

• 60% of respondents have increased security concerns since adopting cloud native.
• Misconfigurations were noted as the biggest area of increased concern (over half of respondents stated it’s now a bigger problem since moving to a cloud native platform).
• Known unpatched vulnerabilities (38%) are responsible for the greatest number of security incidents in their cloud native environments.

Developers three times more likely to view security as their responsibility

Developers today require solutions that enable them to build security into the whole application – from code and open source to containers and cloud infrastructure, and they now have the opportunity to take on a pivotal security leadership position within their organizations as their role evolves to take on greater authority and autonomy.

Significant findings indicate greater security ownership is now being embraced by development teams faster than security teams are willing to let go of their own historic role in the traditional process. For example:

• Respondents in security roles were almost three times more likely to attribute security ownership to their team versus their development team counterparts.
• 36% of developers admit they feel responsible for the security of their cloud native environments.
• At the same time, less than 10% of respondents in security roles believed any security responsibility lay with developers.

Deploying automation makes it 17 times more likely security tests run daily

Adopting a broader and deeper approach to cybersecurity by embedding security tools and best practices throughout the software development lifecycle is the make or break factor in achieving cloud native application security success.

Report findings demonstrate that companies with high levels of cloud native automation also have greater adoption of security testing. Companies who automate were also twice as likely to implement security testing and twice as likely to adopt static application security testing (SAST) and Software Composition Analysis (SCA) tooling into their development lifecycles.

Automation also makes it easier to conduct more frequent testing, allowing for vulnerabilities to be identified and fixed quicker:

• Nearly 70% of respondents with high levels of deployment automation were able to test their security daily (17 times more than respondents who had no deployment automation, with 60% of those only testing their security monthly).
• More than 72% of respondents with high levels of automation have an average time to fix vulnerabilities of less than one week, with 36% having an average of one day or less.
• Automated testing is also a key enabler of visibility into security issues, with 28% of organizations with low levels of automation acknowledging they don’t currently know how long it takes them to fix issues.