Join Doppel at Black Hat USA 2026 to win The Bigger Carry-On suitcase from Away
Research

DevSecOps & Social Engineering: How to Protect Developers

Attackers are targeting developers on GitHub, Slack, and Discord with fake jobs and malicious NPM/PyPI dependencies. Learn how to protect your technical backbone.

DevSecOps & Social Engineering: How to Protect Developers

Corporate firewalls are stronger than ever. Cloud security posture management tools are getting smarter, and zero-trust architectures are finally making their way from whiteboard diagrams into actual production environments.

Because breaching a hardened enterprise network directly is incredibly difficult, time-consuming, and expensive, advanced persistent threat (APT) groups have pivoted.

Instead of spending six months trying to find a zero-day vulnerability in your edge router, attackers are going after the people who already hold the keys to the kingdom: your software engineers.

Today’s developer workstation is the holy grail for a threat syndicate. It holds live SSH keys, active cloud provider tokens for AWS or Google Cloud, and direct commit access to your organization's most sensitive production pipelines. If an attacker compromises a developer, they can just log in and push their own malicious code directly into your product.

This is the reality of software supply chain attacks in 2026. Highly sophisticated adversaries, like the North Korean state-sponsored Lazarus Group, are executing massive campaigns (like the infamous ‘contagious interview’ attacks) that rely entirely on social engineering.

Attackers are hanging out on Slack, Discord, and GitHub, targeting your engineering team with fake freelance offers and malicious open-source repositories.

Here’s how attackers are weaponizing the developer ecosystem, and how DevSecOps teams can protect their technical backbone before an artifact is ever weaponized.

What developer-targeted social engineering looks like in 2026

Engineers are generally incredibly tech-savvy, which means a standard "urgent password reset" email from the IT department usually gets flagged as spam immediately.

Attackers know this, so they tailor their lures to a developer's specific career goals and daily workflows.

Here’s how a modern, developer-targeted social engineering campaign unfolds.

#1. Fake recruiter trap

The attack almost always starts with a highly credible persona. Attackers build extensive, fake recruiter profiles on LinkedIn, Reddit, and specialized developer forums. They target engineers with incredibly lucrative job offers or freelance contracts, usually leaning into high-growth, high-salary niches like Web3, cryptocurrency, or artificial intelligence.

The ‘recruiter’ initiates a completely normal, professional conversation. They ask about the developer's tech stack, their previous experience, and their timeline for taking on a new project. There are no malicious links and no weird attachments.

The goal here is purely psychological: lower the developer's defenses by offering them a massive payday.

#2. Coding challenge payload

Once the developer is interested, the recruiter moves to the next phase of the interview process. They ask the candidate to complete a standard, take-home technical assessment.

Instead of sending a sketchy ZIP file, the recruiter sends a link to a completely normal-looking GitHub, GitLab, or Bitbucket repository. They tell the developer, "Clone this repo, fix the bugs in the authentication module, and push your changes back to us in 24 hours."

To the developer, this looks like a totally standard hiring practice. The repository contains legitimate code, a well-written README.md file, and standard project structures. It feels safe.

#3. Invisible execution

The trap is usually hidden in the project's dependency files, like package.json for Node.js projects or requirements.txt for Python.

The repository points to a malicious dependency hosted on a public registry, and the exact moment the developer opens their terminal and types npm install or pip install, the game is over. A package manager reaches out to the public registry and downloads the malicious payload.

Using pre-install scripts or obfuscated code, the malware executes silently in the background before the developer even opens their code editor. It instantly begins scraping the machine for SSH keys, clipboard data, browser passwords, and cloud tokens, funneling them straight back to the attacker's command-and-control server.

The developer thinks they're just setting up a local environment for a job interview, but they've just handed over total access to your corporate infrastructure.

Cloned infrastructure: weaponizing NPM & PyPI

Attackers exploit the massive scale and inherent trust of the open-source software (OSS) ecosystem.

They know that developers rely on thousands of tiny utilities, wrappers, and helper libraries to build modern applications, and this reliance is weaponized using two primary techniques: typosquatting and dependency confusion.

Typosquatting

When building a malicious coding challenge, an attacker will often clone a legitimate, highly trusted open-source package (like graphlib or buffer). They take the safe code, inject a backdoor or an infostealer into it, and upload it back to a public registry like NPM or PyPI using a slightly altered name.

Attackers might use suffix-addition, version mimicry, or a simple typo (e.g., requests-http instead of requests), and because the malicious package functions exactly like the legitimate one, the developer won't notice anything is broken when they run the code.

The application compiles, the tests pass, and the malware stays completely hidden in the background.

Depending confusion

This tactic is even more insidious because it can target your internal development pipelines directly.

