This document products an overview into the security policies, procedures, and guidelines we have in place for software development here at SparkLabs. It is designed for our customers, both current and prospective, so they can assess our approach to keeping our products, notably Viscosity, as secure as possible.

The information in this document covers the details necessary to perform a software vendor risk assessment on the products we produce. With supply chain attacks proving to be a very real threat in recent years, we want to show our customers that we take the security of our products very seriously.

Please note that this document is primarily designed to provide high-level details about our security policies and procedures. It does not cover information on hardening Viscosity or VPN connections. For information on how to best setup and secure your VPN connections, or for technical security details, please refer to the Viscosity product page as well as the documentation available in our support section.

Software Development Guidelines

To help maintain the security of our products, we have a number of policies, procedures, and guidelines that are followed throughout the planning, development, and release stages of our products. This section provides an overview of these security guidelines suitable for public review.

These are covered from a high-level perspective and designed for review by those assessing the security design and support of our products. Guidelines surrounding software and product design principles, development and testing environments, security testing, vulnerability management, and supply chain management are all areas covered in more detail.

Fine-grained detail about our business security mechanisms, such as authentication, storage and network, communication practices, and other similarly important internal implementation details are not publicly available for our own security.

Software Design and Development

An important step in securing our products is adopting design considerations that enforce security-by-default from the very start of software development. Our guidelines and policies include:

Memory-Safe Programming Languages: Memory safe programming languages, such as Swift, C#, and Rust, must be adopted for development where it is possible to do so. The use of these can help prevent common vulnerabilities such as buffer overflows and memory leaks, helping to improve overall application security. Where possible, existing software and components written in more vulnerable languages, such as C/C++/ObjC, should be rewritten using a memory safe language.

Secure Programming Practices: Secure programming practices must be adopted, such as untrusted input validation, data protection using encryption where possible, adhering to least privilege in access controls, and adopting OS-level security frameworks for functionality where available.

Authenticity and Integrity Mechanisms: Mechanisms like cryptographic signatures and hashes must be used to ensure the authenticity and integrity of applications, communication between components, and network communication. Software should be signed using a protected code-signature identity, and this is validated on execution where possible.

Threat Modelling: Internal threat modelling should be used to identify potential security threats and vulnerabilities in the design phase of new software, features, and changes. Any issues found should be resolved or mitigated before deployment and release.

Risk Mitigation: At risk-components should be identified, and extra redundant safety and security checks added to reduce or eliminate the risk from unexpected vulnerabilities in a component or framework. Sandboxing, process separation, and similar isolation techniques should be deployed wherever practical to do so.

These guidelines are followed throughout the software development process to ensure the implementation and the design of our products is as secure as possible.

Development, Testing and Build Environments

Along with ensuring that products have been designed and developed in a secure fashion, we also have guidelines in place to secure the environment the product is developed in. This encompasses everything from the machines used by software developers writing the source code, source code storage, release build environments, and access control. This is addressed with the following policy guidelines:

Environment Separation: Development and production build environments are kept separate to prevent unintended interactions and safeguard the security of production systems. Testing will take place on dedicated testing machines, or in virtual machines, and never in production build environments. All software development is to occur exclusively within the development environments, ensuring that experimental or untested changes do not impact production systems.

Data Handling: Data from production environments is not utilised in development or testing environments unless these environments meet the security standards of the production environment. This practice protects sensitive production data from exposure. If testing using user supplied instructions, input data, or remote networks, all testing is to take place within a temporary isolated and contained environment, such as on a virtual machine.

Security of Source Code and Build Servers: Unauthorised access to the authoritative source code of the product is strictly prohibited, ensuring that only authorised personnel can make changes or access the source. Unauthorised access to the build servers is also strictly prohibited, only authorised personnel can make changes to the build environment, software, and release scripts. Appropriate network and server security must be put in place, including preventing unauthorised network access by requiring access via a VPN connection with strong encryption and two-factor authentication, network security software such as intrusion detection, strong local authentication, antivirus and malware scanning of builds, and similar best-practice server security standards.

