Security for Software Engineers: Daily Habits That Prevent Breaches

Many recent software breaches started not with a clever exploit but with an ordinary engineering habit: a token pushed to a repository, a package installed without a second look, an editor extension trusted by default, or a project cloned and run on a laptop holding production credentials. Software engineers now hold the keys attackers want most, because a developer's session or publishing token can reach source code, CI pipelines, cloud accounts and every user of a package. This guide is for software engineers, engineering managers and the security teams who support them. It sets out the daily and weekly habits that prevent those breaches, how a team rolls them out without slowing delivery, and how to measure them. It focuses on individual practice; for how organisations build the wider culture around it, see the Security Culture guide.

Source note: product behaviour and guidance below are summarised from the OpenSSF, GitHub, VS Code, npm and NIST pages listed in the references, as checked in November 2026; habits not attributed to them are NHI Mgmt Group recommendations. Confirm against the official text before relying on it.

Key takeaways

• Your laptop is a credential store. SSH keys, cloud sessions, package publishing tokens and Git credentials on a developer machine are what attackers harvest first.
• Secrets never go in code. Use a secrets manager and keep push protection on; if a secret is pushed, rotate it first and clean history second.
• Every dependency is code you run. Evaluate new packages, pin versions with lock files and let updates settle before adopting them.
• Untrusted code stays untrusted. Open unfamiliar repositories in restricted mode or a disposable environment, and treat interview tasks and "fix this bug" projects from strangers as hostile.
• Short-lived beats long-lived. Prefer federated, short-lived credentials for CI and publishing over personal access tokens stored on laptops.

Why engineers are targeted

The breach record on NHI Mgmt Group shows the pattern. In the Bybit Hack 2025, a developer at a wallet provider ran a Docker project on a work laptop; attackers then used the developer's active AWS session tokens, which had already passed MFA, to alter front-end code and redirect about $1.5 billion. In the GlassWorm Campaign 2025, malicious editor extensions harvested npm, GitHub, Git and Open VSX credentials, and leaked publishing tokens let attackers push further malicious updates. Neither required a software vulnerability. See the Threat Actors Targeting Software Developers Guide for the groups behind such campaigns.

Habit 1: keep secrets out of code and history

The OpenSSF Concise Guide for Developing More Secure Software lists "Do not push secrets to a repository" as one of its core items, and the breach record shows why: the Toyota T-Connect Key Exposure 2022 left an access key on public GitHub for five years.

• Read secrets at runtime: fetch them from the organisation's secrets manager or inject them as environment variables in the deployment platform. See the Secrets Management Guide.
• Keep push protection on: GitHub push protection blocks pushes containing recognised secrets from the command line, web UI, file uploads and REST API. Push protection for users is enabled by default on GitHub.com for pushes to public repositories; repository-level push protection is off by default and needs an administrator to enable it. When a push is blocked, do not choose a bypass reason to get it through; remove the secret. See How to enable GitHub secret scanning push protection.
• Add a local pre-commit scan: a secret scanner in a pre-commit hook catches mistakes before they leave the laptop and works on any Git host. See the Git Hooks and Pre-commit Security Guide.
• Ignore local config files: add .env, local credential files and IDE workspace files that can hold tokens to .gitignore from the first commit.
• If it leaks, rotate first: GitHub's own guidance is to rotate the credential first, since removing it from history is time-consuming and often unnecessary once it is revoked. See How to Remove Secrets From Git History.
• Logs and tickets count too: do not paste tokens, connection strings or customer data into tickets, chat, pull request comments or AI assistants.

Habit 2: treat dependencies as code you run

Installing a package runs someone else's code, often with install scripts, on a machine holding your credentials. The OpenSSF guide asks developers to evaluate software before adding it as a direct dependency, use package managers, monitor known vulnerabilities in direct and indirect dependencies, and keep dependencies reasonably up to date after a cooldown.

