More clearly distinguish vulnerabilities in dependencies

spec.md

@@ -32,6 +32,8 @@ A Coordinated Vulnerability Disclosure is a way of disclosing a Vulnerability in
 
 A Coordinator is a person or organization that coordinates communication and disclosure between multiple parties including Researchers and Organizations.
 
+A Security Advisory is a publication indicating a certain version range of a certain product contains a vulnerability. Such an advisory is commonly published by the Organization as the result of the Coordinated Vulnerability Disclosure process, but may also be published by third parties.
+
 ## Vulnerability Reporting Policy
 
 An Organization MUST have a method to deal with vulnerability reports, resolution of issues and distribution of fixes, mitigations, or information.
@@ -70,7 +72,7 @@ If the Organization is distributing software in the binary form, the software MU
 
 ## Vulnerability sources
 
-Organizations accept vulnerabilities from multiple sources and they MUST accept vulnerability reports from external and internal Researchers. If it does trace Vulnerabilities in dependencies using SBOM, it MUST also accept reporting from automatic tools.
+Organizations accept vulnerability reports from multiple sources. They MUST accept vulnerability reports from external and internal Researchers.
 
 ### External reporting
 
@@ -82,17 +84,13 @@ If an Organization is hosting multiple software Products, they MAY have specific
 
 Organizations MUST apply the same processes for internal and external vulnerability reporting.
 
-### Automated reporting
-
-Organizations SHOULD trace disclosed vulnerabilities in dependencies.
-
 ## Vulnerability handling inside an organization
 
 Organizations MUST clearly assign potential vulnerability management to a group or individuals.
 
 All Vulnerabilities MUST be resolved: either fixed, or mitigated, or documented. The resolution time depends on the vulnerability type, but it MUST be reasonable.
 
-If during the analysis the organization finds out that the cause of a Vulnerability is located in a product that is a dependency, the Organization MUST report the Vulnerability to the upstream project, using one of their official vulnerability reporting channels. The communication between multiple Organizations follows the rules of Coordinated Vulnerability Handling and Disclosure.
+If during the analysis the Organization finds out that the cause of a Vulnerability is located in a dependency, the Organization MUST report the Vulnerability to the upstream project, using one of their official vulnerability reporting channels. The communication between Organizations follows the rules of Coordinated Vulnerability Handling and Disclosure.
 
 In case if the upstream Organization does not provide a fix in a reasonable timeline, the Organization MAY provide a fix or a mitigation.
 
@@ -108,7 +106,7 @@ In case of such a multi-party vulnerability handling, all parties SHOULD agree o
 
 ## Vulnerability publication
 
-The Organization MUST publish all resolved vulnerabilities. Each Organization MUST publish a list of all publicly known Vulnerabilities in their products. This publication SHOULD happen on a web page and SHOULD offer a machine-readable version.
+The Organization MUST publish a Security Advisory for each resolved vulnerability in their own product, and publish a list of these advisories. This publication SHOULD happen on a web page and SHOULD offer a machine-readable version.
 
 The publication of the list of known Vulnerabilities takes a form of a list of their identification (one or multiple ones) and at least one link to a public resource describing this Vulnerability (at least the affected product and versions, affected configurations and a general description) and SHOULD include an estimation of severity of the Vulnerability. The Organization MAY include additional information.
 
@@ -135,6 +133,32 @@ Tobie Langel.
 
 _If you have contributed to this specification and aren't properly acknowledged or if you want to edit or remove your name, please let us know by [opening an issue](https://github.com/orcwg/vulnerability-management-spec/issues/new) and we will fix this right away._
 
+## Advisories for dependencies
+
+Organizations SHOULD trace Security Advisories for dependencies.
+They MAY leverage SBOMs for this purpose.
+They MAY use their vulnerability handling process for these potential issues.
+
+Organizations MAY publish a statement on a web page specifying whether advisories for 3rd-party dependencies affect their product.
+If so, they SHOULD provide a machine-readable version.
+
+## Acknowledgement
+
+The following people have contributed to this document either directly or indirectly (e.g. by raising questions):
+Arnout Engelen,
+Daniel Thompson-Yvetot,
+Dick Brooks,
+Jakub Zelenka,
+Jeremy Stanley,
+Lars Francke,
+Maarten Aertsen,
+Marta Rybczynska,
+Mikaël Barbero,
+Simon Phipps, and
+Tobie Langel.
+
+_If you have contributed to this specification and aren't properly acknowledged or if you want to edit or remove your name, please let us know by [opening an issue](https://github.com/orcwg/vulnerability-management-spec/issues/new) and we will fix this right away._
+
 ## References
 
 [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119)