Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

AI-accelerated attacks are redefining the threat landscape, but many of them still rely on one of the oldest tactics in the book: exploiting known vulnerabilities. The difference today is speed. Vulnerabilities that once took skilled hackers months or weeks to exploit can now be weaponized in hours or minutes. This acceleration is forcing organizations to rethink how they identify and remediate risk.

Many observability platforms authenticate to Microsoft Azure by using client secrets. Teams must create, store, and periodically rotate these secrets to keep receiving the telemetry data that they need. This recurring maintenance adds operational overhead and increases the risk of ingestion outages that occur when secrets expire.

On June 1, 2026, the Kubernetes Security Response Committee updated the records for four older CVEs that remain unfixed. The corrections may cause vulnerability scanners to report these CVEs in clusters where they weren’t previously detected. But an affected version doesn’t necessarily mean that a cluster is exposed. Each unfixed Kubernetes CVE depends on a particular combination of permissions, cluster features, and network access.

Software that runs inside customer-managed infrastructure creates a particular challenge at the FedRAMP High baseline. It still has to meet the applicable security and compliance requirements, even though the vendor does not control the surrounding operating system, libraries, network configuration, or maintenance practices. For Datadog, that challenge centers on the Datadog Agent, which runs directly on customer-managed hosts to collect logs, metrics, traces, and security signals.

Google Security Operations (SecOps) is Google Cloud’s security operations platform for detecting, investigating, and responding to threats across large volumes of security telemetry. To make that telemetry useful across sources, Google SecOps uses the Unified Data Model (UDM), a common event schema that provides a consistent structure for security logs. But logs from firewalls, endpoints, identity providers, and other sources all describe and format security events differently.

Security engineers using Cloud SIEM spend their day-to-day investigating signals, tuning detection rules, managing suppressions, running historical jobs across interconnected workflows, and more. Agents are becoming a practical way to navigate that complexity, and we built a set of security tools for the Datadog MCP Server to support them. Cloud SIEM is only one part of a broader cloud security ecosystem, so the Security MCP toolset has to grow across many teams and products.

Apigee X is Google Cloud’s API management platform. Software and platform teams use it to secure, publish, and govern the APIs that internal services, partners, and external developers depend on. Apigee X sits in the request path for that traffic, so a latency spike or a rise in policy errors reaches API consumers before most other signals do. Watching proxy traffic, latency, and security posture usually means jumping between Apigee analytics and separate infrastructure tools.

AI agents can reason through tasks, call tools, and adapt their next steps based on intermediate results. That flexibility is useful for building agentic applications, but it also creates security risk at runtime: A prompt injection attempt can change the agent’s instructions, a malicious request can try to exfiltrate sensitive data, and an unsafe tool call can lead to an action that the application owner did not intend.

Static application security testing (SAST) tools are intentionally conservative. Traditional scanners identify code that appears exploitable and flag the snippet for review, even when protections elsewhere in the application prevent exploitation. Although that approach helps teams catch vulnerabilities, it also creates false positives that consume developer time, slow remediation efforts, and make future alerts easier to dismiss.

Memorandum M-26-14 from the Office of Management and Budget (OMB) marks a significant evolution in federal cybersecurity guidance, establishing a new risk-based framework for logging and network visibility across the United States federal government. The memo replaces the prescriptive requirements of Memorandum M-21-31 with an approach that emphasizes continuous monitoring, threat detection, investigation, and forensic readiness.