Devsecops

Kubernetes 1.37, named Garhwal, was released on August 26, 2026. It contains 67 enhancements, with 16 reaching stable status. The security story is clear. Kubernetes 1.37 strengthens workload identity, trust distribution, and SELinux enforcement today. It also introduces early capabilities that point to better policy protection, safer writable storage, and more resilient recovery tomorrow. For customer decision-makers, the long feature list is not the point. The important question is whether the release helps organisations protect customer data and keep critical services trustworthy. These six features are the most useful answer. ...

One of the most important topics my team has been following this year is designing and implementing a SOC service for cloud-native workloads at ReeVo. We started with the preventative layer. We designed and tuned a solid set of posture rules through our CNAPP solution, covering misconfigurations, risky privileges, and known bad patterns across our clusters. The platform also gives us runtime-security capabilities to identify suspicious behaviour as it occurs. That part is working well. ...

If you make, distribute, integrate, or buy software and connected products in the European Union, you should assess whether the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) applies. The CRA entered into force on 10 December 2024 and, as a regulation, does not need national transposition. Its main product obligations apply from 11 December 2027, while manufacturer reporting duties start on 11 September 2026. The OpenSSF 2026 CRA Awareness and Readiness Report, published by The Linux Foundation, surveyed 843 organizations and analyzed more than 12,000 open source projects. It points to a material readiness gap. It is useful evidence of what surveyed organizations are experiencing, not a measure of the whole industry. ...

It is a Sunday morning in August, the kind of weekend where the plan is coffee, a quiet walk, and maybe some reading that has nothing to do with work. Instead, I am three articles deep into a Linux kernel vulnerability write-up, taking notes, and mentally drafting a threat model. The notification came in on a weekend, and when something with this much claimed impact lands, it is worth investigating even if your calendar says otherwise. ...

The OWASP GenAI LLM Top 10 2026 was published on August 3, 2026. I am still learning my way around AI security, and I read OWASP Top 10 lists because they are the closest thing the industry has to a consensus map. They are not academic papers. They become the basis for threat models, security review checklists, and procurement questions. The GenAI edition specifically maps the risks that matter when you build applications around large language models. ...

Artificial intelligence is becoming part of daily software delivery, often before it becomes part of the organisation’s security architecture. This creates Shadow AI: AI tools, models, agents, extensions, or integrations used without formal approval, ownership, risk assessment, or monitoring. For executives, Shadow AI is not primarily a “developers using ChatGPT” issue. It is an enterprise-risk issue: ungoverned AI can gain access to source code, intellectual property, credentials, customer data, cloud environments, and deployment workflows. When AI systems are allowed to call tools or take actions, they must be treated as new non-human identities with access rights, not simply as productivity software. ...

It’s 2026 and I still get the same question from customers and colleagues: we already encrypt our secrets with git-crypt (or SOPS, or sealed-secrets), why do we need a full secrets manager on top of that? I hear it from platform teams that are otherwise mature, from developers who are genuinely trying to do the right thing, and from managers who see a centralized secrets manager as one more piece of infrastructure to buy, run, and justify. ...

Like most people in this industry, I spend a good part of my week in meetings: vendor evaluations, customer calls, technical deep dives on cloud-native projects. And like most people, I want minutes out of them without spending an hour writing them myself. The obvious answer in 2026 is “send the recording to an AI service”. For me, that answer is wrong by definition. Those recordings contain customer names, security architectures, commercial terms, gap analyses. As a security team leader, I cannot be the person who enforces data-handling policies on everyone else and then ships a customer’s security posture to a third-party API for convenience. ...

This is the third article in my “Back to Basics” series. The goal is simple: take something modern engineers interact with daily through abstractions, and explain what is actually happening underneath. In the first article, I hardened an SSH daemon and explained why the defaults are insecure. In the second, I showed that containers are ordinary Linux processes wrapped in namespaces and cgroups. This article applies the same approach to TLS: strip away the abstractions, read the raw structures, and understand what the tooling is doing on your behalf. ...

It’s 2026 and I still receive questions from customers and colleagues about why they should adopt a hardened container image catalog, why it matters, and how to justify the investment internally. I hear it from security engineers, from architects, from technical leads at companies that are otherwise doing serious work on their security posture. The honest answer is short: European regulations like DORA and NIS2 require it, and from a purely technological standpoint it is the logical evolution of how we have always managed infrastructure. Both arguments stand independently. Together they leave no room for debate. ...