PolinRider keeps expanding, and the postinstall still lands on your runner

Somewhere this quarter, a developer on your team will accept an interview that never happens. Answer questions from a hiring manager who does not exist. Clone a private repo for a coding challenge. Run a very real install. That is the funnel.

DevOps.com reports the North Korean-linked groups behind that pattern are expanding a campaign called PolinRider, pushing malicious packages into developer workflows via the long-running fake-interview scam. Cybersecurity vendors Socket and Rescana attribute the current wave to two DPRK-linked groups. Per DevOps.com, the campaign has escalated over the past several months.

Which part is actually new?

Not the shape. Fake-interview lures aimed at developers have been reported for a while, from roughly the same neighbourhood on the attribution map. Not the delivery vehicle either. Malicious packages inside developer workflows have been a Socket beat for a long time.

What DevOps.com is calling out is scale. The campaign is expanding, per the article. Two groups, per Socket and Rescana. Escalating for months, per the timeline the reporting gives us. That is a signal, not a technical revelation. The industry is telling you the funnel still works.

Reads short. That is because the specifics (which packages, which registries, which victims) belong in Socket's and Rescana's writeups, not a summary of a summary. Read the source if you need artifact names. The pipeline consequence does not need them.

The developer's laptop is a build stage

Here is the framing most orgs still skip. A malicious install on a laptop and a malicious install on your CI runner are the same install. The tarball does not know where it lands.

• The dependency the candidate ran on Wednesday gets pinned into the lockfile on Thursday.
• The lockfile does not remember how the entry got there, only that a resolved hash matched.
• The postinstall runs in whichever context installs the package next. On plenty of teams the next context is a shared runner sitting on more credentials than the workstation.

Any story where a developer executes attacker code without meaning to, on any hardware, is a supply-chain story. This one skipped a step. It aimed at humans, not packages.

Boring controls, still applicable

None of this is new. That is exactly why it is uncomfortable.

• Isolate untrusted installs. npm install, pip install, go get, whatever your ecosystem: run it in an ephemeral, network-restricted, credential-free sandbox. Not "a container". An ephemeral one that dies with the shell.
• Split the token that pulls dependencies from the token that publishes releases. If they are the same identity, the postinstall wins twice.
• Pin to a resolved digest, not a range. <full-integrity-hash> in the lockfile is worth more than any ^ you skimmed past in review.
• Turn scripts off at CI install time (--ignore-scripts, or the moral equivalent in your package manager) where you can. Some tools genuinely break without postinstall. Fix those. The default of "run any script the tarball ships" was always the wrong default.
• Watch new-and-narrow dependencies. A package added three days ago, resolved by a handful of maintainers, several of them freshly created: that is the shape these reports keep describing.
• Assume the lure lands. Not "assume good faith". Assume the interview candidate scenario happens. Design the machine accordingly.

None of these need a new vendor on your invoice. All of them need someone at your organization to decide, on the record, that a developer's laptop is a pipeline stage.

What the reporting does not say

DevOps.com attributes the wave to two DPRK-linked groups and names PolinRider as the campaign, citing Socket and Rescana. Beyond that, resist filling in gaps.

Do not cite package names you have not read for yourself. Do not attribute the campaign to a specific named actor beyond "DPRK-linked", per Socket and Rescana. Do not repeat a victim count that the reporting did not give you. The instinct to add authority by adding specifics is exactly how supply-chain coverage becomes noise.

Read the source. Read Socket's writeup. Read Rescana's. Then decide what your team will actually change.

One line to keep

Fake interview. Real postinstall. Actual production credentials.

Someone on your team will get an unusually flattering recruiter message this quarter. The coding challenge will be polished, the private package plausibly named, the postinstall short and unremarkable.

Do not build a control that assumes people will not run it. Build one that assumes they will.