Prevention of Unauthorised Modification: Measures must in place to prevent unauthorised modifications to the authoritative source code of the product, preserving the integrity and security of the code. Authenticated version control systems must be used to prevent unauthorised access, and track all changes for review.

Software Updates and Supply Chain Assessment: All software used in development, testing, and building shall be kept up-to-date and monitored for security vulnerabilities. Automated processes should be put into place to identify when new versions to critical software is available to ensure that development and build environments are not left un-patched. The security of software used in development and testing should be assessed to ensure that the software is developed in a secure manner and that any potential future security issues will be quickly addressed.

These guidelines ensure that the environments are well-managed and secure, minimising risks and maintaining the integrity of our products throughout their lifecycle.

Product Security Testing

Product security testing is another essential process we take to help identify potential vulnerabilities. As well as continuous testing throughout the development process, we also undertake explicit security testing and review. In particular:

Continuous Testing: Security review is undertaken consistently throughout the development lifecycle. Additions or changes made to at risk-components are subject to peer review. This should be enforced through access controls, such as commit/PR approval via version control software. Unit testing of core and at risk-components is required to automate general security tests, API and input validation, memory safety, and output consistency.

Static Analysis: Static code analysis should be performed as part of source commit process to automate the review of new code for common security pitfalls and identifying potential weaknesses and known vulnerable code patterns. This should be implemented using static code analysis software that integrates with the version control systems.

Dynamic Analysis: Dynamic runtime program analysis should be performed as part of testing release builds. This should include scanning for potential runtime memory errors and misuse, potentially vulnerable concurrency patterns, and race conditions. This should be automated and integrated into the unit testing process where possible.

Independent Verification: At-risk source code and components should be identified, and periodic independent review undertaken.

Software Bill of Materials

A Software Bill of Materials (SBOM) is a document that lists all open source and commercial software components utilised by the product. Maintaining an SBOM enhances supply chain security by enabling customers to easily identify and manage security risks associated with the specific software components used in products. We have the following guidelines:

Maintain a SBOM: We will maintain an internal SBOM for our primary products as part of our development process and meeting our supply chain assessment guidelines.

Availability to Consumers: We will provide a simplified version of the SBOM for each product on our website for public review. This practice ensures that users have access to detailed component information, facilitating better risk assessment and management in their own environments.

The SBOM for each product is part of this document, which can be found in the sections below.

Resolving and Reporting Vulnerabilities

While the guidelines above work to prevent security vulnerabilities, it's important to acknowledge that vulnerabilities can and do still happen. These may occur due to unexpected behaviour, new classes of software vulnerabilities, vulnerabilities or bugs in third-party frameworks or APIs, or security standards changing (for example faster computers enabling attacks on older algorithms).

Thus we have in place guidelines that ensure that following the identification of a vulnerability in one of our products, it is resolved and reported to product users in a timely manner. These include:

Prompt Investigation and Classification: All vulnerability reports, whether generated internally, or submitted from an external source (such as from a software framework vendor or security researcher) will be investigated, validated, and their severity and product impact classified as soon as possible. Where possible, automated alerts should be put in place to monitor third-party frameworks and APIs for security related updates.

Prompt Resolution: Vulnerabilities must be resolved as quickly as possible, taking into account the severity and product impact. Fast resolution minimises the window of opportunity for attackers to exploit vulnerabilities, thereby protecting our products and their users.

Comprehensive Remediation: In addressing vulnerabilities, we will conduct a thorough root-cause analysis to understand the underlying issue. This analysis aids in resolving not just the immediate vulnerability, but also entire classes of vulnerabilities, ensuring the product is as secure as possible.

Timely Disclosure: Vulnerabilities identified in our products will be disclosed publicly where appropriate and in a timely manner. This transparency helps ensure that users are aware of potential risks and allow them to take preventive measures if necessary. Depending on the vulnerability nature and classification, this may take place through product release notes, website blog posts, and update notifications.

Ease of Resolution: Vulnerability resolutions should not require complex actions by the product's users to apply. Ideally products should support automatic updates, and where possible included security fixes should not require any re-configuration by users to apply. If user action is required, the product should walk the user through the steps required with dialogs, messages, or documentation.

These guidelines are critical for maintaining the trust and safety of our software products and ensuring that vulnerabilities are handled effectively and comprehensively.

