OWASP Top 10: Still the Most Cited List in Application Security
Roughly 84% of software breaches exploit vulnerabilities at the application layer, according to Verizon's 2026 Data Breach Investigations Report. Yet teams still ship code with broken access controls, hardcoded secrets, and misconfigured IaaS environments every single day. The OWASP Top 10 exists precisely because these are not exotic attack vectors — they are predictable, repeatable failures that organizations keep making.
If you are running a DevSecOps pipeline in 2026, the OWASP Top 10 is table stakes. Not a checkbox exercise. A living framework that should be embedded in your code review process, your CI/CD gates, and your infrastructure-as-code scanning. This guide breaks down each of the current OWASP Top 10 categories, maps them to real-world DevSecOps tooling, addresses the emerging OWASP Top 10 for LLMs, and explains how IaaS vs PaaS architecture choices affect your threat surface.
The OWASP Top 10 Categories — What Actually Matters in 2026
The OWASP Top 10 2025 edition — which shapes 2026 practice — consolidated several older categories and elevated others the community had underweighted. Here is the current list with commentary that matters to engineers shipping code today.
A01 — Broken Access Control
Still number one. Unchanged since 2021 and for good reason. This category covers everything from IDOR (insecure direct object references) to privilege escalation flaws where users access resources they should not. In microservices architectures, service-to-service trust assumptions create lateral movement paths that a traditional perimeter model would have blocked. Mandatory access policy enforcement at the API gateway and service mesh levels is the most effective control here.
A02 — Cryptographic Failures
Previously called Sensitive Data Exposure. The rename was more accurate. Weak TLS configurations, deprecated cipher suites, and plaintext transmission of personally identifiable information all fall here. In cloud-native deployments, misconfigured S3 bucket policies and unencrypted database snapshots are the most common manifestations. Automated IaC scanning with tools like Checkov catches these before they reach production.
A03 — Injection
SQL injection, LDAP injection, OS command injection — the classics never die. Modern frameworks have largely solved parameterized queries for greenfield applications, but legacy codebases remain full of vulnerabilities. NoSQL injection — particularly abuse of MongoDB's $where operator — is increasingly relevant as document databases proliferate in cloud-native architectures.
A04 — Insecure Design
This is the shift-left category. The OWASP team added it specifically to call out architectures that lack threat modeling from day one. You cannot patch your way out of a fundamentally broken design. Insecure design manifests when teams skip abuse case modeling, fail to rate-limit sensitive endpoints, or build authentication flows without considering brute-force scenarios. Threat modeling with STRIDE or PASTA at the design phase is the primary mitigation.
A05 — Security Misconfiguration
The category that keeps cloud security teams employed. Default credentials, permissive CORS policies, verbose error messages leaking stack traces, and unnecessary features enabled in production. In an IaaS cloud environment, this maps directly to overly permissive IAM roles, publicly exposed storage buckets, and missing network segmentation. A05 is the category most addressable through Policy-as-Code tooling like Checkov running in CI pipelines.
A06 — Vulnerable and Outdated Components
Log4Shell validated this category catastrophically. SBOMs (Software Bill of Materials) are now a regulatory expectation in some jurisdictions. Tools like Trivy and Grype scan container images for known CVEs, but the harder problem is knowing which vulnerabilities in your dependency tree are actually exploitable in your specific context. EPSS scores help prioritize here — a critical CVE in a library your code never loads is lower priority than a high-severity flaw you call on every request.
A07 — Identification and Authentication Failures
Weak passwords, missing MFA, broken session management. Session fixation attacks against JWT implementations are a recurring theme in bug bounty programs. The move to OAuth 2.0 and OIDC reduced some risks but introduced new attack surfaces around token leakage and redirect URI manipulation. Enforcing MFA across all human and service accounts and regularly rotating credentials are the baseline controls.
A08 — Software and Data Integrity Failures
This is the supply chain security category. CI/CD pipeline compromises, unsigned software updates, and deserialization vulnerabilities all land here. The SolarWinds and 3CX attacks are canonical examples of how catastrophic CI/CD compromise can be. If you are not verifying artifact signatures in your pipeline with Sigstore or Cosign, you are flying blind on supply chain integrity.
A09 — Security Logging and Monitoring Failures
Absence of evidence is not evidence of absence. Security logging failures do not cause breaches directly — they ensure breaches go undetected for months. IBM's 2026 Cost of a Data Breach report puts the average breach detection time at 194 days. Adequate logging, correlated alerts, and proper SIEM integration are the difference between catching an attacker in the first hour and reading about your incident in the press six months later.
A10 — Server-Side Request Forgery (SSRF)
SSRF attacks pivot through your application to reach internal infrastructure. Cloud metadata endpoints — AWS's 169.254.169.254, GCP's metadata server — are the prime targets. In IaaS environments, a successful SSRF can expose instance credentials with enough permissions to take over entire AWS accounts. Blocking outbound requests to metadata endpoints at the application and network layers is non-negotiable in any cloud deployment.
IaaS vs PaaS: How Your Infrastructure Choice Shapes OWASP Risk
This distinction matters more than most teams realize when mapping OWASP risk to remediation strategy. IaaS — Infrastructure as a Service — at its core means infrastructure you manage. Virtual machines, networking, storage. Your team owns the operating system and everything above it. PaaS abstracts the underlying infrastructure entirely, and you manage only the application runtime and code.
Take a concrete IaaS example: a Node.js API running on an EC2 instance. Your team owns the OS patching cadence, the network security groups, the IAM role attached to the instance, the container runtime if you are using Docker, and the application code itself. Every OWASP category can manifest. A05 misconfigurations at the OS level, A06 vulnerabilities in your node_modules, A10 SSRF exploiting the EC2 metadata service — the blast radius of a single misconfiguration is enormous because the attack surface spans multiple layers.
PaaS narrows the attack surface but does not eliminate it. A serverless function on AWS Lambda does not have an OS for you to patch, but it can still be vulnerable to injection (A03), broken access control (A01), and insecure design (A04). The shared responsibility boundary shifts, but application-layer OWASP risks remain fully in your court. Cloud Security Posture Management tools help map misconfigurations regardless of deployment model, though the remediation playbooks look very different between IaaS and PaaS environments.
In practice, most organizations run hybrid architectures — containerized services on managed Kubernetes alongside serverless functions and managed database services. That means your threat model needs to account for multiple shared responsibility boundaries simultaneously, with OWASP controls applied at each layer appropriately.
Checkov and Policy-as-Code for OWASP Alignment
Checkov is a static analysis tool for infrastructure-as-code — Terraform, CloudFormation, Kubernetes manifests, Dockerfiles, and more. It checks IaC configurations against a library of security policies, many of which map directly to OWASP Top 10 categories and CIS Benchmarks.
Running Checkov in your CI pipeline catches misconfigurations before they ever reach production. A few examples of what Checkov flags out of the box: S3 buckets without server-side encryption (A02), security groups with 0.0.0.0/0 ingress on sensitive ports (A05), ECS tasks running as root — a privilege escalation vector for A01 — and missing logging configuration on API Gateway (A09).
The real power is in custom policies. Checkov supports custom checks written in Python or YAML. Teams can encode organization-specific controls — such as requiring IMDSv2 on all EC2 instances to prevent SSRF-based metadata exfiltration — and fail builds automatically when those controls are violated. That is Policy-as-Code in practice, shifting OWASP compliance left into the development workflow rather than discovering violations post-deployment during a security audit.
Integrating Checkov alongside SAST tooling gives you a comprehensive shift-left posture: application code scanned for injection flaws and authentication weaknesses, infrastructure code scanned for misconfigurations and encryption failures — all before a single line of code is deployed to any environment.
Container Security and the OWASP Top 10
Containers introduce specific OWASP risks that deserve dedicated attention in any DevSecOps program. A06 (Vulnerable Components) is the most obvious — base images are frequently bloated with packages that carry known CVEs. Running docker pull python:latest and shipping it to production without scanning is security malpractice in 2026.
Container image scanning should be non-negotiable in any DevSecOps pipeline. Trivy, Grype, and Snyk Container all offer registry integration and CI pipeline hooks. The key metric is not just CVE count — it is exploitability. A critical CVE in a library your application never loads is lower priority than a high-severity flaw in a package you call on every request. Pairing CVE severity with EPSS scores gives you a prioritization signal based on real-world exploitation probability rather than theoretical risk.
Beyond image scanning, runtime security matters. Falco detects unexpected syscall behavior that could indicate container escape attempts or privilege escalation attempts (A01). Kubernetes Pod Security Standards enforce least-privilege container configurations at the cluster level — ensuring containers do not run as root, cannot escalate privileges, and have read-only root filesystems where possible.
If you are not auditing your Kubernetes RBAC configuration regularly, you are almost certainly carrying broken access control risks. Overly permissive ClusterRole bindings that grant cluster-admin to service accounts are one of the most common findings in Kubernetes security assessments.
The SAST layer complements container scanning — static analysis of your application code catches injection flaws, hardcoded secrets, and insecure cryptographic implementations before the container image is even built. Together, these controls cover A02, A03, A06, and A07 across both the application and infrastructure layers.
OWASP Top 10 for LLMs: The Emerging Attack Surface
The OWASP Top 10 for LLM Applications is a separate but increasingly critical framework as organizations deploy AI-powered features into production. The top risks include prompt injection — the LLM equivalent of SQL injection — insecure output handling, training data poisoning, model denial of service, and excessive agency where an LLM agent takes real-world actions it should not be authorized to perform.
Prompt injection deserves special attention. Unlike traditional injection vulnerabilities, it cannot be fully mitigated with parameterized queries or input sanitization alone. An attacker can embed adversarial instructions in user-supplied content that the LLM processes, potentially leaking system prompts, bypassing safety filters, or triggering unintended API calls. The attack surface extends to indirect prompt injection — malicious instructions embedded in documents, web pages, or database records that an LLM agent retrieves and acts upon without the user explicitly providing the attack payload.
AI Security Posture Management (AI-SPM) is emerging as a discipline specifically designed to address these risks — inventorying AI models and agents, auditing their permissions and integrations, monitoring for anomalous behavior, and enforcing least-privilege access for AI components. If your team is building on top of LLM APIs — whether OpenAI, Anthropic, Mistral, or self-hosted models — the OWASP LLM Top 10 should be part of your threat modeling process alongside the standard web application Top 10.
Integrating OWASP Top 10 into Your DevSecOps Pipeline
Theory is inexpensive. Here is what OWASP alignment actually looks like embedded in a modern CI/CD pipeline at each stage:
Pre-commit hooks: Secret detection catching A02 violations before credentials reach the repository. Tools like TruffleHog and Gitleaks are standard. Automated secret detection at commit time is the lowest-cost intervention with the highest blast-radius reduction — a leaked API key that never reaches Git history cannot be exploited from a compromised repository.
Pull request and merge gates: SAST scanning for injection flaws (A03), insecure cryptographic usage (A02), and authentication weaknesses (A07). Semgrep, CodeQL, and Snyk Code all ship rule sets explicitly mapped to OWASP Top 10 categories. Checkov IaC scanning runs here as well, catching A05 misconfigurations in Terraform or Kubernetes manifests added alongside application code changes.
Build stage: SCA (Software Composition Analysis) for A06 — scanning package manifests, generating SBOM artifacts, and blocking builds that introduce components with critical unpatched CVEs. Container image builds trigger Trivy or Grype scans against the assembled image before it is pushed to any registry.
Registry and deployment gate: Policy enforcement blocks images with critical CVEs, images running as root, or images missing required security labels. Admission controllers in Kubernetes — like OPA Gatekeeper or Kyverno — enforce runtime policies at deploy time, catching misconfigurations that slipped past earlier gates.
Runtime monitoring: Continuous vulnerability management correlates findings across SAST, SCA, container scanning, and infrastructure scanning into a unified risk view. CSPM tools monitor for cloud misconfiguration drift — configurations that were compliant at deployment but have been changed manually since. Runtime security tools watch for behavioral anomalies that could indicate active exploitation.
The goal is defense in depth across the pipeline. No single tool or gate catches everything. Layering controls at pre-commit, build, deploy, and runtime ensures that a finding missed at one stage is caught at another — and that your OWASP coverage does not depend on any single point of failure in your security toolchain.
Why OWASP Top 10 Compliance Is a Floor, Not a Ceiling
Here is the uncomfortable truth: fully addressing the OWASP Top 10 does not mean your application is secure. It means you have addressed the most common and well-documented vulnerability classes. Sophisticated attackers chain multiple lower-severity issues. They exploit business logic flaws that no automated scanner catches. They target your third-party integrations, your CI/CD pipeline itself, and your developers through social engineering.
The OWASP Top 10 is a minimum baseline. Pair it with structured threat modeling using STRIDE or PASTA, regular red team exercises, an active bug bounty program, and continuous compliance monitoring against frameworks like SOC 2, ISO 27001, or CIS Benchmarks. The teams that treat OWASP as a checklist are the ones that still make the breach news cycle. The teams that internalize it as a security culture foundation — building developers who instinctively think about broken access control and injection when they write code — those are the teams that reduce risk meaningfully over time.
Invest in developer security education alongside tooling. Automated scanners catch known patterns. Developers who understand why injection is dangerous write code that avoids the entire class of vulnerability, including novel variants no scanner has a rule for yet. Security champions programs, internal OWASP training, and secure code review practices compound over time in ways that tool purchases alone never do.
The OWASP Top 10 has been the most cited framework in application security for over two decades because the underlying problems are genuinely hard to eliminate at scale. Use it as a compass, automate as much of it as possible in your pipeline, and build the understanding into your engineering culture — and it becomes a genuinely useful forcing function for continuous improvement rather than another compliance box to tick each year.