Developers usually consider email as a delivery problem. SPF, DKIM, and DMARC on the sending domain, a reliable transactional provider, a webhook for bounces, and a retry queue that avoids hammering the API. That process is well documented and well understood.
The gap lies elsewhere. It is the personal account linked to your git identity, your package registry, your cloud console, and the reset flow for every service you have ever created. That account is typically the oldest component in your stack and the least reviewed. No one writes a runbook for it. It rarely appears in a threat model, because it does not seem like infrastructure, yet it acts like infrastructure the moment someone else controls it.
The recovery chain nobody diagrams
Draw the dependency graph for your accounts, with email at its root. AWS, npm, PyPI, GitHub, and your domain registrar each will send a reset link to an address, so the strength of everything downstream is limited by the strength of that single inbox.
Think about that in practice. If someone reads your mail, they do not need your GitHub password. They request a reset, take the link, and walk in the front door with a valid session. Hardware keys on the accounts that matter break the chain, because a reset link alone stops being enough. Stackademic's cybersecurity topic has more on the account-hygiene side of this if you want the longer version.
Commit metadata is a public address book
Every commit you push carries an author email. So does every signed tag and most package manifests. Scrapers have harvested these for years, which is why an address used only for code still gets targeted messages.
The fix is uninteresting and effective: set a dedicated address or the platform's no-reply alias for commits, and keep your real address off anything that ships publicly.
Phishing aimed at people who write code
Developer-targeted phishing is more specific than the generic kind. Fake CI failure notifications. A pull request review request from a repository you half recognise. An npm security advisory that wants you to sign in. These work because they arrive in a context where you are already clicking through notifications quickly.
CISA's guidance on recognising and reporting phishing makes a point worth repeating. The bad-grammar test is finished, because attackers now draft with the same models everyone else does. Check the sending domain and the link target rather than the prose.
Where the provider sits in your threat model
Most mail providers can read message content. That is a fair trade for plenty of use cases and a poor one for others. If your inbox holds client credentials, incident notes or anything under NDA, an encrypted email provider narrows the problem. The company holds no key to the content, so what is exposed is metadata rather than everything you have written.
It's worth pairing this with a review of connected OAuth apps, because a script you authorised in 2021 may still retain read scope on the entire mailbox.
The awkward part is that none of these fixes are technical, so they don't seem like real work. They take an hour and require no cleverness at all— but that's likely why the account at the root of everything is still using a password you chose at university.
Comments
Loading comments…