This article is based on reporting from TechRepublic and findings from the Oracle/KPMG “Cloud Threat Report 2020: Addressing Security Configurations Amidst a State of Constant Change,” conducted by Enterprise Strategy Group.
The State of Cloud Security: Still Dangerously Immature
A 2020 joint report from Oracle and KPMG painted a sobering picture of cloud security preparedness: 92% of IT professionals surveyed did not believe their organization was well-prepared to secure public cloud services. The survey, conducted by Enterprise Strategy Group, polled 750 cybersecurity and IT professionals across North America, Western Europe, and Asia-Pacific between December 2019 and January 2020.
The two most critical risks identified were over-privileged admin accounts and poor management of cloud secrets — including API keys, account credentials, and passwords. The report’s core message is clear: security in the cloud is failing not because of exotic attacks, but because of avoidable misconfigurations and cultural blind spots that DevSecOps practices are specifically designed to address.
Key Findings From the Cloud Threat Report 2020
The report surfaced several recurring themes across the organizations surveyed:
- Cybersecurity teams are consistently playing catch-up with cloud adoption.
- Fundamental cloud security concepts are not yet widely understood.
- Misconfigured cloud services are prevalent and represent the top security priority.
- Improving security requires changes to people and processes, not just tooling.
- Machine learning is increasingly viewed as a foundational cybersecurity technology.
Over-Privileged Accounts: The Biggest Misconfiguration Problem
Privileged cloud credentials have become the primary entry point for attackers. The report found that 59% of respondents had team members with privileged cloud accounts whose credentials were compromised via spear-phishing attacks. When attackers obtain privileged credentials, they can pivot to additional cloud secrets and from there access databases, object stores, and other sensitive services.
The top misconfigured cloud services, ranked by respondents, were:
- Over-privileged accounts — 37%
- Exposed web servers and server workloads — 35%
- Object store data not secured via access control lists — 34%
- Lack of multi-factor authentication (MFA) — 33%
- Disabled logging for cloud activity audit trails — 31%
The report recommends implementing least-privilege access policies across all cloud environments. In multi-cloud setups, this is particularly challenging due to the complex many-to-many relationships between users, accounts, and cloud platforms — but it remains essential.
Cloud Secrets Stored in Dangerous Places
A closely related problem is where cloud secrets — keys, tokens, passwords — end up being stored. Development teams moving fast frequently prioritize delivery speed over security hygiene, leaving secrets in plaintext in locations that are far too accessible. Survey respondents reported secrets being found in:
- Stored on servers — 59%
- In source code repositories — 55%
- In public cloud object stores — 54%
- Embedded in HTML code — 31%
The report identifies this as a direct consequence of competing priorities: development velocity versus security discipline. The recommended solutions are implementing least-privilege policies combined with a hardware security module (HSM) or a dedicated secrets vault — such as HashiCorp Vault or a cloud-native equivalent — to manage and rotate secrets programmatically rather than storing them in plaintext.
DevOps Is Mainstream — But Security Integration Is Lagging
One genuinely positive finding from the report is that DevOps adoption has moved well beyond cloud-native startups. Only 6% of respondents said they had no plans to adopt DevOps, while nearly one-third had already implemented it, almost another quarter planned to do so within 12–24 months, and a further third expressed interest.
The problem is that security integration into those DevOps workflows is significantly behind. Just over one-third of respondents said their organization had already integrated security into their DevOps processes. The majority are still treating security as a downstream concern rather than embedding it into the design and build phases — a missed opportunity that leaves known vulnerabilities unaddressed until it is costly to fix them.
What DevSecOps Actually Means in Practice
DevSecOps is not a product — it is a cultural and procedural shift that embeds security into every phase of the software delivery lifecycle. The report describes this as “shifting security left”: moving security testing, policy enforcement, and threat modeling into the development and build phases rather than bolting it on at the end.
To build a DevSecOps pipeline that automates security controls through the CI/CD toolchain, organizations should look at integrating security into:
- Software Development Lifecycle (SDLC) tools, including IDEs with security linting and static analysis plugins.
- Source Code Management (SCM) repositories — with automated secret scanning (e.g., git-secrets, GitHub Advanced Security) to catch credentials before they are committed.
- Automated build tools — incorporating static application security testing (SAST) and dependency vulnerability scanning in CI pipelines.
- Agile project management systems — treating security requirements as first-class backlog items alongside features.
- Collaborative messaging platforms — enabling security alerts and incident notifications to flow directly to development teams.
According to the report, 46% of respondents cited “baking security into every stage of the continuous delivery toolchain” as the most important reason to adopt a DevSecOps approach. Collaboration and efficiency were ranked next, followed by compliance requirements.
Security as a Shared Responsibility, Not an Afterthought
The report’s most important cultural insight is that cloud security cannot succeed as a siloed function. When security is the responsibility of a single team operating at the end of the delivery pipeline, it becomes a bottleneck and an afterthought. Effective DevSecOps requires security to be treated as a shared business requirement — understood and acted on by developers, operations engineers, and security professionals alike.
Practically, this means:
- Training developers to understand the security implications of how and where they store secrets.
- Providing guardrails (automated policy checks, secrets managers, IAM templates) rather than just guidelines.
- Making security metrics visible in the same dashboards where delivery metrics are tracked.
- Conducting threat modeling during sprint planning, not during a separate security review cycle.
Summary
The 2020 Oracle/KPMG Cloud Threat Report makes clear that cloud security failures are largely self-inflicted: over-privileged accounts, secrets stored in source code, disabled logging, and absent MFA are all fixable problems. The barrier is cultural and organizational, not technical. DevSecOps provides the framework to close these gaps by integrating security into the same workflows, pipelines, and tools that development and operations teams already use. Organizations that treat security as a bolt-on will continue to fall behind — those that shift it left into everyday engineering practice will be in a materially stronger position.
Survey methodology: Data was collected via an online survey by Enterprise Strategy Group of 750 cybersecurity and IT professionals from private- and public-sector organizations in the US, Canada, UK, France, Australia, Japan, and Singapore, between December 16, 2019, and January 16, 2020. Respondents were required to be responsible for evaluating, purchasing, and managing cybersecurity technology and to have high familiarity with their organization’s public cloud usage.