BoostSecurity News, Press & Events

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.

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;

TL;DR: We've been quiet lately—despite recent Supply Chain drama—because we wanted a clearer picture before chiming in. Attacks on popular GitHub Actions (tj-actions/changed-files and reviewdog/action-setup) have shocked us, but not surprised us. They simply proved the point we had warned about. Alarmingly, reviewdog automatically promoted “typo-fixers” to maintainers overnight. Combine that with GitHub's audit logging gaps—attackers can update releases leaving no trace—and we've got a real mess. It’s time we reassess our threat models and demand better visibility.

TL;DR: Our deep dive into open source projects’ CI/CD systems has revealed that build pipelines can be just as vulnerable as any other link in the software supply chain. We found hundreds of zero days on open source projects’ build pipelines with our detection at scale and responsibly disclosed them. Jump to the Research at Scale section to learn more.