Thi Nguyen (T)

Posted on Apr 21 • Originally published at github.com

Hackers Love Lazy Developers — 19 Security Mistakes You’re Making Right Now

#webdev #devops #opensource #security

Security Handbook for Developers

"Hackers don't break in — they walk through the door you left open."

Part I — Developer Identity & Workstation

Threats that start at the endpoint: your laptop, your keys, your credentials. If an attacker owns the developer, the rest of the defenses barely matter.

1. SSH Keys: Hackers' Easiest Target & Prime Hotspots

Let's be honest—every developer, at least once, has raced through ssh-keygen in a caffeine-fueled haze, hammered Enter three times to skip the passphrase, and thought, "I'll add it later… maybe." But guess what? That heroic shortcut is like leaving your car unlocked with the keys in the ignition and a "Please Steal Me" bumper sticker.

If some sneaky hacker nabs your unencrypted private SSH key, they don't need to knock—they walk right in. They can masquerade as you on your servers or GitHub, push malicious code, raid private repos, and throw a root-level rave in your infrastructure.

There have even been exploits—like the SSH-key-scan honeypot attack—that prey on keys without passphrases.

Don't be that person who leaves the passphrase blank. Instead, channel your inner secret-agent and pick a passphrase like C0ffee#Mug@3xtraShot (words + numbers + special chars). Your future self (and your servers) will thank you! And remember: rotate those keys every month, because even the best locks need fresh keys now and then.

If you provide an empty passphrase when generating an SSH key, the private key will not be encrypted. This means:

Anyone who gains access to your private key file (e.g., via a compromised machine, malware, or accidental exposure) can use it without any restriction to authenticate as you.
There will be no additional layer of security beyond file system permissions.
Attackers can use stolen private keys immediately, making them a prime target in exploits.

By setting a strong passphrase, your private key is encrypted with that passphrase, meaning:

Even if someone steals your private key file, they cannot use it without knowing the passphrase.
It adds an extra layer of security, making it much harder for attackers to exploit.

Maximum Security: Store Your SSH Key on a YubiKey (FIDO2)

Even a passphrase-protected SSH key still lives on disk — and anything on disk can be copied. If your laptop gets popped by malware, info-stealer, or a malicious postinstall script, the attacker walks away with ~/.ssh/id_ed25519 and just needs to crack (or keylog) the passphrase.

The fix: don't store the private key on disk at all. Generate a FIDO2/resident SSH key directly on a hardware token like a YubiKey. The private key material never leaves the device, and every git push requires a physical touch on the key. No touch = no auth. Steal the laptop, still can't push.

Why this is the gold standard for pushing to GitHub:

Private key is non-exportable — malware literally cannot exfiltrate it
Physical presence check (touch-to-authenticate) stops remote abuse even if the machine is fully compromised
Works with OpenSSH 8.2+ natively — no extra agents, no GPG dance
Same key can sign commits (gpg.format ssh) so auth and commit signing are hardware-backed

Generate a resident SSH key on the YubiKey:

ssh-keygen -t ed25519-sk -O resident -O application=ssh:github -O verify-required -C "github-yubikey"

-t ed25519-sk → hardware-backed Ed25519 key
-O resident → key can be pulled back onto any machine with ssh-keygen -K (no backup file needed)
-O verify-required → requires PIN and touch on every use (defense in depth)

Pin the key for GitHub pushes only:

git config --global core.sshCommand 'ssh -i ~/.ssh/id_ed25519_sk -o IdentitiesOnly=yes'

The IdentitiesOnly=yes flag prevents SSH from leaking other identities to the server. Add the public key (id_ed25519_sk.pub) to GitHub → Settings → SSH keys, and every push now demands a physical touch.

Recovery: Buy two YubiKeys and enroll both up front. If you lose one, you're not locked out of your own repos at 2 AM on a Friday.

2. Don't Let Hackers Impersonate You, Lock Down Commits with GPG

Why would a hacker forge your commits? How do they pull it off?

Sneak in malicious code: By masquerading as a trusted contributor, they slip dangerous payloads into your codebase.
Corrupt your audit trail: Fake author metadata clouds the "blame" history, making investigations a nightmare.
Exploit CI/CD: A forged commit can trigger automated pipelines, provisioning backdoors or leaking secrets.

How they hack through forged commits — spoofing Git metadata:

git commit --author="You " -m "Awesome new feature"

Signed commits add an extra layer of security by proving the authenticity of code contributions. This prevents commit forgery and ensures that only verified developers contribute to the codebase.

A signed commit with verified badge:

When you sign a commit, you must enter the password for the GPG key:

Additionally, to be able to push code to Github, you must enter the passphrase for the SSH key. This creates 2 layers of protection similar to multi factor authentication.

When generating GPG key, should generate with an expiration. Recommendation is 3 months.

