Don’t Commit Sensitive Information to the Repository

One of the most common security issues I in code reviews is sensitive information, such as production credentials, API keys, etc, in the source code. The source code I just pulled from the repository. The source code all the developers before me have also pulled down to their local computers. Developers who might not work at the company anymore.

Most people are honest and won’t do anything bad with the information but there are exceptions. Even if developer is honest they might accidently expose the sensitive information such as a stolen laptop or their home network getting compromised.

Some examples of sensitive information I’ve seen:

  • AWS Simple Email Service (SES) key: This can be used by others to send email as if they are your company. I’ve seen it used by spammers and once AWS notices they will disable your SES account until you can prove to them the problem is fixed.
  • Production Database credentials: Often this is not a high priority issue because the database is usually not publicly accessible (i.e. behind a firewall) but in one case the production database was accessible on the internet.
  • FTP credentials to Government Services: Attackers could upload malicious files as if they where company in question.
  • Private SSH for Production: With this key anyone can log into to production but also pretend to be the production server.

Where to store sensitive information?

Credential and API keys should be kept in a password manager (1Password, BitWarden, etc) or a secrets manager (AWS Secrets Manager, Azure Key Vault, etc).

For local development developers shouldn’t need access to the production environments. Instead they should setup the services they need access to on their local development environment such as a local development database.

For 3rd party services that can’t be installed or mimcied locally developers should be given access to a test/development copy. For example, a test S3 bucket instead of production.

Applications should read sensitive information from environment variables. Most frameworks provide a way to store environment variables in a file, usually called .env, and read this file when the application starts. This file contains key-value pairs and looks like:

DB_USER=username
DB_PASSWORD=password
DB_SERVER=server.com
DB_NAME=prod_db

AWS_S3_BUCKET=prod-bucket.s3.us-east.amazonaws.com
AWS_S3_BUCKET_KEY=production_key
AWS_S3_BUCKET_SECRET=produciton_secrect

The .env should never be committed to the repository and ideally added to the .gitignore or equivalent. Instead I recommended committing a .example.env file to the repository which has all the keys expected but not the values. At least not the production values, but possibly some development values. When a developer first sets up their development environment they copy the .env.example to .env and fill in the missing values that they find in the password manager:

DB_USER=devuser
DB_PASSWORD=<local db password>
DB_SERVER=localhost
DB_NAME=dev_db

AWS_S3_BUCKET=test-bucket.s3.us-east.amazonaws.com
AWS_S3_BUCKET_KEY=<get from password manager>
AWS_S3_BUCKET_SECRET=<get from password manager>

How to fix the problem?

Unfortunately you can’t just remove the sensitive information because it is still viewable in the repository history. Also, it might also exist on others that have forked the repository.

If there are multiple credentials you need to remove then pick one and do the following:

  1. Add the sensitive information to your password or secret manager.
  2. Setup a .env file, or something similar, if it does not exist.
  3. Move the sensitive information to the .env file.
  4. Do a release to test you have the sensitive information migrated correctly. You will need to add the sensitive information to the staging/production environment variables or files.
  5. Change the sensitive information (change password, regenerate API key, etc). This should only require an update to the system and the environment variable in production.

Repeat the above steps for the next piece of sensitive information until they are all removed from the respository.

Additional information:

P.S. – Not related to the above post. I’m just really like the new Blink-182 album.

Do I have to die to hear you miss me
Do I have to die to hear you say goodbye
I don’t want to act like there’s tomorrow
I don’t want to wait to do this one more time
One more time, one more, one more time, one more time



Posted in Security | Tagged , | Comments Off on Don’t Commit Sensitive Information to the Repository

Saturday MP Show #17: Hack the Box – Busqueda (User Flag)

In this episode I find the user flag for the Busqueda machine on Hack the Box. Perhaps with a little help from the walkthrough and Chat GPT to assist with my lack of Python knowledge.

