The culprit wasn’t code quality. It was a sloppy rebase and a wide-open CI/CD pipeline.
Git rebase is powerful. It keeps commit history clean, ensures a readable project timeline, and makes merges predictable. But it also opens doors for risk if your secure workflow isn’t airtight. When developers rewrite history, they can accidentally hide bad changes, bypass gates, or slip in unwanted commits. Without solid guardrails in your pipeline, that commit can make it all the way into production before anyone notices.
A secure CI/CD pipeline means that no matter what happens during a rebase, you control what reaches deployment. To achieve this, every push—rebased or not—must be re-validated from scratch. Rely only on fresh, trusted artifacts. Validate commit signatures to ensure code comes from real, approved contributors. Block merges unless all tests and security scans have passed on the exact code being shipped.
Access control is just as important as validation. Limit who can trigger builds on protected branches. Use short-lived credentials that expire as soon as a job finishes. Keep secrets out of git history forever. Every write path to production should have explicit review and logging.