#Cisco vstack vulnerability upgrade

In the example above, I truncated the product_tree and known_affected to focus on the elements of the vulnerability statement. If a product is listed at known not affected, an impact statement with details must contain why the product is not affected.Ī complete example with a VEX document is provided in the CSAF 2.0 examples It is also possible to set no_fixed_planned or none_available as remediation actions. If a product is known to be affected, the vendor must include additional remediation information.

Notes - details about the vulnerability.

At least one vulnerability CVE or ID (Not all vulnerabilities may have a CVE, but should have at least one).

Affected status - Whether the product is affected by the vulnerability, regardless of the presence.

Product Tree - Lists all products referenced in the CSAF document.

VEX is a profile in the Draft CSAF 2.0 Standard which allows for organizations to make a statement about whether a product is affected by a vulnerability.Įvery VEX document has the following elements: There is no machine-readable industry-standard protocol to state whether a product is affected by a vulnerability, nor under what conditions result in being affected by a vulnerability. The above actions are necessary because of a major gap:

(In some cases, customers may also transfer the risk via insurance.).

Customers may eliminate the risk by disabling the product.

Customers may mitigate the vulnerability with secondary controls (e.g., firewall, IDS).

Customers may ask their product/vendor representative whether they are affected by the vulnerability.A vendor may post a message on a known website or blog claiming they are not vulnerable.However, this may increase the total cost of ownership higher than necessary.

#Cisco vstack vulnerability upgrade

Customer may create a policy to ALWAYS upgrade when a CVE is present.If the presence of a CVE is not indicative of being affected by a CVE, how do we determine whether we need to take action? The presence of a vulnerability indicates risk but does not indicate whether a product is affected or not.Īpplications depending on libcurl 7.64.1, which is vulnerable to CVE-2019-5436 (libcurl TFTP buffer overflow), are not affected by the vulnerability if they do not use TFTP.Īssuming SBOM adoption solves the problem of knowing what is in our infrastructure, we still don’t know whether a given product is affected by a vulnerability. However, the presence of a vulnerability does not necessarily mean that a product consuming that library is affected.Īn implementation may not exercise the vulnerable feature.Īlternatively, the data sent to the vulnerability may be sufficiently sanitized, preventing the exploit from materializing. Recently, we saw the high-impact announcement of CVE-2021-44228 (Log4Shell).Īnalysts and engineers are inspecting every installation of Java for susceptibility of Log4Shell. CVEs play an essential role in announcing vulnerabilities for a given product or library.