When configuring a software that runs in the back-end to power your mobile or web-application, there are many knobs and switches you can turn.

Generally, there are three common ways to pass configurations into a software:

• Via a configuration file.
• Via a command line argument.
• Via an environment variable.

Many applications allow for a mixed approach, and in some cases one is forced to do so.

Why we advise against more than one way of configuring

Non-transparency and ambiguity are fertile ground for human-error caused cyber incidents like data breaches. Mixing approaches on how to configure a back-end software is causing exactly these problems, and the next subsections show why.

Which configuration takes precedence?

Having configurations communicated to the software using different channels (e.g. via a configuration file, as well as a command line argument) makes it easier to miss things. Furthermore, if the same parameter is set in two ways, it is not always clear which will be the final value.

Troubleshooting

Having configurations in more than one place makes troubleshooting harder, since one needs to check each one every time troubleshooting takes place. In the best case scenario, all is done in a container where steps can easily be traced. In the worst case, one needs to go through execution history of different shells.

Versioning

It is easy to version configuration files, but it is not easy to keep track of environment variables and command line arguments. By using anything else but configuration files, the DevSecOps specialist generally loses the ability to historically audit a setting.

Repeatability

It takes a lot more effort to ensure that command line arguments or environment variables are set when running (or restarting after a defect) a software than to just keep track of one configuration file. This makes the process of running a specific software with a desired configuration harder to repeat on either a different environment or in the case of a sudden need of a restart on the same machine.

Why are people using a mixed approach?

Two of the main reasons we observed why people do use a mixed approach are:

• They ran into issues while setting up the service and found tips on forums like StackOverflow.
• Different team members are assigned to fix issues with a certain piece of software, and both have different preferences.

Our Recommendation

Generally speaking, using a configuration file is always the best way to go. Optimally, the file is not subject to string-replacements during the deploy process. By using a file, it can be part of your code-repository, which then provides a proper way of auditing the file historically, reviewing it properly, and allowing it to be scanned by tools like CoGuard.

‍

‍