I enjoy developing and maintaining the RecipeRadar[1] project's infrastructure in a truly open fashion.

Since the project itself is AGPL-licensed, that means I like to -- ideally -- push infrastructure documentation and changes before the associated administrative commands are run. As a result, code to the system itself is already published and available (in a chronological sense) to anyone using the service over the network at any given point in time.

However, it does introduce a set of strange risks: what if, for example, planned changes will expose security vulnerabilities that have _not yet_ been introduced, but will be when the commands are run?

In a typical system administration scenario, generally the 'home team' acts carefully and is primarily only aware of their own actions - aside from monitoring for any externally-initiated or unexpected system behaviour during maintenance.

If a mistake is made, sometimes they'll backtrack and clean up, but for some kinds of system change, it's hard to know whether an exposed vulnerability was exploited, because the exposure window may have been very brief.

I have a sense that the best overall solution to this kind of problem (in this kind of open environment) would be an 'adversarial' system administration approach; perhaps involving some kind of mirroring.

Two (or more) systems would walk through the same series of administration steps, each with one (or more) red teams attempting to exploit the process -- already armed with the knowledge of the steps to be applied in advance.

The red teams would then report back on their achievements during the operation, and those findings could be used to improve the tooling and processes using during open system administration.

Does that make sense to anybody, and/or can anyone provide thoughts or reading material about research into this kind of area?

[1] - https://www.reciperadar.com/

[2] - https://github.com/openculinary/infrastructure/