Lunch time thought Whilst I love that git is a wonderful event sourced distributed ledger I also like that its criminal to rewrite commits because of this But I also hate that once again I committed something I wish I hadn't and now i have to go change the roles This to me smells of a design problem - how can we as an industry be exposing ourselves to this risk like this? There has to be a better way. There is a usability problem in here - I know better, but when going fast it is excruciatingly easy to miss something. I keep seeing console *commands* with *secure data* in them that should never be there. We have a system that has bad cohesion. The command changes as the API changes The secure data changes when the organisation changes But our API munge these to seperate reasons for change together into a single command. Should we start giving examples of things like that that depend upon env vars only? What do you think? #CI #ContinuousImprovement #XP #Security Sure pre-commit hooks are great - but when github actions are easy to edit inline we really need something to check for id like strings and really interrogate us wrt comitting them.
Agreed on git. Tidying up orphaned bad commits... yuck. Mandate a secrets vault... Azure Key Vault and AWS Secrets Manager are two I've used a few times now. If you can, secure the vault to your pipeline via service principal or managed identity. Rotate secrets. Best of luck.
Senior Consultant at Deloitte Digital
3moOne of the reasons that I'll often defer to shell scripts when building pipelines from Jenkinsfiles / github workflows is so that it's possible to locally run as many of the steps as possible, which would either pass in things with "${@}" (I've personally found useful if deferring to gradle tasks), or use environment variables to pick which test suite type to run. Overall, I think I agree. Declaring a list of required environment variables that contains secrets at the top of the script can then have references to what the value should be and how you might go about getting it. What might also be a good idea is to defer to a generated file in the pipeline that you would then `source` from, within the scripts. Then use a single variable as the environment config that's made in a prior step.