|
1 | 1 | --- |
2 | 2 | title: Security Advisories |
3 | | -reviewed: 2025-03-18 |
| 3 | +reviewed: 2026-05-29 |
4 | 4 | suppressRelated: true |
5 | 5 | --- |
6 | 6 |
|
7 | | -* [Security Advisory 2022-12-06](cryptography-xml-vulnerability.md) |
8 | | - * System.Security.Cryptography.Xml vulnerability (CVE-2022-34716) in NServiceBus |
9 | | -* [Security Advisory 2020-03-11](servicepulse-directorytraversal.md) |
10 | | - * ServicePulse Directory Traversal vulnerability. |
11 | | -* [Security Advisory 2017-01-10](msmq-permissions.md) |
12 | | - * MSMQ permissions vulnerability. |
13 | | -* [Security Advisory 2016-07-05](sqlserver-sqlinjection.md) |
14 | | - * NServiceBus SQL Server Transport injection vulnerability. |
| 7 | +## Security Vulnerabilities |
| 8 | + |
| 9 | +Particular Software investigates, assesses, remediates, and discloses security vulnerabilities identified in its own code in a coordinated manner aligned with standard industry disclosure practices. |
| 10 | + |
| 11 | +When a security vulnerability is confirmed, its scope, severity, exploitability, and potential customer impact are evaluated. This assessment may include code review, testing, security analysis tools, and industry-standard severity frameworks such as CVSS. |
| 12 | + |
| 13 | +Depending on the nature of the issue, remediation may include one or more of the following actions: |
| 14 | + |
| 15 | +- releasing a patch that removes the vulnerability |
| 16 | +- applying mitigations that reduce the likelihood or impact of exploitation |
| 17 | +- removing or disabling affected functionality |
| 18 | +- making architectural or design changes where necessary |
| 19 | + |
| 20 | +For vulnerabilities that require confidentiality prior to release, investigation and remediation may be performed in a private repository or other non-public development environment until a fix is ready. This helps reduce the risk of premature disclosure before customers can apply an update. |
| 21 | + |
| 22 | +Where appropriate, temporary protective measures may also be taken, such as unlisting packages or removing releases, to limit further exposure while a remediation is being prepared. |
| 23 | + |
| 24 | +Security fixes and related communications are coordinated so that remediation is available before or at the time of public disclosure. |
| 25 | +Advisories are listed on the [Published Advisories](published-advisories.md) page and may be accompanied by additional customer communication when warranted. |
| 26 | + |
| 27 | +Public disclosures will typically include: |
| 28 | + |
| 29 | +- the affected product or repository scope |
| 30 | +- affected versions |
| 31 | +- remediation or mitigation guidance |
| 32 | +- fix availability status |
| 33 | + |
| 34 | +## Dependency Vulnerabilities Process |
| 35 | + |
| 36 | +Particular Software maintains an automated process to identify, assess, track, and remediate vulnerabilities affecting both direct and transitive software dependencies used in its repositories. |
| 37 | + |
| 38 | +### 1. Detection |
| 39 | + |
| 40 | +Automated dependency auditing is used to detect known vulnerable packages, including vulnerabilities introduced through transitive dependencies. Detection is based on published vulnerability intelligence associated with package ecosystems and GitHub Security Advisory identifiers. |
| 41 | + |
| 42 | +When a vulnerability is detected, the automation records the advisory using its unique `GitHubAdvisoryId` and begins coordinated tracking. |
| 43 | + |
| 44 | +### 2. Centralized internal triage |
| 45 | + |
| 46 | +For each newly detected dependency vulnerability, a centralized internal tracking issue is created that serves as the coordination point for security review, prioritization, remediation planning, and status tracking. |
| 47 | + |
| 48 | +### 3. Repository and branch impact assessment |
| 49 | + |
| 50 | +After initial recording, the affected repositories and versions are determined. For each affected repository/version combination, the system creates a GitHub issue labeled as `Dependency CVE` that includes the advisory reference and necessary context. |
| 51 | +Customers can subscribe to these issues to receive updates on the vulnerability status and remediation progress. |
| 52 | + |
| 53 | +If customers cannot wait for a fix to be released, they can [pin transitive dependencies](https://learn.microsoft.com/en-us/nuget/concepts/auditing-packages#transitive-packages) until a fix is released. |
| 54 | + |
| 55 | +### 4. Remediation |
| 56 | + |
| 57 | +Dependency vulnerabilities are remediated by one or more of the following actions: |
| 58 | + |
| 59 | +- upgrading the affected package to a version that resolves the vulnerability |
| 60 | +- upgrading a parent dependency that resolves the transitive vulnerability |
| 61 | +- removing the vulnerable dependency path |
| 62 | +- applying another documented mitigation where no fixed version is yet available |
| 63 | + |
| 64 | +### 5. Disclosure and external communication |
| 65 | + |
| 66 | +For dependency vulnerabilities discovered through public advisories, the upstream advisory and CVE record are treated as the authoritative public source for the vulnerability. |
| 67 | + |
| 68 | +Dependency vulnerabilities that have been addressed in the platform are listed on the [Dependency Vulnerabilities](dependency-vulnerabilities.md) page. |
| 69 | + |
| 70 | +The following will be disclosed: |
| 71 | + |
| 72 | +- the affected product or repository scope |
| 73 | +- the relevant advisory or CVE identifier |
| 74 | +- affected versions |
| 75 | +- remediation or mitigation guidance |
| 76 | +- fix availability status |
| 77 | + |
0 commit comments