Your open-source project just received an email from someone claiming to be a core maintainer, asking for elevated repository access. The writing style matches, and the email domain looks legitimate, but something feels off.
This scenario is real. The recent attack on Axios shows that threat actors are using sophisticated social engineering tactics against open-source maintainers. They're not sending obvious phishing emails anymore—they're conducting reconnaissance, studying communication patterns, and crafting convincing impersonation attempts.
You need a response protocol that allows your team to verify requests without offending legitimate maintainers or causing unnecessary friction. Here's a script template you can adapt for your project.
Purpose of the Script
This verification script helps your team respond to suspicious access requests, contribution proposals, or security disclosures that claim to come from maintainers or trusted contributors. It establishes a secondary verification channel without publicly questioning someone's identity.
The script is useful for:
- Repository access escalation requests
- Requests to add new maintainers or collaborators
- Urgent security patches from "existing" maintainers
- Proposals to transfer ownership or fork control
- Financial or sponsorship discussions claiming maintainer authority
Prerequisites
Before implementing this script, ensure you have:
Established maintainer roster: Document all current maintainers with their verified contact methods. Store this in a private repository or team wiki—never in public documentation where attackers can study it.
Out-of-band communication channel: Set up a verified secondary contact method for each maintainer. This could be a phone number, Signal account, company Slack workspace, or PGP-signed email address. The key is that it must be verified through a different channel than your primary communication.
Team agreement: All maintainers must agree to this verification protocol and understand they'll be subject to it themselves. Frame it as mutual protection.
Response time expectations: Define how quickly you'll respond to verification requests (suggest 24-48 hours). Attackers often create artificial urgency; your protocol should explicitly reject it.
The Verification Script
Subject: Verification Required - [Original Request Subject]
Hi [Maintainer Name],
I received your request regarding [specific action requested]. Before proceeding, I need to verify this through our secondary channel.
Please confirm this request by:
[CHOOSE ONE BASED ON YOUR ESTABLISHED PROTOCOL]
Option A - Direct Contact:
Sending me a message at [your verified secondary contact] with the phrase "Verified request: [unique identifier]"
Option B - Signed Confirmation:
Replying to this email with a PGP signature using your registered key [key fingerprint]
Option C - Platform Verification:
Commenting on this GitHub issue [create private issue] from your verified account: [link]
I'll process your request within 24 hours of receiving confirmation. This verification applies to all access escalation requests, regardless of tenure or trust level.
If you didn't make this request, please contact me immediately at [your verified contact].
Thanks,
[Your Name]
[Your Role]
Customizing the Script
Adjust verification methods: Use methods your team actually uses. A phone call may be more practical than a cryptographic proof.
Calibrate urgency language: The script avoids apologizing or suggesting the request might be legitimate. Your tone should be matter-of-fact: this is standard procedure.
Create request-specific identifiers: Generate a unique phrase or code for each verification request. This prevents attackers from reusing old confirmations.
Scale the protocol by risk level: Not every request needs the same verification rigor. Categorize by risk:
High risk (requires verification): Access escalation, new maintainer additions, ownership transfers, urgent security patches, financial discussions
Medium risk (enhanced review): Significant code contributions from new patterns, dependency updates affecting core functionality
Standard process: Regular contributions from established patterns, documentation updates, minor fixes
Document false positive handling: Your script will occasionally flag legitimate requests. Document how you'll handle the verification conversation when the maintainer confirms it was them—acknowledge the inconvenience but reinforce why the protocol exists.
Validation Steps
After implementing this script, validate your protocol quarterly:
Run a red team exercise: Have a team member simulate a social engineering attempt. See if your verification protocol catches it. Document what worked and what didn't.
Measure response consistency: Track how often team members apply the verification protocol. If usage is inconsistent, you have a training problem. Review cases where the script wasn't used and understand why.
Check verification channel validity: Quarterly, confirm that your secondary contact methods still work. Maintainers change phone numbers, company affiliations, and communication preferences.
Review for social engineering evolution: Every six months, review recent social engineering tactics reported in the open-source community. Update your script's language and verification methods to counter new patterns.
Test your response time: Measure how long verification actually takes. If your 24-hour target regularly becomes 72 hours, adjust your stated timeline to match reality.
The Axios attack wasn't an isolated incident—it was one visible example of industrialized tactics targeting open-source maintainers. Your verification script won't stop every attack, but it forces attackers to compromise multiple channels simultaneously, increasing their cost and reducing their success rate.
Most importantly: use this script consistently. The moment you skip verification for a "trusted" request is the moment an attacker's reconnaissance pays off. Your maintainers will understand. The attackers are counting on you making exceptions.
Social Engineering Tactics