Vulnerability Disclosure

We strongly encourage responsible reporting of security vulnerabilities in our products by security researchers. By fostering an environment of collaboration, we aim to improve the security of our products effectively and efficiently. To this end, we have the following guidelines:

Contact Information and Statement: Clear contact information will be provided on our website, detailing how security researchers can report vulnerabilities found in our products. A dedicated security contact email address will be provided. This ensures that all reports are directed to the appropriate channels for prompt attention.

Reporting Timeframe and Action: We have a clear timeframe for acknowledging and addressing reported vulnerabilities. For most submissions researchers should allow up to 7 days for an acknowledgement. For complex submissions researchers should allow up to 14 days. A resolution timeline is communicated to researchers upon validation of their report, ensuring that they understand the process and expected timelines for action. Obvious "beg bounty" and similar invalid submissions will be discarded without acknowledgement.

Recognition of Researchers: Researchers who responsibly report vulnerabilities are recognised and appreciated. We acknowledge their contributions to our security, which can include public acknowledgment, such as thanks in blog posts, release notes, or update notices, or other forms of recognition, depending on the nature and impact of their findings.

This approach to vulnerability disclosure not only enhances the security of our products but also helps to build a constructive relationship with the security research community.

Software Bill of Materials (SBOM)

Please find the Software Bill of Materials (SBOM) for our products provided below. Each SBOM is crafted to list only the components or software that are relevant to a vendor risk assessment. It specifically excludes components or software used solely in the build process, such as IDE software, compiler versions, and package generation tools.

Additionally, it does not detail the versions of the programming languages used, nor does it list components or software that are considered part of the operating system or the core modules/frameworks of the programming language or runtime environment. This approach ensures that the SBOM remains a streamlined and focused resource for assessing potential vendor risks associated with the essential functional components of our software.

Also note that a product may not always use the latest version of components or software: newer versions may not address any security vulnerabilities, or if a vulnerability exists it may be in an unused function or framework and the product has been assessed to be unaffected.

Finally, please be aware that while each SBOM below is regularly updated, these updates are performed manually rather than automatically. As such, there may be occasions when the SBOM does not reflect the latest version of the product. If you require the SBOM for the latest version and the version number listed below does not reflect that, please do not hesitate to contact us to request an update.

Viscosity (macOS) SBOM

Version 1.11.1

Software	Version	Used By	License
libcbor	0.10.2	Viscosity	License
libfido2	1.14.0	Viscosity	License
lwIP	2.1.2	Viscosity	License
LZO	2.10	OpenVPN	License
obfs4proxy	0.0.14	obfs4proxy	License
OpenSSL	3.0.13	Viscosity, OpenVPN	License
OpenVPN	2.6.10	OpenVPN	License
pkcs11-helper	1.30.0	OpenVPN	License
PLCrashReporter	1.11.1	Viscosity	License
Sparkle	2.6.1	Viscosity	License

Viscosity (Windows) SBOM

Version 1.11.1

Software	Version	Used By	License
Driver Module Framework	1.1.145	Viscosity	License
HIDAPI	0.12	libu2f-host	License
JSON-C	0.16	libu2f-host	License
libu2f-host	1.1.10	Viscosity	License
LZO	2.10	OpenVPN	License
obfs4proxy	0.0.14	obfs4proxy	License
OpenSSL	3.0.13	Viscosity, OpenVPN	License
OpenVPN	2.6.10	OpenVPN	License
Pkcs11Interop	1.1.10	Viscosity	License
TAP-Windows6	9.27.0	TAP-Windows6	License

Viscosity Security Information

As a security and privacy product, Viscosity's behaviour understandably comes under extra scrutiny. In particular, queries regarding its use of the network, the security of those network connections, and the security of VPN connections, are common. This section details information beyond the above guidelines for Viscosity's network and security behaviour.

Security of Updates & Outbound Connections

Viscosity will make a number of outbound network connections in normal operation. Besides encrypted VPN connections themselves, software update checks are the most common form of connection and one that we occasionally receive queries about. This support article covers all possible connections Viscosity may attempt to make, and covers the security surrounding update checks to ensure that an attacker can't compromise the update process.

