If there is a possibilities that active keys getting exposed in the configuration, then the following ideas can be considered as a solution.
QA process to detect any key exposure
Proper code review has to be done before code merge to avoid conflict.
Process in place to cycle active keys.
Using active key of Operator account on server instead of SON account active key - Whether custom_permission can be used to limit the damage caused by any Key?
Can we make config files encrypted which can be accessed only via their own passphrase?
Is it possible to write SONs code not to be dependent on the active key ?
Any possibility to get certain config value comes from ENV variable?
Shut down SON, change the active key.
Vote out SON
Use Owner key to change the active key.
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
Point of Contact: SON operator
Point of Contact: The community, who can vote out SON