Adding GPG key in Github Account Setting:

3. Enforce Strong Password Practices & Secure Credential Management

Ensuring strong password hygiene is critical to protecting developer accounts, repositories, and infrastructure from unauthorized access. Weak or reused passwords are a major attack vector, leading to account takeovers and data breaches.

Best Practices for Strong Password Security

Use a Password Manager — Developers should never store passwords in plaintext. Use a trusted password manager such as Bitwarden, 1Password, LastPass, or KeePassXC. Enable 2FA for the password manager itself.
Use Strong, Unique Passwords for Each Service — Generate randomized, long passwords (at least 16-24 characters with uppercase, lowercase, numbers, and special characters).
Rotate Passwords for Critical Applications Regularly — Critical applications include GitHub, social accounts, Google Account, crypto wallets, database credentials, cloud infrastructure, and financial accounts. Rotate every 3-6 months.
Enable Two-Factor Authentication (2FA) on All Apps — MFA is non-negotiable. Prefer hardware security keys (YubiKey, NitroKey) over SMS or authenticator apps.
Use Passkeys Where Possible — Passkeys (WebAuthn) are a more secure alternative to passwords. Prevents phishing attacks by eliminating password-based logins.

4. Secrets Aren't for Sharing, Not Even with Your Team

Never share private keys, API secrets, or credentials with anyone—including coworkers.

Do Not Share Credentials: Use role-based access controls (RBAC) and secure secret management tools.
Rotate Credentials Regularly: Implement automated credential rotation policies.
Compromised Secrets Lead to Untraceable Security Breaches: If credentials are leaked, attackers could move laterally within the system, making it harder to identify the entry point.

5. Don't Store Secrets in .env Files – Use a Secure Secret Vault

Why .env Files Are a Security Risk

.env files can be accidentally committed to Git, exposing secrets in repositories.
Attackers with access to a developer's machine can extract credentials from .env files.
.env files lack access controls, making it impossible to enforce least privilege access.
Secrets in .env files are not automatically rotated.

Use HashiCorp Vault Instead

Secrets are encrypted on the disk level
Provides dynamic secret injection without storing credentials in local files
Supports RBAC for secure access management
Allows automatic secret rotation

# Inject secrets dynamically
vault exec -wrap-env my_command

# Example: Injecting Database Credentials Securely
vault exec --env DB_USERNAME --env DB_PASSWORD my_command

Secrets are never stored in local files or exposed in shell history.

6. Secure Firewall Policy for Developer Desktops

A firewall is critical for developer desktops, ensuring unauthorized network traffic is properly controlled.

Key reasons:

Block unauthorized outbound traffic — Prevents malware from leaking sensitive data.
Restrict inbound access — Ensures only necessary services are accessible.
Mitigate attack risks — Reduces exposure to port scanning and unauthorized access.

Best Practices:

Least Privilege: Allow only necessary services.
Deny by Default: Block all and allow only required traffic.
Logging & Monitoring: Enable logging for audit trails.
Regular Review: Periodically check rules for outdated permissions.
Use IP Whitelisting: Restrict access to trusted IPs.

Suggested tools: UFW, OpenSnitch.

7. Monitor for Compromised Developer Devices

Even if your backend is locked down, all it takes is one developer's infected laptop to sink the ship.

Use Endpoint Detection & Response (EDR) tools like CrowdStrike, SentinelOne, or open-source Wazuh.
Disable automatic token caching in CLI tools like GitHub CLI, AWS CLI.
Limit SSH agent forwarding, especially on jump boxes and bastion hosts.
Restrict privileged developer laptops from using public Wi-Fi or enforce VPN-only policies.

Part II — Supply Chain & Dependencies

Everything that enters your machine from the outside world: packages, images, downloads, attachments. The inbound trust boundary is where modern attacks land first.

8. No Blind Installs: Treat Each Package Like a Potential Trojan

The open-source package ecosystems (npm, PyPI, Go modules and beyond) are prime real-estate for supply-chain attacks. One malicious dependency can turn your entire codebase into a backdoor.

Real-World Supply-Chain Ambushes

Common Attack Patterns

Typosquatting & Look-Alikes — Packages with names almost identical to popular ones sneak past casual installs.
Compromised Maintainers — If a trusted owner's account is hijacked, legitimate libraries can be laced with malware.
Dependency Confusion — Publishing internal package names publicly tricks CI/CD pipelines into fetching malicious versions.
Obfuscated Malware — Minified or compiled code conceals data-stealing routines.

Pre-Installation Security Checklist

Authenticate the Source — Install only from official registries and verify the maintainer's identity. Run npm audit, pip audit, or use tools like Socket.dev.
Pin & Inspect Your Dependencies — Commit lockfiles. Preview dependency trees with npm ls, go mod graph, or pipdeptree.
Spot Typosquats — Double-check package names against the registry and GitHub repo links.

