BoostSecurity News, Press & Events

December 8th 2025, by François Proulx, VP of Security Research @ BoostSecurity.io

TL;DR: 2025 didn’t give us a new, magical Supply Chain vuln class; instead it gave us attackers who finally started reading our manuals. 

From Ultralytics’ pull_request_target 0‑day (where a BreachForums post indicates they used our own poutine scanner to find it) through Kong, tj-actions, GhostAction, Nx, GlassWorm and both Shai‑Hulud waves, the common pattern wasn’t typosquats but Pipeline Parasitism: living off CI/CD, maintainer accounts and developer endpoints using the same tools and patterns we published to defend them.

The vuln mechanics stayed boring: shell injections and over‑privileged tokens. But they were operationalized with worms, invisible Unicode payloads, blockchain C2, and even wiper failsafes.

Thankfully, platforms are finally improving, yet “pwn request” is here to stay; the only sustainable answer is to treat pipelines as production systems and publish future research assuming adversaries are our most diligent readers!

TL;DR: Malicious code caching, dangling commits, pseudo-versions stealthily pointing to backdoors... Go makes you just as vulnerable as other ecosystems to social engineering attacks, and can even help malicious actors cover their tracks. Go enables new manipulation techniques to subtly trick users into downloading malicious packages. In this article, we describe various attack vectors in the Go ecosystem, from social engineering to well-known attacks such as repojacking, domain hijacking, and dependency confusion. Go's ecosystem guarantees integrity, not trust.

TL;DR: A routine disclosure unraveled a class of Bot-Delegated Time-Of-Check to Time-Of-Use race conditions where helpful automation bots (often GitHub Apps) may sometimes promote untrusted code changes from a fork to a victim repo, enabling the insertion of a “side-door” malicious workflow.

Now generally available in our first major release: v1.0.

In our last post, we released the BoostSecurity Safe Package MCP server: a lightweight guardrail that lets coding agents check dependency safety before they install anything. That helps stop typosquats, malware-laced releases, and risky, unmaintained packages from ever reaching your machine.

Today, we’re taking the next step in developer supply-chain defense:

Meet the Poutine MCP Server

Poutine brings Model Context Protocol (MCP) superpowers to your editor/agent so it can analyze repos and build pipelines on demand, spot dangerous CI/CD coding patterns, and validate newly generated pipelines, all inline while you code.

In the previous post, we made the case that developers are big targets of attack these days. Hardly a week goes by without some malware slipping into the open source package ecosystem. Developers are affected when they directly (or transitively) download the package. 

TL;DR: Your trusty Dependabot (and other GitHub bots) might be an unwitting accomplice. Through "Confused Deputy" attacks, they can be tricked into merging malicious code. This doesn’t stop here. It can escalate to full command injection via crafted branch names and even bypass branch protection rules. Plus, we disclose two new TTPs to build upon previously known techniques.

After connecting with dozens of CISOs and CTOs, we've realized there’s a lot of diverging ideas around what software supply chain security even is. Even more so, the range of opinions around how to effectively protect against the unique and expanding kinds of risks is confusing to say the least. And while there are plenty of supply chain security standards around, and plenty of deeply technical supply chain security resources, there wasn't anything talking about it from a business risk level. So, we put together a resource for CISOs and CTOs that explores four categories of risks;

TL;DR: CI/CD remains a stealthy and soft target for supply chain attacks—especially via linters, formatters, build and test tools. This guide breaks down Living Off the Pipeline (LOTP) techniques, where attackers exploit CI tools already present and without modifying the workflow itself—using config files, plugins, and environment variables instead.

After connecting with dozens of CISOs and CTOs, we've realized there’s a lot of diverging ideas around what software supply chain security even is. Even more so, the range of opinions around how to effectively protect against the unique and expanding kinds of risks is confusing to say the least. And while there are plenty of supply chain security standards around, and plenty of deeply technical supply chain security resources, there wasn't anything talking about it from a business risk level. So, we put together a resource for CISOs and CTOs that explores four categories of risks;