In a word…. yes. And here’s why.
You trust your engineers - but they don’t need production secrets by default
The principle of least privilege dictates that systems and people run with, by default, the lowest level of permissions to carry out their daily tasks. For things that require more, this should be elevated to for a period of time and then reduced.
This helps to defend against risks such as:
- An engineer having their user account compromised.
- Source code is unintentionally leaked.
Using this model, the attacker or folks on the internet would be able to see source code (which could be a problem in itself!) but would not be able to read production secrets without having to undergo additional authentication and authorisation checks. These checks would hopefully thwart their efforts.
Client expectation
This is especially true if your client base includes large enterprises or financial institutions, although all clients have a right to this in our view.
Frequently aspects of security questionnaires will revolve around best application security development practices. Generally these call out specific requirements on how the access to production secrets are controlled. Being able to answer such questions confidently opens the door to new business opportunities and is a win for everyone involved.
A key expires or is leaked
When production secrets are hard-coded, maintaining them can be highly complex, require numerous code changed in multiple systems and cause down time during the switch over.
This can be avoided by moving secrets out into better alternatives (read on to find out more!).
Regulations and compliance
In addition to the already discussed client expectations, your businesses specific regulatory and compliance obligations may need to be factored in.
How can you say that you know who accesses client data, when there is a production service account database connection string in the codebase that everyone can access?!
I get the problem. What should we do?
Fortunately, there are a lots of options.
- If you are operating in the cloud, investigate your cloud service providers secrets management tools. Azure KeyVault and AWS/GCP Secrets Manager all enable you to securely store secrets, control their expiry and rotation as well as control access using groups and other mechanisms.
- If you are on prem, investigate other secrets management tools. These provide similar functionality to the above cloud offerings but specific to your environment.
How can we be sure our source code doesn't contain secrets?
Vulnerabilities.io has been designed from the ground up to surface real risks. This includes finding secrets wherever they may lurk in source control. Frequently secrets identification tools can yield a high number of false positives, making it hard to see the wood for the trees and losing engineering buy-in. Vulnerabilities.io avoids this and shows you tangible issues.
