Vulnerabilities and Security Practices in Xceed Products

At Xceed, security is a priority in the design, development, and maintenance of our products. The following information outlines how vulnerabilities are managed, what types of network activity our components perform, and the general security profile of Xceed libraries.

1. Relationship Between Xceed Products and .NET

All Xceed libraries are built on top of Microsoft’s .NET framework (or .NET Core/.NET 5+). They follow established best practices for .NET development and do not introduce security risks beyond what is inherent to the underlying platform.

• Primary consideration: Any potential security concerns typically originate from the .NET runtime or environment configuration rather than from the Xceed code itself.
• Best practice: Keep your .NET runtime up to date with the latest stable release from Microsoft, as updates often include important security patches.

2. Vulnerability Reporting

We encourage responsible disclosure.

• If you believe you have found a security vulnerability or receive a report from a scanning tool, please contact us immediately at support@xceed.com.
• In our experience, most reports fall into one of two categories:
  1. False positives — results flagged by automated security scanners that are not actual exploitable vulnerabilities.
  2. .NET-level issues — concerns related to the framework or runtime environment, not to the Xceed product itself.

We will review all reports promptly and work with you to determine the source of the issue.

3. Cybersecurity Profile of Xceed Products

By design, the vast majority of Xceed products are self-contained libraries with no outbound network communication. Specifically:

• No HTTP requests or background internet interactions are performed.
• No telemetry, “call home” behavior, or data collection is built into any Xceed library.

En only exception is Xceed SFTP/FTP for .NET, which performs network transfers only when explicitly configured by the user. In these cases:

• The connection details, credentials, and transfer targets are entirely under user control.
• The library does not initiate connections on its own and does not store or transmit any information outside of the configured transfer operation.

4. Secure Development Practices

To help ensure our products remain safe:

• We follow secure coding practices and avoid deprecated or insecure APIs.
• Source code is regularly reviewed and maintained by experienced developers.
• Dependencies are kept to a minimum, reducing the attack surface and external risk factors.

5. Customer Recommendations

To maintain a secure deployment:

1. Update regularly — Always use the latest stable version of both the Xceed product and the .NET runtime.
2. Use secure configurations — For network-enabled components (such as SFTP/FTP), configure connections using strong encryption (e.g., SFTP over SSH) and avoid plain-text credentials.
3. Scan your environment holistically — Focus on the hosting environment, runtime, and third-party dependencies, as these are more likely to be the origin of vulnerabilities than the Xceed library itself.