Security policy

This document outlines the risks associated with using PostSharp or Metalama and describes our policies for addressing security vulnerabilities.

Trust boundary

Like the .NET SDK itself, PostSharp and Metalama execute your source code and your NuGet dependencies at build time, and they assume that both are trusted. Vetting what enters your build is outside the scope of these products. This document describes the security of the products themselves, not of the code they compile.

Network access

PostSharp and Metalama are compilers and/or IDE plug-ins that run locally on development workstations or build agents. They open no network port and cannot be reached over the network from another machine. They do use local inter-process channels which are reachable by other processes on the same machine. The products themselves make outbound connections only to our own servers (under postsharp.net and metalama.net) for license registration and auditing, for telemetry, and to fetch the product news feed. As part of the build, the .NET SDK also restores our NuGet packages from your configured package sources, which makes its own outbound connections like any other dependency.

Please refer to our privacy policy for details about the data we collect.

Sensitive data

Your source code and compiled code never leave your workstation or build agent; we do not collect or process them.

We do process a limited amount of personal data:

  • License metering and auditing verify license compliance. This feature sends the full license key, a one-way hash of your operating-system user name, a one-way hash of a machine identifier (rotated monthly), and the product edition, version, and license type. Metalama’s license auditing sends the full license key, the license type, the product version and date of use, and pseudonymous identifiers of the device and user.
  • Telemetry, when enabled, collects technical configuration, feature usage, project metrics, and redacted error reports, tagged with a randomly generated pseudonymous machine identifier, different from the one used for license auditing (also rotated monthly).

Both PostSharp and Metalama send this data to our servers.

Additionally, Metalama’s telemetry implementation sends pseudonymized data to Matomo Cloud (InnoCraft). Your license key or its hash is never sent to Matomo.

We do not store your IP address with this data.

Risk assessment and mitigation

Because our products open no network port, vulnerabilities in Metalama, PostSharp, or their dependencies are very unlikely to be exploitable remotely. The realistic attack surface is local: an attacker who already runs code as a different user on the same machine (which mainly matters on shared or multi-user build agents), or one positioned between your machine and our servers (a man-in-the-middle).

Beyond your source code, our products also read a few other inputs: the product news feed, content feeds, and the design-time channel between the analyzer and the IDE. We have hardened the parsing of these inputs to prevent a compromise of our servers, or a malicious local process, from turning them into code execution on your machine. As with any such hardening, this reduces the risk but cannot eliminate it entirely.

The most critical risk associated with our products is a supply chain attack, where malicious code could be injected into our products not to harm our own company, but our customers. Such an attack could target either our organization or one of our dependencies.

To mitigate this risk, we implement the following measures:

  • Dependency audits: We regularly audit our dependencies using automated tools such as NuGet Package Vulnerability Scanner and GitHub Dependabot to identify known vulnerabilities. Any flagged issues are promptly assessed and addressed if necessary.

    Most vulnerabilities in dependencies require network exposure or untrusted input to be exploited. Our products expose no network service, and the limited external data they do read (the news and content feeds, and the IDE channel) is parsed defensively. Consequently, very few vulnerabilities in dependencies require action on our part.

  • AI-based security audits: We periodically use an AI model to audit the entire codebase for security and privacy weaknesses. Every finding and proposed fix is reviewed, corrected, and tested by a human before release.

  • Hardware security keys: All accounts sign in with hardware security keys (FIDO2) on every device or online service; passwords or software alone do not grant access.

  • Privileged access workstations: We treat every developer machine as potentially compromised, so access to our CI/CD pipeline and production environments comes only from dedicated, hardened workstations. Each sign-in requires a physical touch on a security key, which no software on a compromised machine can supply on its own.

  • Binary signing: We sign our binaries using an Authenticode key stored on a secure and isolated device, separate from build agents and development machines. Before signing, we scan the binaries for known malware.

  • Source availability: Metalama is open source. PostSharp is available as source code to enterprise customers under a source-available license, going back to version 1.0. In both cases, customers can audit the source code and build the product using their own infrastructure.

Supported versions

How we apply a security fix depends on the servicing phase of your version:

  • Current and Long-Term Support (LTS) versions: we fix all reported vulnerabilities.
  • Extended Support versions: we proactively fix only serious vulnerabilities, those significant enough to warrant a published security advisory (typically High severity or above), and address lower-severity issues on request.

Versions that have reached the end of their support window do not receive security fixes. Please ensure that you are using a supported version. The list of supported versions is maintained in the Version and Support Policy.

Reporting a vulnerability

Report vulnerabilities privately through GitHub Security Advisories, using the Report a vulnerability button on the Security tab of the relevant repository:

This keeps the report private until a fix is available.

We aim to acknowledge vulnerability reports within 24 hours and provide a resolution or mitigation plan within three days, depending on the severity of the issue.

If you do not receive a prompt response, or in case of emergency, please contact us by phone.