Thanks to Hack the Box for creating a playground for myself, and others, to learn cyber security skills. Thanks to kavigihan for creating the Busqueda machine.

Have question you want answered in a future video? A question I should ask you? Pair on a problem? Constructive feedback? Send an email to ask@saturdaymp.com.

Need help shipping secure high quality software faster? Check out Saturday Morning Productions.

Posted in Saturday MP Show, Security | Tagged , , | Comments Off on Saturday MP Show #17: Hack the Box – Busqueda (User Flag)

Do you Really Need Custom Software?

Custom software is expensive to build and usually delivered late and overbudget. Custom software, like a garden, needs to maintained and frequently updated. Especially for security updates. Everyone, well almost everyone, forgets to budget time and money for maintenance.

Before getting custom software built you should check for an existing solution. I’m willing to bet something does exist. Don’t get hung up on the 10% the custom software can’t do. Look at the 90% of the problem it does solve.

Get custom software built when it will save you more time and/or money then existing solution. When your business has outgrown the existing solutions. When it makes sense.

Posted in Business Side | Tagged , | Comments Off on Do you Really Need Custom Software?

Saturday MP Show #16: Trying out Docker Compose Watch

In this episode I try out the new Docker Compose Watch developer feature that synchronizes files on the host and the container. Similar to Docker Volumes. It won’t replace Docker Volumes for for me, at least not yet. Are you using, or thinking about using, Watch?

I did encounter a known bug where Docker Watch won’t run again after a Ctrl-C stop. You can find a workaround for the issue here.

Thanks to Docker for creating Docker. That sounded weird. Anyway it has been an invaluable tool for creating development environments for my clients.

Have question you want answered in a future video? A question I should ask you? Pair on a problem? Constructive feedback? Send an email to ask@saturdaymp.com.

Need help shipping secure high quality software faster? Check out Saturday Morning Productions consulting.

Posted in Saturday MP Show, Software Development | Tagged , , , | Comments Off on Saturday MP Show #16: Trying out Docker Compose Watch

My Takeaway from Talking to Strangers by Malcolm Gladwell

Taking to Strangers book cover.

Book: Talking to Strangers
Author: Malcolm Gladwell

This book has a lot of stories that include a police stop gone wrong, pyramid scheme, Cuban spies, drinking, sexual assault, and torture. A bit hard to follow all the different stories and pick out a theme for the book. At least for me.

My biggest takeaway was finding the balance between trust and doubt. The book points out that most humans are wired to trust by default. We believe what others say and this trust can override nagging doubts.

At first this seems like a bad thing that we humans are so trusting but the book does a good job of highlighting an example of someone who has doubts by default. In the story about Bernie Madoff, who ran the largest Ponzi scheme in history, Harry Markopolos noticed right away that something was wrong with Madoff’s investments but had trouble convincing people. He started getting paranoid and not trusting anyone which, from my take, made it harder from him to find people to report his suspicions of Madoff too and likely made it hard for the people he did contact to believe him. The chapter ends with the lines:

Then he [Markopolos] dug out his gas mask from his army days. What if they came in using tear gas? He sat at home, guns at the ready – while the rest of us calmly went about our business.

I am too trusting by default and got burned a couple times. For example, contractors working on our home. I ignored the signs and ended up with a partially completed basement reno with lots of problems I had to fix myself or hire someone else to fix.

This book was good reminder to listen to my gut feel that something is not right. Politely but firmly push back and verify if my gut feelings are correct or not. Especially for items that will have a big impact on my life, such as expensive renovation. Just don’t take it too far so I mistrust everyone and end up holed up in my house with guns at the ready.

Posted in Business Side, Takeaways | Tagged , , | Comments Off on My Takeaway from Talking to Strangers by Malcolm Gladwell

Saturday MP Show #15: PR Created for Standard Ruby Linter Bug