1. Before adding: check the package is the one you meant (watch for typosquats), that it is maintained, how many maintainers it has and whether the functionality justifies a new dependency.
2. Pin and lock: commit lock files and install from them in CI (npm ci rather than npm install, for example), so builds use exactly the reviewed versions.
3. Let releases settle: a short cooldown before adopting a brand-new version gives registries and researchers time to catch malicious releases.
4. Review update pull requests: automated dependency updates are only safe if someone reads what changed for major or unusual updates. See the Dependency Update Automation Guide.
5. Know the response: if a package you use is reported compromised, follow the Malicious Open Source Package Response Playbook.

See the Malicious Package and Dependency Confusion Guide for registry configuration and scoping.

Habit 3: open untrusted code safely

Attackers increasingly deliver malware as code for developers to run: fake job interview tasks, "reproduce this bug" repositories, malicious editor extensions and poisoned AI assistant configuration. The Bybit compromise began with a Docker project run on a work machine.

• Use Workspace Trust: VS Code opens unfamiliar folders in Restricted Mode, which blocks tasks, debugging, the terminal, AI agents and extensions that have not opted in until you trust the folder. Keep security.workspace.trust.enabled at its default of true, and do not trust a folder until you have read its tasks, launch configuration and build scripts. VS Code's documentation advises: when in doubt, leave a folder in Restricted Mode.
• Use a disposable environment: run unknown projects, take-home tests and proof-of-concept code in a container, cloud development environment or virtual machine that holds no credentials.
• Curate extensions: install editor extensions only from publishers you recognise, prefer an organisation allow list and remove those you no longer use.
• AI coding agents: give agents the same caution you would give a new contractor: no production credentials, approval for commands and review of every change. See the AI Coding Agents Security Guide.

See the Developer Workstation and IDE Security Guide for the device baseline your organisation should provide.

Habit 4: protect your accounts and access

• Phishing-resistant MFA: the first item in the OpenSSF guide is MFA for privileged developers. Use security keys or passkeys for your Git host, cloud console, package registry and SSO. See the Phishing-Resistant MFA Guide.
• Prefer fine-grained, expiring tokens: when you need a personal access token, scope it to specific repositories and permissions and give it an expiry. Delete tokens you no longer use.
• No standing production access: request time-limited elevation for production changes instead of keeping admin roles on your daily account.
• Sign commits: GitHub supports GPG, SSH and S/MIME commit signatures and lets administrators require signed commits on a branch. SSH signing needs Git 2.34 or later and, in NHI Mgmt Group's view, is the simplest to set up. Signed commits make impersonated commits stand out.
• SSH key care: protect private keys with a passphrase or hardware-backed keys and remove keys from accounts and servers when devices are replaced. See How to find unused GitHub deploy keys and SSH keys.

Habit 5: write and review code with security in mind

Daily coding habits prevent the vulnerability classes that scanners keep finding.

• Review before merge: the OpenSSF guide asks for review before accepting changes. Use branch protection so no one, including administrators, merges unreviewed code to the main branch.
• Threat model the change: for a new endpoint, integration or permission path, spend ten minutes on what could go wrong. See the Threat Modelling Guide.
• Prefer memory-safe languages for new components where practical, as the OpenSSF guide recommends.

Habit 6: publish and deploy from pipelines, not laptops

Publishing tokens and deployment keys on laptops are the root of many supply chain incidents. npm trusted publishing, for example, lets a package publish from GitHub Actions, GitLab CI/CD or CircleCI using OpenID Connect, with short-lived signed credentials tied to the authorised workflow and no stored token to leak; once it works, token-based publishing can be disallowed for the package. Provenance attestations are generated automatically for public packages built from public repositories on GitHub Actions and GitLab CI/CD. Other registries and clouds offer similar OIDC federation. See the CI/CD Pipeline Identity Security Guide and the Sigstore Guide.

Where identity fits

Most of the credentials in this guide are non-human identities that engineers create and then forget: personal access tokens wired into scripts, deploy keys, bot accounts, CI secrets and API keys for test environments. Give each one an owner, a purpose, the smallest scope and an expiry, and record it where the security team can see it. When you change teams or leave, hand over or revoke what you created; the Coupang Breach 2025 involved a former engineer's signing key that was not revoked. See the Developer endpoints as NHI stores guide.

Rolling the habits out across a team

