The Recruitment Email That Isn't What It Seems
Last week I was building a Slack integration for a client's hiring pipeline. Standard stuff—candidate notifications, automated screening workflows, the whole thing. Then I read about Contagious Interview, and I had to stop.
These aren't random phishing attempts. They're surgical. Someone is posing as a recruiter or tech lead, reaching out to developers with what looks like legitimate code review work or a job opportunity. The bait is specific enough to work because, well, we expect those emails. I get five a week. You probably do too.
The problem isn't the email itself—it's the attachment, the GitHub link, the "pull request you need to review." It's the thing that makes sense in context.
Why This Actually Concerns Me More Than Ransomware
- Ransomware is loud
- This lives in your development environment and watches what you build, what credentials you use, what APIs your company's actually running on—which is infinitely more valuable than locking files
- You might not know you're compromised for months because it's not screaming at you from a dialog box
I'm not sure this is the right perspective, but I think the real risk here isn't the initial compromise. It's what happens after. If someone has access to your CI/CD pipeline, your GitHub organization, your build artifacts—they're not just stealing data. They're potentially poisoning the software your company ships to customers. They're in position to inject themselves into every automation workflow you've built.
That keeps me awake at 2 AM in a way security theater doesn't.
The Automation Problem I Can't Solve Cleanly
Here's where I'm actually conflicted. I build a lot of recruitment automation—resume parsing, candidate scoring, background check integrations. Automation assumes trust at certain checkpoints. You set up a workflow, it runs, nobody's manually reviewing every step because that defeats the purpose of automation.
But trust is exactly what's being weaponized here. A recruiter's email account. A GitHub user with legitimate permissions. A code review process that's supposed to move fast.
Should I be telling clients to add manual verification steps to their hiring workflows? That sounds like I'm undoing the entire reason they hired me. Should I recommend they treat every external link with paranoia? That might actually be smart, but it also sounds exhausting and probably won't stick for long.
I genuinely don't know what the answer is that's both secure and practical, and I think that's the thing nobody wants to admit about modern infrastructure.
What I'm Actually Changing in My Workflows
- SSH key rotation policies that aren't just recommendations—they're hard stops in onboarding
- Every integration that connects to a git repository now logs who accessed what and when. Even if nobody reads those logs, they exist. They're auditable. Sometimes that's enough friction to matter
- I stopped building workflows that require developers to paste tokens into Slack messages, which I know everyone does anyway, which is a different problem entirely
The Thing I Can't Shake
The most dangerous part of this attack isn't technical. It's social. Someone sent an email that looked right. Someone clicked because the context was perfect. The psychology of a developer getting recruited, a code review landing in your inbox—these are normal Tuesday things. We've been trained to respond to them automatically.
So what does that mean for automation? If humans are the unreliable variable, and we're building systems that scale human workflows, what happens when the human part of the equation is the actual vulnerability? Do we automate harder? Do we add more friction? Do we accept that security and scale might be opposing forces?
I don't have a clean answer. I just know that the next time I'm designing a workflow that touches authentication or external integrations, I'm going to sit with this for longer than I probably should.
