Supply-Chain-Security

On 19 October 2026, a supply chain compromise replaced GitHub release binaries of the official OVHcloud CLI (ovhcloud-cli) with a credential stealer for about ninety minutes. Anyone who installed from GitHub, Homebrew, or the project’s install script in that window could have received malware instead of a cloud tool. The source repository was clean. The build pipeline was clean. The files on the release page were not. OpenSourceMalware reconstructed the incident: timeline, how the assets were swapped, how the malicious build was identified, GlassWorm indicators, hashes. OVHcloud published a security advisory the next day, pulled the bad files the same afternoon, and shipped a clean immutable v0.16.0. ...

Javier Martinez published a sharp piece on September 24, 2026: Why are SBOMs failing to stop supply chain attacks? I agree with his analysis. I recommend reading it before continuing here. TLDR of the Sysdig Article Martinez starts from a simple idea. An SBOM plus signatures and attestations should give us attribution (who built it), provenance (where it comes from) and content (what is inside). In a Kubernetes flow that means verifying attestations before deploy, then generating and signing your own SBOM when you ship. ...

We spend an enormous amount of time trying to secure software. We run SAST. We scan dependencies. We scan container images. We run IaC scanners. We check Kubernetes configurations. We monitor runtime behaviour. We build SBOMs. We integrate everything into CI/CD and create dashboards full of vulnerabilities, CVEs and security findings. And yet sometimes the most interesting security problem is not a vulnerability in our software at all. Sometimes it is a placeholder. ...

I have been preparing talks for DevSecOps Day in Bologna this October, and I keep landing on the same sentence: if your shift left story starts at the pipeline, you are already late. In most orgs, shift left still means moving SAST and SCA earlier in CI. Signed images and policy as code are useful. None of them help if the first credential theft happened in the editor, on a laptop, while someone was trying to be a good engineer. ...

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. ...

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 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. ...

The Problem We Have Today Open source security is no longer limited by finding vulnerabilities. It is limited by coordination. Modern software depends on thousands of open source components: libraries, container images, build tools, package managers, CI/CD actions, and infrastructure projects. When a serious vulnerability appears, many teams still struggle with basic questions. Question Why it is hard Where is the vulnerable component running? SBOMs and inventories are often incomplete. Who owns the remediation? Dependencies cross teams, vendors, and platforms. Can we patch fast enough? Testing, release windows, and legacy systems slow everything down. What if no clean patch exists yet? Teams need mitigations, not only advisories. AI makes this harder. Frontier models can inspect code, reason across dependencies, and find chained vulnerabilities faster than traditional disclosure processes were designed to handle. Discovery is accelerating. Exploitation windows are shrinking. ...

A few months back I saw a post circulating on LinkedIn about a developer who had been targeted by a fake recruiter. The person had been invited to a “technical assessment,” cloned a repository, and ran the code provided as part of the interview. What followed was a silent drain of every credential stored on their machine. I remember reading it and feeling a specific kind of disgust, not just at the technical sophistication of the attack, but at the deliberate choice to weaponize something as emotionally charged as a job search. ...

It Happened Again On April 22, 2026, the official Bitwarden CLI npm package (@bitwarden/cli) was compromised. For roughly 90 minutes, between 5:57 PM and 7:30 PM ET, anyone who ran npm install @bitwarden/cli received a malicious package. Around 334 developers did exactly that. The attackers did not break into Bitwarden’s npm account directly. Instead, they hijacked a GitHub Actions workflow in Bitwarden’s CI/CD pipeline and weaponised npm’s Trusted Publishing mechanism to push a poisoned release. Trusted Publishing is OIDC-based and requires no stored credentials: it was introduced as a hardening measure after credential-based attacks. It became the entry point. ...