9. Don't Let Docker Be Your Trojan Horse: Lock Down Your Containers

Containers are like magic boxes: lightweight, portable, and fast. But if you treat them like black boxes and skip security, they'll behave like Pandora's Box.

A container isn't a sandbox unless you make it one.

Major Docker Security Breaches

Tesla Kubernetes Hack (2018) — Attackers exploited an open Kubernetes dashboard to deploy cryptominers.
Docker Hub Data Breach (2019) — 190,000 user credentials exposed.
TeamTNT Docker API Attacks (2020–2021) — Exploited unauthenticated Docker daemons.
Graboid Docker Worm (2019) — First Docker worm spread through unsecured daemons.
Dero Miner Targeting Docker (2025) — Cryptomining worm exploiting misconfigured Docker daemons.

Best Practices for Secure Docker Usage

1. Never Run Containers as Root

# Bad
USER root

# Good - Use a non-root user
RUN useradd -m appuser
USER appuser

2. Use Minimal Base Images

# Small and secure base image
FROM alpine:3.20

3. Scan Images for Vulnerabilities — Use Trivy or Dockle.

4. Sign and Verify Docker Images — Use Docker Content Trust (DCT) or Cosign.

5. Avoid Leaking Secrets in Docker Images

# Bad
COPY .env /app/.env

# Better
ARG API_KEY
ENV API_KEY=$API_KEY

6. Use Docker Networks + Firewalls Wisely

# Limit to localhost
-p 127.0.0.1:8080:80

7. Monitor and Limit Container Resources

docker run --memory=256m --cpus=0.5 myapp

8. Keep Docker & Host Up-To-Date — Consider distros like Bottlerocket or Flatcar designed for containers.

9. Runtime Security with eBPF + Sandboxing — Use Cilium Tetragon for eBPF-based monitoring. Use gVisor or Kata Containers for sandboxing.

10. Verify Website URLs Carefully Before Downloading Anything

The Download Trap: When "Official" Isn't Actually Official

You're rushing to install a new tool, you Google it, click the first result, and BAM — you just downloaded malware disguised as legitimate software. Even Homebrew has been targeted by sophisticated phishing campaigns.

How Attackers Hook Developers

The Google Ads Hijack — Malicious ads appear above legitimate search results.
Typosquatting — https://node-js.org instead of https://nodejs.org, https://g1thub.com instead of https://github.com.
SEO Poisoning — Fake sites optimize for search rankings.

The Developer's Download Defense Playbook

Step 1: Source Authentication — Never trust search engines for software downloads. Bookmark trusted sources.

Step 2: URL Forensics — HTTPS is non-negotiable. Inspect certificates. Read URLs character by character.

Step 3: Prefer Package Managers

# Secure: Use official package managers
brew install node          # macOS
apt install nodejs         # Ubuntu/Debian
npm install -g typescript  # Node.js packages

# Risky: Manual downloads from random websites
curl https://suspicious-site.com/nodejs.tar.gz

Step 4: Pre-Installation Scanning — Upload to VirusTotal, verify checksums, sandbox test suspicious downloads.

Attack	Year	Impact	Method
PyPI Package Attack	2022	Thousands infected	Mimicking `pytorch-nightly`
Google Ads Malware	2023	Mass infections	Fake ads for VLC, Notepad++
NPM Supply Chain	2021	Worldwide impact	Malware in `ua-parser-js`

11. Weaponized PDFs & File Traps: Don't Get Baited

Cybercriminals love when you open random files, especially PDFs via Telegram, email, or Discord. From Radiant to Ronin, multimillion-dollar exploits began with a single careless click.

Radiant hack (2024) — $50M lost from malware in a PDF
Ronin Bridge hack (2022) — $615M lost from a similar vector

Guidelines for Handling PDFs:

Do NOT download and open PDFs directly — Open them in your browser using Google Drive or other secure preview options.
Be wary of unexpected attachments — Verify legitimacy before opening.
Never enable macros or scripts — Some PDFs prompt you to enable features that execute malicious code.
Report suspicious files — If you receive a suspicious PDF, report it to your security team.

Use application sandboxing if you must open a PDF locally:

Windows: Windows Sandbox (built-in)
Linux: Firejail
macOS: App Sandbox

Part III — DevSecOps & Shift-Left

Security baked into the build pipeline and the code itself. Find bugs before attackers do.

12. Secure Your CI/CD Pipelines: Attackers Love Automated Trust

Your CI/CD pipeline has the keys to the kingdom: access to source code, secrets, cloud credentials, and deployment mechanisms.

Major CI/CD Security Breaches

