Datadog's State of Cloud Security 2026 report, released in November, has sparked practical and direct questions in security circles. The key finding: the median number of high or critical vulnerabilities in cloud workloads jumped from four in May to 16 in November. This increase is linked to frontier AI, notably the release of Anthropic's Mythos model. The data is based on software composition analysis of third-party libraries across thousands of organizations.
Here are the six most common questions, with clear answers.
Q1: Is a median of 16 high or critical vulnerabilities per workload a real problem, or just a bigger CVE database?
It's a real problem. The growth in the CVE database is not just theoretical; it affects actual applications in cloud environments. A median means half your workloads likely have more than 16 vulnerabilities.
Shift your focus from reducing vulnerability counts to controlling the blast radius. You can't patch everything, so limit what a compromised workload can access. Use scoped roles, network segmentation, and avoid standing access to production data. CIS Controls v8.1 (Control 7, Continuous Vulnerability Management) provides a prioritization framework. Pair it with exposure context to prioritize fixes for internet-facing workloads with reachable vulnerable code paths.
Q2: Why would anyone run a dependency version released less than 24 hours ago?
Automation is the main reason. Datadog found that 60% of organizations run versions released less than 24 hours earlier, appearing in 21% of cloud applications. This is due to auto-update settings, unpinned version ranges, and CI pipelines that pull the "latest" version on every build.
This matters because hijacked libraries are often identified and contained within hours. A 24-hour-old package hasn't had that vetting. Implement a dependency cooldown: a waiting period before new versions enter your environment. Set this in your package manager or artifact proxy, pin versions in lockfiles, and create an exception path for emergency security patches so the cooldown doesn't block real fixes.
Q3: We have hundreds of dependencies. How do we manage that without a full-time team?
Datadog's data highlights the challenge: 149 dependencies per cloud workload on average, and 568 across an organization. Manual review isn't feasible.
Use three controls. First, an internal artifact repository or proxy to enforce cooldowns and block known-bad packages. Second, generate a Software Bill of Materials (SBOM) in your build pipeline to quickly identify where libraries are used. Third, automate Software Composition Analysis (SCA) gating on pull requests with pre-agreed severity thresholds. For regulated environments, map this to NIST SP 800-53 supply chain controls (the SR family) for audit evidence.
Q4: Where are long-lived credentials actually hiding?
Start with two areas flagged by Datadog: cloud-hosted AI inference services and CI/CD pipelines. Nearly half of organizations using Gemini have long-lived Gemini API keys. Also, nearly 30% of AWS IAM users and Google Cloud service account users have access keys older than three years.
These aren't just hygiene issues. Tools like Pacu, Pathrunner, and TruffleHog can find over-permissioned credentials and exposed keys at scale. Long-lived keys are prime targets for attackers. Run your own secret scanner across repositories, build logs, and container images before someone else does.
Q5: What does the move to short-lived identities look like in practice?
Replace static keys with the calling workload's own identity. For AI services, use IAM roles, managed identities, or service accounts with federated credentials, rather than separate long-lived keys.
For CI/CD, use OIDC federation between your pipeline and your cloud provider so jobs receive temporary tokens scoped to that run. Start by inventorying keys older than 90 days, rank by privilege, migrate the highest-privilege and internet-adjacent ones first, then enforce a policy that blocks new static keys. NIST SP 800-63 is a useful reference for authenticator lifecycle and assurance.
Q6: How do I explain this to the board without it sounding like another scary stat?
Don't start with the fourfold increase. Focus on what you're changing. Boards respond to decisions and measurable improvements, so present it as two programs with owners and Key Risk Indicators (KRIs).
For dependencies: track the percentage of production workloads covered by a cooldown policy and an SBOM. For credentials: monitor the count and age of long-lived keys, aiming for a downward trend. Emphasize that you're designing for the assumption that some applications will be compromised, and you're limiting what that compromise can affect. This ties to risk appetite, not just alarm.
If you're using a Virtual CISO (vCISO) or Fractional CISO, make these programs explicit deliverables with dates, rather than leaving them in a general "cloud security improvements" category.
Where to go for more
Read Datadog's State of Cloud Security 2026 for the full dataset and recommendations on cooldowns and federated identities. For control mapping, start with CIS Controls v8.1 (Controls 5, 6, and 7 cover accounts, access, and vulnerability management), NIST SP 800-53 for supply chain risk, and the CIS Foundations Benchmark for your cloud platform's configuration baselines. If AI services are part of your environment, ISO/IEC 42001 offers a management system structure for governing them alongside the credential work above.
