A word about security
As Octory is highly customisable, it is natural to think about misuses or faults. Or to wonder how the application handles data.
Octory should most often run with the current logged in user privileges. It is strongly not recommended to run it as root. This is why a privileged Helper is provided for Octory features which require root privileges, like storing the MDM API credentials in the keychain, or executing a script with root rights. The implementation of this Helper provides a secure way to execute commands with root privileges. That said, as the application is customisable, it is required to ensure that only the root user can customise it. This is why the application will retrieve configuration files only in two folders: /Library/Application Support/Octory and /Library/Managed Preferences/ (folder where MDM custom configuration profiles are pushed). Those folders can be written only by the root user, but read by most users. Thus, Octory can read in the folders, but it requires root privileges to write Octory configuration profiles in those folders.
The Helper is implemented following Apple guidelines in terms of security using XPC connections. Also, both the Helper and the application are signed with Amaris Developer ID certificate, ensuring that only the application can connect to the Helper, or any other application signed with Amaris Developer ID certificate. Obviously, this certificate is not shared with anyone, even at Amaris. Only a few specific people can use it to notarise applications or sign products.
Octory tries to retrieve information about the system and hardware for it to be used as placeholders, as mentioned on the documentation. This information is internal to Octory, and only available while Octory is running. When the application is terminated, those information are not stored, and the application has to retrieve them again.
Moreover, while the application is running, it does not send anything to the network, except when the admin-user specified a SendRequest. This can be verified by running a network analyser on the device like WireShark.
As mentioned, Octory can send request to an API if the admin-user specifies it. Thus, it has to securely store the credentials to authenticate to the API. To do so, the credentials are once passed as arguments when launching Octory in the command line. Then, those credentials are stored in the system keychain through the privileged Helper. This way, only the root user can access to them, or an application with root privileges, but not the end-user.
It is then up to the admin-user to make sure that no other application will read those credentials if not allowed. Also, the admin-user should think to clear the command line history after having launched Octory with the credentials arguments. This is to prevent those credentials to be retrieved them if the system was hacked and the hacker gained root privileges.
Octory can read any folder which can be read by the end-user themselves and is not sandboxed. This a compromise Amaris makes to avoid the admin-user to authorise every read operation since Catalina. This is why the admin-user has to change some scripts rights to let Octory execute them when they are in a protected folder, like /Library/Application Support/Octory.
Octory will read the MDM or system log files to offer monitoring features. Most often, those log files can be read by any user, and do not contain sensible information. Moreover, the session log file is only stored in the /tmp folder, whereas the log stored in at /Library/Logs/Octory/octory.log contains only information useful for crashes and other similar problems.