I finally create the PR for Standard Ruby Linter Bug I’ve been working on the base several videos and months. I also fix the merge conflict noticed in the previous video.

Read about the bug I’m trying to fix here and the PR here.

Thanks to Test Double for creating Standard! It is a great linter for Ruby projects.

Have question you want answered in a future video? A question I should ask you? Pair on a problem? Constructive feedback? Comment, DM me, or send an email to ask@saturdaymp.com.

Need help shipping secure high quality software faster? Check out Saturday Morning Productions consulting.

Posted in Saturday MP Show, Software Development | Tagged , , , , | Comments Off on Saturday MP Show #15: PR Created for Standard Ruby Linter Bug

XPlugins.iOS.BEMCheckBox v3.0.1 Released (.NET 6.0+ Support)!

BEMCheckBox Example Gif

I’m happy to announce that v3.0.1 of the XPlugins.iOS.BEMCheckBox has been released! This release updates XPlugins.iOS.BEMCheckBox so it can be used in .NET 6.0 and higher projects (e.g. net6.0-ios12). You can find the latest release on NuGet here.

You can ignore the v3.0.0 release. The NuGet package incorrectly listed the minimum iOS version as 16.1 (e.g. net6.0-ios16.1) instead of 12.0 (e.g. net6.0-ios12).

Let me know if you spot an issue or have an improvement by opening an issue.

Thank you Boris-Em for creating BEMCheckBox. Myself, and others, really appreciate it.

Posted in Releases, Software Development | Tagged , , , , | Comments Off on XPlugins.iOS.BEMCheckBox v3.0.1 Released (.NET 6.0+ Support)!

Saturday MP Show #14: Rate Limiting with NGINX and Fail2Ban

A rate limiting demonstration using NGINX and Fail2Ban based on a presentation that I gave at BSides Edmonton in 2022. Follow along with the GitHub repo here.

Be sure to admire the seamless editing due to a power outage issue towards the end of the video.

Thank you to BSides Edmonton for allowing me to present last year. I also had a great time as an attendee at the 2023 conference.

Have question you want answered in a future video? A question I should ask you? Pair on a problem? Constructive feedback? Comment, DM me, or send an email to ask@saturdaymp.com.

Contact me if you need help shipping secure high quality code faster. Learn more at Saturday Morning Productions.

Posted in Uncategorized | Comments Off on Saturday MP Show #14: Rate Limiting with NGINX and Fail2Ban

Saturday MP Show #13: Merge Conflict when trying to create a PR for the Standard Ruby Linter Bug

I attempted to create a pull request (PR) for the Standard Ruby Linter bug I’ve fixed but ran into a merge conflict. Didn’t create the PR but did figure out the solution to the merge conflict that will be fixed in the next video.

Read about the bug I’m trying to fix here. Other videos fixing the Standard Ruby Linter Todo Bug:

Thanks to Test Double for creating Standard! It is a great linter for Ruby projects.

Have question you want answered in a future video? A question I should ask you? Pair on a problem? Constructive feedback? Ping me at ask@saturdaymp.com.

Need help shipping secure high quality software faster? Check out Saturday Morning Productions consulting.

Posted in Saturday MP Show, Software Development | Tagged , , , , | Comments Off on Saturday MP Show #13: Merge Conflict when trying to create a PR for the Standard Ruby Linter Bug

See you at BSides Edmonton 2023

I am excited to announce that I’ll be attending BSides Edmonton this year! I’m looking forward to increasing my cyber security knowledge from the talksCTF, and fellow attendees.

Specially I’m looking to learn the latest best practices for protecting my clients websites and their underlying servers. Is this something you can help me with? If so let me know and we can chat either at the conference or some other time.

I’m also happy to chat about software development, DevOps, legacy code, board games, Warhammer 40K lore, amount other things. I’m also happy to pair on some CTF problems.

Posted in Security | Tagged , | Comments Off on See you at BSides Edmonton 2023