Skip to main content

Posts

Continuous Security in DevSecOps: Moving Beyond One-Time Testing 

Waiting for a single annual pentest to secure your application is like locking your front door only once a year and hoping for the best. In an era where  133 new vulnerabilities  are reported every single day, relying on periodic snapshots leaves your organization exposed to evolving threats for months at a time.   This approach is no longer just risky; it is a significant financial liability. Data from the  IBM Systems Science Institute  highlights that fixing a bug in production costs 100 times more than catching it during the initial design phase. For modern teams, the ‘window of vulnerability’ between tests is where attackers find their greatest opportunities.   Transitioning to continuous security in DevSecOps is the only way to close this gap. By embedding automated validation into your CI/CD pipeline, you move from a reactive ‘checkbox’ mentality to a proactive, resilient posture. This guide explores how to move beyond one-time testing to build a defense that evolves as fast a...
Recent posts

Why Senior Engineers Still Do Manual Work in Highly Automated Environments

Automation has been part of enterprise IT for many years, and in many environments, it has grown into an extensive network of interdependent workflows that keep routine operations running smoothly. Scripts provision accounts, automated workflows manage cloud resources, orchestration tools coordinate ITSM processes, and AI-driven tools help employees across the organization complete tasks more efficiently. On paper, this level of automation should allow the most experienced engineers to spend less time on routine operational work and more time on architecture, optimization, and long-term improvements. In practice, however, many teams experience the opposite. Even in highly automated environments, senior engineers are frequently pulled back into day-to-day operational tasks. They are asked to rerun failed jobs, correct permissions, verify provisioning results, or investigate why an automated workflow behaved differently than expected. Instead of focusing on higher-value work, they bec...

Open Source Contribution is About More Than Just Altruism 

Open source software is a foundational pillar of modern technology. From operating systems and databases to cloud infrastructure and developer tooling, it is embedded across nearly every layer of the stack. Most organizations rely on it in meaningful ways, often without fully accounting for how central it has become to their ability to build, scale, and operate And yet, for all its ubiquity, contribution to open source remains uneven. Many organizations still treat open source as something to consume rather than something to participate in. It is pulled into internal systems, adapted, and relied upon, but the relationship often stops there. A  new   report by the Linux Foundation   found that 28% of organizations say they use but do not contribute to open source software at all—that’s over a quarter of all organizations that are not contributing whatsoever. And for those who do, the degree to which they contribute may vary significantly.   Within the open source world, that dynamic ...

GitHub’s Spec Kit Puts the Spec Back in Software Development

If you’ve spent any time working with AI coding agents, you know the routine. You describe what you want. The agent generates code that looks right. You run it. It breaks — or worse, it works but solves the wrong problem. This frustrating pattern has earned a name: Vibe coding . You give the AI a vague idea and hope it guesses correctly. For quick prototypes, that’s fine. For production software, it’s a real problem. GitHub’s answer is Spec Kit — a new open-source toolkit for spec-driven development that provides a structured process to bring spec-driven development to your coding agent workflows with tools including GitHub Copilot, Claude Code, and Gemini CLI. The core idea is simple: Write the spec first. Specs as the Source of Truth For decades, code has been king. Specifications served code — they were the scaffolding we built and then discarded once the “real work” of coding began. We wrote PRDs to guide development, created design docs to i...

When Should a DevOps Agent Act Without Human Approval? 

Every team deploying AI agents in DevOps eventually faces the same design question, and it’s more consequential than it first appears: H ow much should the agent do on its own? The question sounds like a settings dial — more autonomy here, less there. In practice, it is a governance question, an engineering question, and an organizational trust question bundled together.   This article gives you a framework for thinking through the autonomy decision — what factors actually determine where on the copilot-to-autopilot spectrum a specific action should sit, and how to build the guardrails that make the decision defensible.   The Spectrum Isn’t Binary   The framing of “ human in the loop vs. fully autonomous” is too coarse to be useful in practice. Real DevOps agent deployments live somewhere on a more granular spectrum:   Level 0 — Observe only : The agent watches and logs. No output to humans, no actions. Used for baselining and evaluation before deployment. ...

NetDevOps Isn’t Stalled, it’s Stuck on the Wrong Problem 

While it is true that network engineers are taking on NetDevOps roles to advance stalled automation efforts,  the barrier to NetDevOps isn’t technical; it’s people.   The 44% Problem   The  2025 State of Network Automation Survey  from the Network Automation Forum, which gathered responses from 681 network professionals across 58 countries, paints a clearer picture. When asked about barriers to automation, only 10% cited technical challenges. Meanwhile, 44% pointed to  people  problems: Skills gaps, organizational dysfunction, cultural resistance and yes, sometimes, just personalities that don’t mesh.   Let that sink in: The tools work. Python is mature. Ansible is everywhere. Source-of-truth platforms are production-ready. The tech isn’t the bottleneck — people are — and this aligns with something else the recent NetDevOps article touched on: Nearly half the organizations have no formal measurement of automation success. You can’t fund what you can’t prove, and you can’t prove...