Securing Your Development Environment
Introduction→▼Dev Environment→Client→Transport→Server→App→Data→More

Securing Your Development Environment

April 1, 2025

Before an HTTP request ever leaves — before it reaches the user's browser, before it hits the server, before we start securing anything — your application's code and configuration pass through your development environment. This is Layer 0.

A single security lapse in your development environment can expose sensitive data, compromise systems, and erode user trust you spent months building. The consequences often extend beyond your own project — a compromised developer account is a backdoor into every system that account has access to.

Why is Securing Your Dev Environment Crucial?

Think of your development environment as the blueprint room for a high-security building. If those blueprints fall into the wrong hands, the building's vulnerabilities are exposed, and its security is compromised. Similarly, leaked API keys, weak passwords, and public repositories can provide attackers with a backdoor to your applications and data. A compromised developer account can be a gateway to exploiting production systems.

Security of your app starts with you! Each of missteps presented in this post can enable attackers to bypass any of the rules presented later in this guide. Simply because they would get an easy access to the headquarter and all the secrets.

Securing Your Dev Environment: the Basics

1. Never Expose API Tokens in Public Repositories

API tokens are like digital keys, granting access to sensitive resources. Committing them to public repositories is like leaving your front door wide open.

  • Use environment variables or secure configuration files to manage API keys
  • Add .env files to .gitignore immediately when starting a project
  • Consider git hooks (e.g., git-secrets, trufflehog) to catch secrets before they're committed
  • If you accidentally commit a secret — rotate the key immediately, then clean the history

2. Keep Repositories Private

Unless your project is explicitly open source, keep your repositories private. This limits the attack surface and prevents unauthorized access to your codebase.

  • Use the access control features provided by your version control system (GitHub, GitLab, Bitbucket)
  • Review who has access to your repos regularly

3. Employ Strong, Unique Passwords

Weak passwords are easily cracked, providing attackers with a foothold into your accounts.

  • Use long, complex passwords that include a mix of uppercase and lowercase letters, numbers, and symbols
  • Never reuse passwords across services

4. Utilize a Password Manager

Remembering numerous strong passwords is challenging. A password manager securely stores and generates passwords, simplifying the process.

  • Consider reputable password managers like Bitwarden, 1Password, or LastPass

5. Enable Two-Factor Authentication (2FA)

2FA adds an extra layer of security by requiring a second form of verification, such as a code from your mobile device.

  • Enable 2FA on all accounts that support it, especially your version control system, email, and cloud provider accounts

6. Secure SSH Access

  • Use SSH Keys: Avoid password-based SSH authentication. Generate strong SSH key pairs and store the private key securely.
  • Disable Password Authentication: In your SSH server configuration (sshd_config), set PasswordAuthentication no.
  • Restrict SSH Access: Limit SSH access to specific users and IP addresses using AllowUsers and AllowHosts directives in sshd_config.
  • Change Default SSH Port: Modify the default SSH port (22) to a non-standard port to reduce automated attacks.
  • Use SSH Agent: Use an SSH agent to avoid repeatedly entering your passphrase.
  • Protect your private key: Set proper file permissions on your private key (e.g., chmod 400 ~/.ssh/id_rsa).
  • Use a strong passphrase for your private key when generating the SSH key.
  • Regularly rotate SSH keys: Rotate keys periodically to reduce the impact of potential compromises.

Git Hooks — Catching Secrets Before They Land in the Repository

Git hooks are scripts that execute automatically at specific git events — for example, before a commit (pre-commit) or before a push (pre-push). This is the ideal place to scan code for secrets.

git-secrets (AWS Labs)

git-secrets scans commits for secret patterns — AWS keys by default, but you can add your own patterns.

# Installation (macOS)
brew install git-secrets

# Configure for a repository
cd your-repository
git secrets --install          # Installs pre-commit, commit-msg, prepare-commit-msg hooks
git secrets --register-aws     # Adds patterns for AWS keys

# Scan entire repository (find secrets in history)
git secrets --scan-history

TruffleHog — Deeper Scanning

TruffleHog goes further — it scans the entire git history and uses entropy (randomness) to detect potential secrets, not just known patterns.

