A few weeks ago, I shared my initial idea of automatically fixing hardcoded secrets within CI pipelines. The feedback has been overwhelmingly against the idea, as many in the community feel uncomfortable with CI modifying code, even if it's technically safe. After re-evaluating, I've pivoted my approach: now, remediation will occur locally through pre-commit hooks or manual intervention, while the CI will strictly serve as a detection-only mechanism. My reasoning is that CI should remain deterministic and non-invasive. Developers generally prefer reviewing changes before committing, and automatic fixes are most effective when they are clear and predictable. However, the question remains: Is pre-commit the right stage for this remediation? Should tools strike a balance at detection only, keeping fixes entirely manual? Has anyone seen successful auto-remediation integrated into real repositories? I'm trying to gauge community comfort with these practical applications.
3 Answers
I think your plan to implement checks at various stages of the SDLC could be effective. Using pre-commit hooks can help prevent secrets from being committed, but it relies on everyone setting up their environments correctly. Also, the risks of auto-remediation seem high, especially since proper remediation involves more than just string replacement. Once a secret gets into VCS, it can be tricky to completely remove it. I’ve seen automatic rotations work when compromised secrets are detected, but it can lead to outages if mishandled. Just something to consider!
Totally! Keeping the automation simple and safe seems wise. I personally prefer manual fixes to foster better coding practices.
One thing I realized is that while detection is crucial, it's equally important to have a solid plan post-detection. Many pipelines currently just fail on detection, leading to manual fixes. What if some low-risk fixes could be automated, especially for clear-cut cases, without introducing ambiguity? That’s the boundary I’d like to explore.
That approach might work well! Sometimes a simple replacement is all that’s needed, and if it can happen automatically without risk, it's worth a shot.
For sure! Keeping it contained to the simplest changes makes sense. Anything complex should stay manual.
I believe pre-commit hooks are solid for preventing secrets from landing in the repo, but it’s essential to also consider how to deal with existing secrets in your git history. CI should act as a failsafe: if a secret is detected during CI, it should lead to a hard failure on the pull request. Automatic fixes can be risky and may not even be practical depending on how complex the situation is.
This makes a lot of sense! I think of it as three separate issues: prevention, detection, and historical cleanup. A thorough cleanup is necessary to ensure no remnants of exposed secrets exist.
Yep! And as you mention, many teams skip the historical cleanup, which is where the real danger lies.
You're spot on about the need for a robust approach; the environment setup is a big factor. Developers should be educated about manual remediation to ensure it becomes a learning moment. There’s a lot at stake when automatic changes are involved.