Malik Haidar is a veteran in the field of cybersecurity, having spent years in the trenches of multinational corporations bridging the gap between deep technical intelligence and executive strategy. His perspective is particularly vital now, as we navigate the fallout of the GHAPPIER campaign, an attack that turned our own security innovations—like OIDC and Sigstore—against us. This discussion delves into the limitations of provenance-based security, the rapid manipulation of automated CI/CD workflows, and the evolving use of decentralized blockchain technologies for command-and-control infrastructure. We also explore the connection between GHAPPIER and the broader PolinRider campaign, assessing how credential harvesting continues to be the primary gateway for supply chain compromises.
The GHAPPIER campaign successfully exploited npm’s trusted publishing, which many of us viewed as a gold standard for security. How does this breach shift our understanding of OIDC and Sigstore’s role in a secure supply chain?
It’s a sobering reminder that provenance is about the ‘where,’ not the ‘what.’ When the attacker took over the @dforge-core/dforge-mcp maintainer account for those 105 minutes on September 9, they didn’t break Sigstore; they used it exactly as intended to validate a malicious build. The 0.2.21 release carried a valid attestation that is still sitting in Sigstore’s public log today, effectively giving a legitimate stamp to a 99KB file containing a dangerous loader. We have to realize that because the registry trusts the repository’s CI identity, having push access is functionally identical to having publish access. This incident proves that even the most rigorous cryptographic signatures cannot protect you if the source itself has been corrupted by a stolen key.
Looking at the timeline, the attacker spent only 14 minutes between modifying the workflow and publishing the loader. What can we learn from how they manipulated the GitHub Actions environment?
The speed was surgical and highlights a major blind spot in how we monitor CI/CD pipelines. They modified just three lines of code to ensure any push to the main branch would trigger the release workflow, then waited less than a quarter of an hour to rewrite that workflow for unattended publishing. This brief window is where the real damage happened—once the automation took over, the human element was removed, and version 0.2.21 was shipped to the public. It’s a gut-wrenching feeling for a maintainer to realize their project was compromised and a malicious version was live for 35 minutes and 38 seconds without a single alarm bell ringing. We need to start treating any change to a release workflow’s trigger block as a high-priority security event that requires immediate, manual verification.
One of the most striking details of this campaign is the use of Ethereum transactions for configuration. How does this move toward decentralized infrastructure change the game for security teams trying to neutralize a threat?
It’s an incredibly clever and frustrating tactic that leaves incident responders swinging at ghosts. By reading configuration data from an empty Ethereum transaction that cost a mere $0.20, the attackers eliminated the need for traditional command-and-control domains. There is no domain to suspend, no hosting provider to subpoena, and no central server to seize; the instructions are etched into a public, immutable ledger. I’ve seen teams scramble to find a C2 IP address only to realize the “phone home” is just a blockchain query, which makes the loader nearly impossible to “kill” in the traditional sense. This forces us to move away from blocking external IPs and instead focus on sweeping for internal artifacts, like the specific one-line loader that initiates the four-stage chain.
The GHAPPIER loader has been linked to the PolinRider campaign, which some attribute to state-sponsored actors. Based on the 65 public repositories and 22 accounts affected, how would you characterize the scale and intent of this operation?
The scale is significant, with at least 73 infected files identified across various platforms, suggesting a highly organized credential-harvesting machine. While some researchers point to North Korea, the reality is that the methods—like infecting developer machines with malicious extensions—are becoming standardized among top-tier threat actors. This isn’t just about stealing data from one company; it’s about poisoning the well of the entire open-source ecosystem to gain long-term, quiet access. We haven’t seen a massive corporate compromise from this specific campaign yet, but the fact that the infrastructure remained active for five days after the initial discovery shows a high level of confidence and persistence. It’s a psychological game as much as a technical one, knowing that your stolen credentials could be used to push a general-purpose remote shell that deletes itself from the disk as it executes.
What is your forecast for supply chain security?
I expect we will see a significant shift toward “hermetic” builds where even the build environment itself is scrutinized for any deviation from a known-good state. In the next few years, the battleground will move from verifying the identity of the publisher to verifying the integrity of the code changes themselves through automated behavioral analysis before they ever hit the CI/CD pipeline. We will also likely see a crackdown on the use of blockchain for C2, with more organizations blocking outbound traffic to public nodes unless there is a specific business need. Ultimately, the industry will have to accept that “trusted publishing” is only the first step and that true security requires a zero-trust approach to every single commit, regardless of who signed it.