# Installation
pip install trufflehog
# or via binary release: https://github.com/trufflesecurity/trufflehog/releases

# Scan local repository
trufflehog git file://. --only-verified

# Scan GitHub repository
trufflehog github --org=your-organization

Gitleaks — Fast and Configurable

Gitleaks is a popular alternative with ready-made CI/CD integration:

# Installation
brew install gitleaks

# Scan local repository
gitleaks detect --source .

# As a pre-commit hook
gitleaks protect --staged  # Scans only staged files

Add to .git/hooks/pre-commit:

#!/bin/sh
gitleaks protect --staged -v

.gitignore as the First Line of Defense

Before any hook runs — sensitive files shouldn't reach git at all. Set up .gitignore right at git init:

# Secret files
.env
.env.local
.env.*.local
.env.production
*.pem
*.key
*.p12
secrets.json
config/secrets.yml

# Certificates
*.crt
*.cert
ssl/

# Tool-specific
.aws/credentials
.ssh/

The gitignore.io tool generates a .gitignore for your tech stack in seconds.

Important: if a file was already in the repository before being added to .gitignore — simply adding it to .gitignore doesn't remove it from history. You need git rm --cached.

What to Do When a Secret Has Already Landed in the Repository

If you accidentally pushed an API key to a public repository, assume it's already compromised — bots scanning GitHub work within minutes.

  1. Immediately revoke the key — change it in the service it belongs to (AWS Console, GitHub Settings, Stripe Dashboard)
  2. Remove the secret from history — git filter-repo or BFG Repo Cleaner
  3. Force push — overwrite history on the remote repository
  4. Check logs — whether the key was already used by someone else

Cleaning history is a destructive operation — consult your team before doing it.

SAST in Your IDE — Static Security Analysis While You Write

SAST (Static Application Security Testing) is code analysis without running it — searching for vulnerabilities in the source code itself. When SAST runs in the IDE, security issues are flagged the same way as syntax errors.

Snyk for VS Code / JetBrains

Snyk is one of the more popular tools with a plugin for VS Code and IntelliJ/WebStorm:

  • Scans dependencies for known CVEs (similar to npm audit, but with better UX)
  • Analyzes code against OWASP Top 10
  • Suggests fixes directly in the editor

The plugin is free for personal use and open source projects.

SonarLint

SonarLint is an IDE plugin from the creators of SonarQube — available for VS Code, IntelliJ, Eclipse, Visual Studio. It analyzes code in real time and highlights "code smells" and security vulnerabilities with an explanation of why a given pattern is dangerous.

ESLint Security Plugin (JavaScript/TypeScript)

For JS/TS projects — eslint-plugin-security:

npm install --save-dev eslint-plugin-security
// .eslintrc.json
{
  "plugins": ["security"],
  "extends": ["plugin:security/recommended"]
}

Detects among other things:

  • eval() with user-supplied data
  • Unsafe file system operations
  • Potential ReDoS (Regular Expression Denial of Service)

Actionable Steps

  • Immediately audit your repositories: Search for any accidentally committed API keys or sensitive data. Remove them and rotate the keys.
  • Move all API keys to environment variables: Never hardcode them into your source code.
  • Check repo visibility: Ensure all sensitive repositories are set to private.
  • Generate strong, unique passwords: Use a password generator.
  • Install and configure a password manager: Store all your credentials securely.
  • Enable 2FA everywhere possible: Start with your most critical accounts.
  • Generate and use SSH key pairs: Disable password-based SSH authentication.
  • Configure your SSH server securely: Modify sshd_config to restrict access and change the default port.
  • Regularly update your operating system and software: Patching vulnerabilities is essential.

Summary

The development environment is Layer 0 — a compromised developer means a compromised production, because the attacker gets access to code, configuration, and secrets before any application-side security mechanism comes into play. The checklist above covers the most common gaps: API key exposure, repository visibility, weak passwords, missing 2FA.

For related posts in the series: managing API keys and tokens — including where to store them and how to rotate them — is covered in Authentication Tokens and API Keys. The risks associated with external dependencies (Snyk scanning, npm audit) continue in Third-Party Libraries.