Overview
It’s completely normal for early-stage startups to prioritize growth and product stability over security. Most founders are focused on shipping features fast, getting user feedback, and building a product that works. Security often gets pushed down the list until one day, it comes back to bite.
That day usually arrives when a customer asks for a penetration test report, or you need to pass a SOC 2 or ISO 27001 audit to close a deal. At that point, you’ll wish you had taken some basic steps early on.
From our experience working with newly founded companies or those undergoing their first penetration test, we consistently see the same types of vulnerabilities. These usually stem from launching too quickly, lack of security reviews, and minimal resources. The good news? Many of these risks can be avoided with simple practices without spending a lot of time or money.
What Are Secrets?
Secrets are any sensitive credentials that grant access to your systems or data. This includes:
- Passwords
- API keys
- Database credentials
- AWS access keys and secret tokens
- Any other tokens or private configuration values
Secrets are the keys to your kingdom — they often hold more value than your source code.
Imagine two scenarios:
- Your database credentials or AWS keys get leaked, exposing customer data like PII stored in an S3 bucket.
- Your source code gets leaked, but it contains no secrets.
Which is more damaging to your business? Clearly, the first. A leaked database or cloud storage bucket can lead to data breaches, regulatory fines, and lost customer trust especially with enterprise clients you've spent months trying to close.
Unless your code contains highly proprietary algorithms or trade secrets, it's usually not the most valuable thing. What truly matters are the systems and data that code controls and that’s exactly what your secrets protect.
That's why secrets must be treated with the highest level of care securely stored, access-restricted, and never hardcoded into your codebase or shared in unsafe channels.
1. Leaked Secrets in GitHub Repos ,Docker Images, and JavaScript Files
Problem:
One of the most critical and common issues we encounter is exposed secrets API keys, tokens, database credentials often found in:
- Public GitHub repositories (including commit history)
- Public Docker images
- JavaScript files on the frontend
Most developers assume that deleting a .env file before making a repo public is enough. Unfortunately, Git keeps a full commit history, so secrets can still be recovered even if the file is deleted later. Similarly, people often forget to clean up secrets from JS files or accidentally bake them into Docker layers.
Solution:
- GitHub: Before making any repository public, deactivate or rotate all secrets stored in the repo — especially those that may exist in old commits.
- Use tools like truffleHog or gitleaks to scan your repo history before publishing.
2. Docker Images
Problem:
Docker images can be deconstructed layer by layer. If secrets were ever added to a layer, even if deleted later, they might still be accessible. .env files and sensitive configs are often unintentionally included in public images.
Solution:
- When building a public Docker image, start from scratch.
- Double-check that no secrets or sensitive files or logs are included in any layer.
- Use .dockerignore properly, and avoid multi-stage builds with secrets in early stages.
3. JavaScript Files (Frontend)
Problem:
Secrets sometimes get hardcoded into frontend JavaScript files during testing and are forgotten. Even if removed later, assume that once a secret is exposed to the internet, it’s compromised.
Solution:
- Never store secrets on the frontend.
- Rotate the secret if you suspect it was ever exposed.
- Remember: if the secret was exposed even for a short period, it might have been cached or indexed.
Recommendations
- Rotate any leaked secret immediately. Before rotation, assess the impacted services to minimize disruption.
- Never store secrets in source code or documentation.
- Use a Secrets Manager (e.g., AWS Secrets Manager, HashiCorp Vault, or any reliable alternative).
- For CI/CD pipelines (e.g., GitHub Actions), define secrets using environment variables never hardcode them.
- Limit access to secrets among your team. Think ahead what happens if an employee's laptop is compromised?
- Slack is not a secret manager. If someone shares a secret on Slack, rotate it. Consider using tools like Password Pusher or whisper for temporary, secure sharing.
- Remember: security is built on strong fundamentals. You don’t need enterprise tools at the beginning, just good habits.
- Document your secret usage like Name of Secret , the Service , where you are using it and when you created , these meta data is very important in case of incident
This is Part 1 of a blog series focused on achieving practical security for your product with minimal cost and overhead. Next parts will cover other common risks and how to address them efficiently.