We (my employer) recently parted ways with a development vendor and yesterday I was combing through various repositories, cleaning up the nightmare that was their branching strategy (or lack thereof) when I stumbled across this little gem:

Screenshot a GIT commit with easily-guessed, hard-coded passwords...with a comment about needing to change the passwords...

Bad Code: Hard-coded passwords and a comment acknowledging the problem

Two thought immediately popped into my head:

  • Why would you hard-code credentials into your application?
  • Why wouldn’t you have stronger credentials right off the bat?

I have to take some of the accountability here; as the Lead at my company, code quality falls within my realm of responsibility. Thankfully, this commit never made it out of the Development branch…but it’s all to easy to imagine this sort of problem making it’s way up the chain, into Production. Honestly, I never thought I’d have to add “do NOT hard-code credentials” into our guidelines for new developers but then, I’ve been wrong about a lot of things in my career… 😄

On a lark, I took my Mac down the hall to our cyber security expert and asked her to spot the problem. It took her all of ten seconds to start laughing. Once she was able to stop giggling, she offered two bits of advice:

  1. Stash this sort of issue in your “this is bad code” file to show to junior developers as a teachable moment.
  2. Look into something called SonarQube to help automate the detection of potential security issues in source code.

It’s an old, tired stereotype that developers hate interacting with security folks but every time I talk with our cyber security expert, I get homework…and that’s an absolutely wonderful thing; when we stop learning, we start to degrade.

Note: This post is from my old site and was ported over into Micro.Blog when I consolidated from two sites into one. All of the migrated posts can be found here.