The DevOps.com stories enterprise IT leaders actually read.
Volume 342, Issue 4 · 8 articles
DevOps.com argues shift-left security can't handle AI-era risks that appear before any code is written.
DevOps.com argues that shift-left security, introduced in 2001 to catch problems early in development, no longer suffices in AI-driven environments, since AI introduces risk 'before a single line of code is generated' through prompts, untrusted agents, and malicious packages.
It cites research showing 100% of companies have AI-generated code yet 81% of security teams lack visibility into how AI is being used.
The article calls for replacing the traditional Software Development Lifecycle with an Agentic Development Lifecycle (ADLC) governing AI tools, models, and data access throughout development.
Required controls include visibility into shadow AI usage, guardrails against malicious packages and secret exposure, and auditable governance records for accountability.
DevSecOps works best when security engineers act as partners throughout development rather than gatekeepers at the final release gate.
The article argues that waiting until a final security review to catch vulnerabilities creates late-stage scrambles that slow every release, and that DevSecOps works best when security decisions happen continuously throughout development instead.
It outlines three points where a security team can act as a partner rather than a gate: before development, deciding what needs protection; during development, embedding actionable guidance and controls into tools developers already use; and at the point a vulnerability is found, jointly discussing risk and remediation.
Clear guardrails, actionable scanner results and defined ownership let developers resolve issues without unnecessary delays, while teams still need to define which findings must stop a release and how exceptions are tracked.
Package registries are shifting from post-install scanning to blocking malicious packages before installation.
Thijs Feryn explains how software supply chain security is moving from after-the-fact scanning to proactive, gate-based enforcement at the package repository level, driven by attacks like malicious axios versions and forged provenance on 42 TanStack packages.
Major platforms including npm, JFrog Xray, Sonatype, Cloudsmith, and Socket have converged on blocking packages before installation rather than detecting problems afterward.
This approach involves trade-offs between deep platform integration and vendor lock-in versus registry neutrality, plus concerns about developer friction.
As gate-based enforcement becomes standard, the article says the real differentiator becomes who owns the policy and where it runs.
DevOps.com describes traffic-based mocking that improves accuracy as upstream services deploy more often.
The article addresses how traditional hand-written mocks grow stale as upstream services evolve, widening the gap between test behavior and production reality. Its proposed alternative captures real service responses via recording sessions run against staging environments, automatically triggered by upstream deployments.
This traffic-based approach captures all returned fields including undocumented ones, identifies non-deterministic fields by comparing multiple captures, and surfaces behavioral drift as explicit diffs.
The result inverts the usual relationship between deploy frequency and mock accuracy: more upstream deployments produce more accurate mocks, making the method best suited to HTTP API dependencies.
A practitioner's lessons from building multi-cloud services: the real challenge is semantic differences between providers, not connectivity.
Drawing on experience building services across AWS, GCP and Alibaba Cloud, the author argues multi-cloud complexity comes less from basic connectivity and more from semantic differences in how providers behave, such as one returning a success response for deleting a nonexistent object while another returns a 404.
Building abstraction layers on official provider SDKs, rather than raw REST APIs, works better because the SDKs already handle request signing, retries and endpoint discovery, letting teams focus on normalization.
The piece recommends applying portability selectively: abstract standardized commodity services like compute, storage and messaging, but keep native integrations where a provider's specific capabilities offer real cost or competitive advantages.
DNS is core infrastructure that needs formal change management, tested redundancy, and strict access controls.
DNS is often ignored until it breaks, yet it underpins app connectivity, email, identity, and cloud workloads.
The article argues organizations need formal change-management processes for DNS edits, since a single record change can have a wide blast radius. It calls for actively tested secondary DNS and failover, regular audits against DHCP/IPAM/asset inventories to prevent DNS drift, and least-privilege write access to zones.
The overall message: DNS deserves the same governance and visibility as other critical infrastructure.
Old Azure DevOps Classic releases retain stale configs that can silently undermine a pipeline migration.
The article explains that Azure DevOps Classic releases act as snapshots, freezing task graphs, Helm names, image paths, and variable values at creation time -- so they keep working even after pipeline definitions are updated in a migration cutover.
This creates risk: an old release referencing a retired Helm name with --install could create a new installation instead of updating the current one, leaving orphaned Kubernetes resources.
To fully complete a migration, the author recommends inventorying pre-cutover releases, inspecting their stored tasks and variables rather than trusting current definitions, removing obsolete image repositories, and abandoning stale releases only after testing, since a green deployment alone doesn't prove old paths are dead.
DevOps.com argues human plan review can't scale against AI-agent-driven infrastructure change volume.
The author contends that manual plan review for infrastructure changes, once effective, is breaking down under the volume of changes generated by AI agents.
Plan review actually bundles four distinct jobs -- policy compliance, blast radius assessment, intent verification, and audit documentation -- that now fail together as volume grows.
The proposed fix is to redistribute these: automate compliance checks via policy engines, replace blast radius guesswork with hard constraints like TTLs and budget caps, keep humans focused only on intent verification, and generate audit trails as a byproduct of enforcement rather than of approval.
The goal is enforcement that works without requiring anyone to read every plan.
More from DevOps.com · All IT section newsletters · This week