VPN Connections

Viscosity will create an outbound connection when establishing a VPN connection. The destination address/es, IP protocol type and port, encryption level, and other security characteristics are entirely dependent on the configuration of the VPN connection itself. In most instances we recommend getting in touch with your VPN Provider if you require technical details.

If using a client-side process firewall, such as Little Snitch, these connections will be reported to come from an "openvpn" process. When using obfuscation, you'll likely see an "obfsclient" or "obfs4proxy" process connecting to the obfuscation server.

Update Checks and Downloads

Viscosity will check for an available update at most once every 24 hours. Viscosity performs these checks by accessing a XML file on the SparkLabs software update server (swupdate.sparklabs.com) over HTTPS. This file contains the latest version information and is known as an "appcast". If an update is found, the corresponding release notes will also be downloaded from the same server over HTTPS.

When installing an update, Viscosity will automatically download the update from the software update server and then verify that it is a legitimate update that has not been tampered with before installing it. Viscosity uses several verification techniques: a) The download takes place over HTTPS using only valid certificate credentials; b) Viscosity checks the DSA signature of the update using an embedded public key; and c) the code-signature and certificate on the Viscosity app bundle (macOS) or installer (Windows) is verified.

Viscosity does not collect or send any "system profiling" (information about your computer's system) data as part of these checks. Update checks can be disabled using the "Automatically check for updates" setting under the Preferences window, however it's strongly recommended update checks are left enabled.

When configuring an enterprise firewall to allow these connections, please be aware that the software update server is located behind Cloudflare's CDN network. This means that the IP address/es of the software update server will vary, so rules based on the destination IP address alone are not recommended.

DNS Lookups

The Windows version of Viscosity runs its own DNS engine to support features such as Split DNS. Viscosity will make outbound UDP connections on port 53 to the relevant VPN DNS server/s to perform DNS lookups when Split DNS is active for one or more connections. Please note that this does not apply to the Mac version, where Split DNS queries will instead come from the OS.

License Checks

Depending on the serial type and age, Viscosity may phone-home to check that the license details used to register it are valid. It sends a secure irreversible hash (SHA256) of your license details over HTTPS to our server (sparklabs.com or secure.sparklabs.com) to check on the status. The server will return a valid or invalid status. Like with update checks, Viscosity does not collect or send any "system profiling" data.

To remove the ability for an adversary to monitor for these checks Viscosity attempts to perform them through an active VPN connection, rather than over the local network. This prevents a malicious network administrator or country level actor from being able to monitor for connections to our server to identify someone as a Viscosity user. A check will only take place outside of a VPN connection if prior attempts through a VPN connection have been blocked for an extended period of time.

Certificate Revocation Checks

Viscosity is code-signed for added security and part of macOS and Windows developer requirements. When launching Viscosity the operating system (OS) will check and verify the signature to ensure that Viscosity has not been altered or corrupted. As part of this process it may need to contact one or more servers (typically apple.com or microsoft.com domains) to ensure that the certificate/s are valid.

In some instances client-side process firewalls may report these connections coming from Viscosity itself. However these checks are handled entirely by the OS and outside the control of Viscosity.

OpenVPN Protocol Security

For information regarding the security of the OpenVPN protocol, please refer to the Security Overview page on the OpenVPN wiki.

Privacy Policy

Accessing and storing as little data as necessary forms a core part of our product security strategy, minimising the information available for potential attackers to access. Full details are available in the Products section of our privacy policy.

Security Reports

As outlined above, we encourage security researchers to responsibly report any vulnerabilities they discover in our software. For information on how to submit a security report, including contact details, please visit the Security Reports section of our website.

Other Documentation

Occasionally we get asked for a SOC 2 or similar security report. Typically when we’re asked for such reports it’s under the mistaken belief that Viscosity is a service (similar to commercial VPN Service Providers or a cloud provider) and that customer data is passing through our network.

This is not the case: no customer data or VPN network traffic passes through our network or any of our servers. Full details are available in the Products section of our privacy policy.

Contact

If you require any further information regarding the security of our products, please don't hesitate to get in touch.