The plan below is NHI Mgmt Group's recommended rollout.

1. Week 1, baseline: run a secret scan across all repositories and history, list personal access tokens and publishing tokens in use, and check MFA methods for Git host and registry accounts.
2. Weeks 2 to 3, quick wins: rotate any live secrets found, enable repository push protection, enforce phishing-resistant MFA for the organisation, and turn on branch protection with required review.
3. Month 2, tooling: ship a standard pre-commit configuration with secret scanning, adopt lock files everywhere, and introduce a dependency cooldown in the update bot. Pilot with one team, measure build time and false positives, then roll out.
4. Month 3, credentials: move publishing and deployment to OIDC federation from CI, set maximum token lifetimes, and replace standing production access with just-in-time elevation.
5. Ongoing: cover these habits in onboarding and role-based training, and appoint security champions. See the Developer Security Training Programme Guide and the Security Champions Programme Guide.

Rollback without losing ground: if a control blocks delivery (a noisy scanner rule, a cooldown that delays an urgent fix), use a documented, logged exception for that case rather than disabling the control for everyone, and tune the rule. Small and large teams: a five-person start-up gets most of the benefit from MFA, push protection, branch protection and lock files, all available on mainstream Git hosts. A large engineering organisation should add central token policy, an internal package proxy, extension allow lists and federated publishing for every package.

Detection and measurement

• Secrets caught before push: ratio of secrets blocked by pre-commit or push protection to secrets found after merge; it should rise over time.
• Time to rotate: median hours from a confirmed secret leak to revocation.
• Push protection bypasses: count and reasons each month; frequent "I'll fix it later" bypasses signal a training or tooling gap.
• Long-lived tokens: number of classic or non-expiring personal access tokens and laptop-held publishing tokens; target zero.
• Phishing-resistant MFA coverage: percentage of engineers using security keys or passkeys on the Git host and registry.
• Unreviewed merges: merges to protected branches without approval; target zero.

Alert on new personal access tokens with broad scopes, push protection bypasses, publishing from outside CI, and cloud API calls using developer sessions from unexpected networks.

Framework mapping

The habits also map to the NIST Secure Software Development Framework (SP 800-218, version 1.1); see the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.

Common failure patterns

• "Temporary" hard-coded keys: a key added to test locally and committed, as in the Toyota T-Connect Key Exposure 2022.
• Running a stranger's project on the work laptop: the route into the Bybit Hack 2025.
• Publishing tokens on developer machines or in public repositories: the enabling factor in the GlassWorm Campaign 2025 and in npm worms such as the Shai-Hulud npm Worm 2025.
• Bypassing push protection to meet a deadline: the secret lands in history and must be rotated anyway.
• Installing the latest version the moment it appears: no cooldown, so a malicious release is adopted before anyone notices it.
• Standing admin rights: a daily account with production admin that turns any laptop compromise into a production incident.

Practitioner checklist

• Use security keys or passkeys on your Git host, cloud console, package registry and SSO.
• Keep secrets in a secrets manager; never commit .env or credential files.
• Run a secret scanner in a pre-commit hook and keep push protection on.
• Rotate any leaked secret immediately, then decide on history clean-up.
• Evaluate new dependencies, commit lock files and adopt new versions after a cooldown.
• Open unfamiliar repositories in Restricted Mode or a disposable environment with no credentials.
• Use fine-grained, expiring tokens and delete those you no longer need.
• Sign commits and require review before merge on protected branches.
• Publish packages and deploy from CI with OIDC federation, not from your laptop.
• Hand over or revoke every credential you created when you change role or leave.

Standards and references

• NIST: SP 800-218 Secure Software Development Framework
• OpenSSF: Concise Guide for Developing More Secure Software
• GitHub Docs: About push protection
• GitHub Docs: About secret scanning
• GitHub Docs: About commit signature verification
• Visual Studio Code: Workspace Trust
• npm Docs: Trusted publishing for npm packages

Related NHI Mgmt Group resources: Security Culture · Developer Workstation and IDE Security Guide · Secure Coding Guide · Compromised Developer Workstation Playbook