Security

Table of Contents

1. Overview
2. Supply Chain Security
3. Security Model & Limitations
4. File Locations
5. Changing Keys
6. Exporting and Recovering Services
7. Windows Reinstallation or Machine Migration
8. Best Practices
9. Troubleshooting

Overview

Servy securely encrypts stored passwords, environment variables, and process parameters using AES encryption.

The AES encryption key and initialization vector (IV) are protected using Windows Data Protection API (DPAPI) with the LocalMachine scope. This ensures the key material can only be decrypted on the same machine where it was created, and is protected by the operating system.

All official Servy executables and installers are digitally signed using a trusted code-signing certificate provided by the SignPath Foundation. This allows users and automated systems to verify the authenticity and integrity of Servy binaries.

Servy has been reviewed by Microsoft Security Intelligence and is classified as safe. It performs only standard installation and service-management operations and does not include malware, adware, or unwanted software. Servy passes VirusTotal scans and is distributed through well-known package managers including Windows Package Manager (WinGet), Chocolatey, and Scoop. Official releases are available from GitHub and these package managers.

Supply Chain Security

Servy publishes Software Bills of Materials (SBOMs) for official releases in CycloneDX format. These SBOMs document all production dependencies used to build Servy and allow users and organizations to independently assess supply-chain risk and license compliance.

The Servy source repository uses GitHub Dependabot to monitor third-party dependencies for known security vulnerabilities. When vulnerabilities are identified, Dependabot generates security alerts and notifications to update affected dependencies, allowing issues to be reviewed and updates to be applied as appropriate.

Combined with reproducible builds, signed binaries, and trusted distribution channels, this provides transparency into Servy's dependency graph and reduces supply-chain risk.

Security Model & Limitations

Servy manages service definitions and related state in a shared configuration directory under %ProgramData%\Servy. All accounts running Servy services must have write access to %ProgramData%\Servy.

Servy does not implement isolation between different Windows accounts or services that share this configuration directory. In practice this means:

• Any account with write access to %ProgramData%\Servy may be able to influence the configuration or behavior of other Servy-managed services on the same machine.
• You should treat all accounts used to run Servy services that share this directory as being in the same trust boundary.
• Servy is not intended for multi-tenant or hostile/untrusted workloads, or for scenarios where services running under different accounts must be strictly isolated from each other. If you require strict isolation between services, consider using separate machines/VMs or alternative mechanisms that enforce per-service isolation between Windows accounts.

File Locations

Servy stores the AES key and IV in the following files:

# AES Key
%ProgramData%\Servy\security\aes_key.dat

# AES IV
%ProgramData%\Servy\security\aes_iv.dat

Changing Keys

You can replace the AES key and IV by modifying the files above.

Changing either file will make all previously encrypted passwords impossible to decrypt.

Only replace these files if:

• You are setting up a new Servy installation
• You have a migration plan to re-enter or re-encrypt credentials

Exporting and recovering services

Service configurations can be exported to XML or JSON for backup or migration purposes.

Important considerations:

• Passwords and other secrets are exported in plaintext
• Exported files must be treated as highly sensitive
• After importing services into a new installation, secrets are re-encrypted during service installation using the new system's DPAPI keys

Because exported configuration files may contain secrets in plaintext:

• Exports should be stored securely
• Access to export files should be restricted
• Export files should not be committed to source control or shared insecurely

Once services are installed, secrets are protected at rest using DPAPI and are no longer stored in plaintext.

Windows reinstallation or machine migration

Because DPAPI keys are tied to a specific Windows installation, encrypted secrets cannot be recovered after a clean OS reinstall.

If you want to recover services from a previous Servy installation, you must:

• Export services from the original installation
• Import the exported services into the new installation
• Install each service individually

Service definitions and non-sensitive configuration are restored automatically.

Best Practices

• Backup first: Keep a secure backup of the existing key and IV before making changes
• Restart required: Restart the Servy app after modifying these files
• Restrict access: Limit access to the %ProgramData%\Servy\security folder so only trusted administrators can read/write these files
• Do not share across machines: Because DPAPI LocalMachine scope is used, copying the files to another machine will not work

Troubleshooting

• Encryption errors: If Servy cannot decrypt stored passwords, verify that the key and IV files exist and are intact
• Corrupted files: If either file is corrupted or partially overwritten, previously encrypted passwords will be unrecoverable
• Permissions issues: Ensure Servy app have sufficient access to read the key and IV files in %ProgramData%\Servy\security
• User account mismatch: Although LocalMachine scope is used, very restrictive security settings may prevent some service accounts from accessing the files