SolarWinds Orion (2020) — Nation-state attackers inserted a backdoor, impacting 18,000+ customers.
Codecov (2021) — Attackers tampered with the Bash uploader, stealing secrets from thousands of environments.
CircleCI (2023) — Compromise led to theft of environment variables, secrets, and keys.
Travis CI (2022) — Leaked secrets in build logs exposed thousands of credentials.
PHP Git Server (2021) — CI pipeline was hijacked to insert malicious code into official PHP source.

Best Practices:

Use ephemeral environments: Rebuild containers and runners on every job.
Restrict secrets exposure: Never expose all secrets to every job; use secret-scoping.
Require commit signature verification before running deploy jobs.
Use OpenID Connect (OIDC) for temporary cloud permissions via short-lived tokens.
Audit your pipeline dependencies: Install only trusted tools and lock versions.
Pipeline Isolation & Segmentation: Separate pipelines by environment.

13. Secure Coding: Write Code That Resists Attacks

Developers must write code that is resilient to common attacks. Key practices from the OWASP Top 10:

Input Validation: Treat all user input as untrusted. Validate and sanitize on the server side.
Output Encoding: Encode data output to prevent XSS.
Parameterized Queries: Prevent SQL injection.
Authentication and Session Management: Implement strong auth, MFA, and secure cookies.
Error Handling: Avoid leaking sensitive info in error messages.
Least Privilege: Never run applications as root.

# Vulnerable to SQL injection
cursor.execute("SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'")

# Secure: Parameterized query
cursor.execute("SELECT * FROM users WHERE username = ? AND password = ?", (username, password))

14. Security Testing: Shift Left and Catch Issues Early

Shifting security left means integrating security early in the SDLC:

SAST (Static Application Security Testing): Analyze source code during development. Tools: SonarQube, Bandit, ESLint with security plugins.
DAST (Dynamic Application Security Testing): Test running applications. Tools: OWASP ZAP, Burp Suite.
Dependency Scanning: Use Dependabot, Renovate, or Snyk.
Secret Scanning: Use GitGuardian or TruffleHog to prevent secrets from being committed.

Part IV — Access & Infrastructure

Shrink the blast radius: no standing production access, no flat networks, no permanent cloud admins.

15. VPN Connection Required for Critical Resources

VPN authentication must require Two-Factor Authentication (2FA).
All employees and contractors must enable 2FA on cloud accounts, code repositories, and internal dashboards.

16. Implement Just-In-Time (JIT) Privileges

Developers often have standing access to sensitive infrastructure. JIT access ensures elevated permissions are granted temporarily, on-demand, with approval, and revoked automatically.

How to Implement:

AWS IAM + SSO + Identity Center — Short-duration assume-role sessions
Azure PIM — Temporary admin roles with approval and MFA
Teleport Access Requests — JIT SSH/Kubernetes/database access via Slack or web UI
StrongDM or Boundary (HashiCorp) — Identity-based JIT session brokering

17. Cloud Security: Shared Responsibility Model

Key practices:

IAM: Assign minimal permissions. Use groups and roles. Enable MFA.
Network Security: Use VPCs, security groups, and network ACLs.
Encryption: Encrypt data at rest and in transit.
Logging and Monitoring: Enable cloud provider logs and set up alerts.
IaC Security: Scan Terraform/CloudFormation templates with Checkov or tfsec.

// Bad: Public read access
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"

// Good: Restrict to specific IAM role
"Effect": "Allow",
"Principal": {
  "AWS": "arn:aws:iam::123456789012:role/my-role"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"

Part V — Detect & Respond

Assume breach. The question isn't if something slips through — it's how fast you see it and how cleanly you contain it.

18. Security Logging & Alerting: Detecting Threats Before They Strike

"You can't defend what you can't see."

Centralizing developer logs using SIEM tools is essential. A well-configured SIEM can help you:

Detect lateral movement across developer machines
Correlate developer activity with alerts from cloud systems
Set up anomaly detection alerts for suspicious behavior

Tools:

Wazuh — Open-source SIEM + XDR
Falco (CNCF) — Cloud-native runtime threat detection
Osquery — Query endpoints like a database
MITRE ATT&CK Framework — Map attacker behavior to detection patterns

19. Incident Response: Be Prepared for the Worst

Following the NIST model:

Detection and Reporting: Recognize breaches through unusual behavior and monitoring alerts. Report immediately.
Containment: Isolate affected systems. Revoke compromised credentials.
Eradication: Patch vulnerabilities. Remove malware.
Recovery: Restore from clean backups. Monitor for recurrence.
Post-Incident Analysis: Conduct retrospectives to improve defenses.

Frameworks:

Open Source Toolkits:

GRR Rapid Response — Remote forensics
TheHive + Cortex — Collaborative incident handling
Zeek — Network traffic analysis

Originally published at fystack/developer-security-handbook