What would be the best way to scan a codebase to ensure there are no production-level credentials included in the codebase? We have tried doing Static Scans via some major tools but I do still see some credentials that are still lingering around and possibly more.
What would be the best way to do this?
I'm going to go off tangent here and answer the real problem rather than your presupposed solution.
The way to prevent production credentials from being checked in code repository is to not let developers have production credentials in the first place during development. Have separate development and production credentials and possibly a separate development and operations team. Developers have the ability to check in code but doesn't have access to production environment and doesn't know production credentials; operations have access to production environment and production credentials, but only read access to the code repository. The few people that needs to act as both developer and operations, need to be properly trained to separate development and operations role.
To make this separation easy, you should also never check in the config file to code repository. Instead have an example config and when deploying to new environment, operations should copy this file and modifies that. Developers need to be trained to copy over config changes (e.g. new config entries) to the example config to make an example in the example config.
To be honest, if you allow developers of a significant-sized project to hardcode credentials and push that code to a development repository, then you have a serious code quality problem, and your code will probably need complete, manual, review before it can go to production.
Anyway, simply use all the potential credentials and grep for them. Find the place they're used. Have a stern talk with whoever hard-coded them into source code in the first place. This is really first day tutorial stuff.
The most common approach is to grep the code base looking for when the secrets are assigned. For example, the following regex will match a verity of code that may contain interesting values:
egrep "(secret|password|hmac|access.*key)\s*[:=>]" -iRn .
The above grep will find common hardcoded secrets in config files or elsewhere in code, for example:
aws_secret_key = "..."
<mysqlPassword>...</mysqlPassword>
The only commercial product that can find hard-coded secrets is Checksmarx. This is a source code analysis tool with lots of options, and tons of custom rules to match bad behavior.
You should consider checking the hard way. Go into the code and grep for the interface used to send credentials for authorizing. Examine each instance you find. Walk backwards from each, searching for variables that contain the credential parameters. Grep for each of those variable names, and every place they are accessed.
Ensure that there aren't obfuscated or hidden paths, such as weirdly constructed buffers that feed into the API. Make sure this code isn't using globals or statics that could be injected from (or siphoned off by) other parts of the program.
Because these are credentials, the code carrying them needs to be very simple so that you can review it easily. Any complex code surrounding them should be refactored and simplified until it is transparent and readable.
As a variety of variable names can be used to store the value of the key, it gets difficult to automatically verify the credentials.
One thing that you can try is run the linux command strings to print all the strings stored in the files. Then you can check if any of these are your credentials
