Secure Development
Secrets, dependencies, and the supply chain — where modern breaches actually start, and how teams shift left.
Secrets Management
Hardcoded secrets are the breach that never stops giving: committed once, they live in git history forever, and public-repo scanners find them in minutes. Rule: secrets never touch source code. They come from environment variables, a secrets manager (Vault, cloud KMS/Secrets Manager), or mounted files — injected at runtime, never baked in.
# NEVER: committed to git, lives in history forever DB_PASSWORD = "hunter2" # runtime injection instead export DB_PASSWORD="$(vault kv get -field=pw secret/db)" # guardrails echo ".env" >> .gitignore git secrets --scan # pre-commit hook blocks known patterns
Dependency & Supply-Chain Security
Your code is a sliver of what ships — the rest is dependencies, and their dependencies, hundreds deep. Attackers noticed: supply-chain attacks compromise a popular package (typosquatting, hijacked maintainer accounts, malicious updates) so your build pulls in their code with full application privileges.
| Threat | Example | Defense |
|---|---|---|
| Known CVE in a dep | Log4Shell (log4j RCE, 2021) | npm/pip audit, Dependabot, patch cadence |
| Typosquatting | reqeusts vs requests | Pin names + versions; review adds |
| Hijacked package | event-stream (2018) | Lockfiles, integrity hashes, provenance |
| Build-system compromise | SolarWinds (2020) | Signed builds, reproducible builds, SBOM |
Shift Left — Security in the Pipeline
The earlier a flaw is caught, the cheaper it is — fixing in design costs a fraction of fixing in production. “Shift left” bakes automated security checks into the pipeline so problems surface at commit time, not incident time.
| Check | What it catches | When it runs |
|---|---|---|
| SAST | Static analysis of your source (injection, bad crypto) | On commit / PR |
| SCA | Vulnerable/again-licensed dependencies | On commit + continuously |
| Secret scanning | Committed keys and tokens | Pre-commit + CI |
| DAST | Runtime flaws against a live build | Staging / nightly |
| IaC scanning | Misconfigured cloud/Terraform | On commit |
None replace human review or threat modeling — they catch the known and the mechanical, freeing humans for the logic flaws tools can’t see (like an IDOR that’s syntactically perfect code).
Baseline Hardening Checklist
- Validate input at trust boundaries (allowlist)
- Encode output for its context
- Parameterize every query
- Least-privilege every credential + service
- Log security events; alert on anomalies
- Patch on a cadence; watch your SBOM
- Trusting client-side validation alone
- Detailed error messages/stack traces to users
- Default credentials and debug mode in prod
- One god-credential shared across services
- Rolling your own crypto or auth
- “We’ll add security later”
Interview Questions
A secret was committed to git and pushed. What now?
Rotate it immediately — assume it’s compromised. Removing the line or rewriting history doesn’t help; it was public, and automated scrapers hit public repos within minutes. Then add secret scanning so it can’t recur.
What is a software supply-chain attack?
Compromising something upstream of you — a dependency, a maintainer account, the build system — so malicious code ships inside a trusted artifact with your app’s privileges. Log4Shell, event-stream, and SolarWinds are the canonical cases.
Why commit a lockfile?
It pins exact versions and integrity hashes, so builds are reproducible AND a tampered re-publish under the same version fails verification. It’s a supply-chain control, not just a convenience.
What does “shift left” mean and why?
Move security checks earlier — commit/PR time rather than post-deploy. Flaws cost far less to fix before release, and automated SAST/SCA/secret scanning catch the mechanical issues so human review can focus on logic flaws.