GitHub disclosed that attackers accessed its internal repositories after compromising an employee device through a poisoned Visual Studio Code extension. The company said the activity appears limited to GitHub-owned internal repositories, with the attacker’s claim of roughly 3,800 repositories being “directionally consistent” with its investigation. GitHub also said it found no evidence that customers’ own enterprises, organizations or repositories were impacted.

That is reassuring, but it is not the whole story.

The bigger takeaway is that this was not just a code security incident. It was a trust incident. An engineer downloaded what appeared to be a legitimate developer tool, and that trusted workflow became the attacker’s way in.

That is social engineering in a modern developer environment. It does not always arrive as a sketchy email with a bad link. It can show up as a helpful extension, a routine update, a useful package, a fake support prompt, or a “productivity tool” that looks like it belongs in the workflow.

For InfoSec teams, this is a big deal. Developer endpoints are not ordinary laptops. They often have access to source code, cloud environments, secrets, build systems, package registries and CI/CD pipelines. Compromise one trusted developer machine, and an attacker may gain a map of how the organization builds, ships and secures software.

Internal repositories can also be extremely valuable. Even when customer data is not stolen, internal code may expose architecture details, deployment scripts, API references, test data, support snippets, credentials or clues that help attackers plan follow-on attacks.

Organizations should use this incident as a reason to tighten controls around developer tools. Inventory approved IDE extensions. Review publishers and permissions. Watch for unusual repository cloning, unexpected token use and new tools installed on developer machines. Rotate secrets quickly when exposure is possible, and move toward short-lived, tightly scoped credentials wherever practical.

But do not make this only a technical control problem. Train developers for the social engineering they actually face. Teach them to question unexpected extensions, verify publishers, be cautious with auto-updates, report suspicious tool behavior and use trusted internal channels before installing anything that touches code or credentials.

The bottom line: attackers are not just phishing inboxes anymore. They are phishing workflows.

Treat developer tools like production infrastructure. Monitor them, govern them and make sure your people know when trust is being abused.

Let’s stay safe out there.