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 stores service definitions, runtime state, and operational metadata in a shared configuration directory located at %ProgramData%\Servy. Any Windows account configured to run a Servy-managed service must have Read and Write permissions for this directory.

This design allows Servy to remain lightweight and fully compatible with standard Windows service behavior without introducing the complexity of per-service configuration stores or additional privilege separation layers.

Because the configuration directory is shared, Servy does not implement logical isolation between services running under different Windows accounts on the same machine. All services that use the same %ProgramData%\Servy directory operate within a single trust boundary. In practice this means:

• Shared Influence: Any account with write access to %ProgramData%\Servy can potentially modify configuration data or influence the execution behavior of other Servy-managed services on the system.
• Mutual Trust: All Windows accounts assigned to run Servy services should be considered mutually trusted. A compromise of one account may allow indirect influence over other services managed by Servy.
• Target Use Cases: Servy is designed for single-tenant or trusted environments, such as dedicated application servers, developer workstations, and internal infrastructure.
• Workload Restrictions: Servy is not intended for multi-tenant, adversarial, or untrusted workloads where strict isolation between services is required.

If your security requirements require strong isolation guarantees between services running under different identities, consider the following approaches:

1. Machine Isolation: Run unrelated workloads on separate physical or virtual machines.
2. Containerization: Use Windows Containers or Docker to enforce process and filesystem isolation.
3. Hypervisor Boundaries: Deploy services on separate operating system instances to achieve hardware-enforced security boundaries.

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