Many enterprise engineering teams build private, internal packages (let's call one corp-auth-helper) that they host on private registries. However, package managers like NPM or pip are often configured to check public registries first by default.

An attacker simply registers a package on the public NPM registry using the exact same name as your internal package (corp-auth-helper), but they assign it a ridiculously high version number (like 99.0.0).

When a developer pulls the latest code and runs npm install, the package manager gets confused. It sees the public package with the higher version number and assumes it's the most up-to-date release, and it pulls the malicious public package down onto the developer's machine instead of the safe internal one.

Why a developer compromise is catastrophic

Malware executes locally on the developer's machine during the install phase, completely bypassing your traditional CI/CD security checks. The attacker can establish persistence within developer tools like VS Code, giving them a permanent backdoor into the environment.

From there, they can inject malicious workflows directly into your company's private repositories, continuously exfiltrate trade secrets, or poison the software you eventually ship to your own customers. It turns your most valuable engineers into unwitting insider threats.

Legacy AppSec vs agentic code protection

The cybersecurity industry has spent the last decade building application security (AppSec) tools designed to scan code after a developer commits it. We have static analysis (SAST), dynamic analysis (DAST), and software composition analysis (SCA) tools built right into the pipeline.

But these tools are fundamentally reactive. They scan the code after it's already on the machine or in the repository. Against a sophisticated social engineering campaign, this is way too late.

To actually protect the technical backbone of your company, you have to push your defenses further left. You need proactive digital risk protection (DRP) that monitors the open web and neutralizes the threat before the developer ever clicks "clone.”

Security capability

Legacy AppSec

Agentic DRP

Visibility scope

Scans internal code repositories only after a commit is made

Actively monitors the open web, public package registries, and developer forums

Threat detection

Relies on known CVE signatures and historical vulnerability databases

Uses agentic AI to identify typosquatted packages and behavioral anomalies in real-time

Remediation speed

Fails the automated build after the malware has already executed on the developer's machine

Executes automated takedowns of the cloned repo and malicious package globally

Coverage area

Limited entirely to the IDE and the CI/CD pipeline

Covers external communication channels like Slack, Discord, GitHub, and social media

How Doppel protects the technical backbone

You can't rely entirely on your developers to manually verify the authenticity of every single transitive dependency they pull down on a Tuesday afternoon. And you certainly can't expect them to outsmart highly organized, state-sponsored intelligence operatives posing as recruiters.

DevSecOps needs an active, autonomous defense layer that operates outside the firewall. This is exactly where Doppel's agentic AI completely rethinks software supply chain security.

Tracking repository anomalies

Doppel's AI agents continuously scan the external software ecosystem, including GitHub, GitLab, NPM, PyPI, and RubyGems. The system looks for behavioral anomalies, not just known bad hashes.

Our agents instantly identify unauthorized code leaks, spoofed organizational namespaces, and cloned corporate repositories. If an attacker tries to register a public NPM package that mimics your private internal naming conventions (attempting a dependency confusion attack), Doppel flags it immediately.

Doppel gives you total visibility into how your brand and your technical assets are being represented on the open web.

Securing the collaboration layer

Developers live in Slack, Discord, and specialized forums, and Doppel extends your threat visibility directly into this collaboration layer.

By monitoring social platforms and developer hubs, our agentic AI can spot coordinated fake recruiter personas and identify malicious campaign links circulating in the wild. Doppel catches the social engineering lure before the developer ever has a chance to click on the coding challenge.

Machine-speed takedowns for code

Alerting your SOC that a developer might have downloaded a bad package is helpful, but it doesn't solve the core problem. The attacker's infrastructure is still live, waiting for the next victim.

When Doppel’s AI verifies a spoofed repository or a malicious package impersonating your brand, it automatically initiates multi-channel takedowns. We issue direct, API-driven requests to repository hosts (like GitHub) and package registries (like NPM) to burn down the attacker's operational core.

Doppel completely removes the poisoned artifact from the global supply chain, destroying the attacker's sunk costs and ensuring no other developer can accidentally pull the payload.

Securing the code at the source

The days of assuming your internal network is a safe, sterile environment are long gone.

Threat syndicates are actively hunting your software engineers, exploiting the inherent trust of the open-source community, and weaponizing the very tools your team relies on to build your product. If you're only scanning for vulnerabilities after the code is committed, you're leaving your entire technical backbone exposed to social engineering.

It's time to stop playing defense in the pipeline and start taking the fight to the attacker's infrastructure.

Get a demo to see how Doppel’s agentic AI tracks repository anomalies, defeats developer-targeted social engineering, and executes machine-speed takedowns.

Learn how Doppel can protect your business

Join hundreds of companies already using our platform to protect their brand and people from social engineering attacks.