Auditing over fifty public repositories on GitHub reveals an uncomfortable truth: the same security mistakes repeat regardless of the developer's experience or project size. From startups to large corporations, the temptation to hardcode keys, forget to configure .gitignore, or leave credentials in Git history is common and dangerous. At Q2BSTUDIO, where we develop custom software and offer cloud, AI, and cybersecurity services, we know that security must be integrated from day one. Below, we analyze the three most recurring failures and practical solutions to avoid them, with a technical and business approach that will help you protect your code and reputation.
Mistake #1: API keys and passwords embedded in source codeThe most basic and yet most devastating error. Seeing something like const dbPassword = 'supersecret' in a JavaScript file is too common. Although many developers know about environment variables, the reality is they don't always use them correctly. Even when they create a .env file, they often upload it to the repository because they forget to add it to .gitignore. The result: anyone who clones the project gets access to AWS keys, Slack tokens, database credentials, or Stripe keys. The solution is not just technical but cultural: establish a policy of never including secrets in code, use environment variable managers like dotenv, and most importantly, automate detection with tools like dotguard before every commit. In our cybersecurity and pentesting projects, we implement secret scanners in the workflow to detect leaks early. Additionally, we recommend rotating any key that has been exposed, even if only for a few minutes.
Mistake #2: An incomplete or missing .gitignore fileMost developers remember to add node_modules/ and .DS_Store, but forget other equally sensitive files: .env, .env.local, *.pem, *.key, config/database.yml, secrets.json, *.p12, *.pfx. If any of these files contain credentials and are not in .gitignore, they will end up synced to GitHub. The lack of a complete .gitignore is one of the main causes of leaks in open-source projects. The solution is to create a base template that covers all common patterns of sensitive files, and review it whenever a new type of credential is added. In cloud environments, such as when working with AWS and Azure cloud services, private key files (pem, p12) are critical; they must never be in the repository. That's why at Q2BSTUDIO we configure repositories with exclusion policies from the first commit and use analysis tools to verify that no forbidden file slips through.
Mistake #3: Credentials in Git history, the trail that never disappearsYou have removed the key from the current code, but the damage is already done if that same file with the key was previously committed. Git keeps all history, and anyone can run git log -p | grep 'api_key' or git log --oneline and find the information. This is especially dangerous because even if you delete the file, the commit that contained the key still exists. The only complete solution is to rewrite history with tools like BFG Repo-Cleaner or git filter-repo. However, the ideal is to never reach that point. Prevention begins with using environment variables from the start and implementing pre-commit hooks that scan the code for secrets. In projects that integrate artificial intelligence or AI agents, access keys to language models (like OpenAI or Claude) are especially valuable and must be protected with the same rigor. At Q2BSTUDIO, when developing AI solutions and intelligent agents, we apply these practices from the initial design to avoid any leak.
Bonus: Automate secret detection in your CI/CD pipelineThe best way to ensure no secret reaches the remote repository is to integrate a secret scanner into your continuous integration flow. Tools like dotguard, GitHub Advanced Security, or GitLeaks can run on every pull request, scanning the code for patterns of keys, tokens, passwords, or connection URLs. If the scanner detects something suspicious, the build fails and the developer must correct it before merging. This practice, combined with Business Intelligence dashboards like Power BI to monitor project security, is part of the enterprise solutions we offer at Q2BSTUDIO. Additionally, process automation allows for periodic credential rotation and generating compliance reports without manual effort. Cybersecurity is not a destination but a continuous process that must be integrated at every stage of development.
Conclusion: security is part of development, not an add-onThe three errors analyzed are common, but also perfectly avoidable with proper practices: use environment variables, rigorously configure .gitignore, clean Git history if necessary, and automate secret detection. If you have committed any of these mistakes, don't panic: the priority is to rotate the exposed keys and adopt a secure workflow from now on. At Q2BSTUDIO, as a company specialized in custom software development, artificial intelligence, cloud, and cybersecurity, we help organizations of all sizes build secure products from the ground up. Don't let a technical oversight put your project at risk. Security is not optional; it is a fundamental requirement.
