Tanzu External Vulnerability Response and Remediation Policy
Article ID: 405328
Updated On:
Products
Issue/Introduction
Report Vulnerability
Tanzu provides critical infrastructure for applications and application platforms. Tanzu works hard to build products that customers trust, and they depend on timely updates to vulnerabilities. This policy explains the processes followed by Tanzu product and security teams.
Tanzu Security Response Center
A top priority for Tanzu is to maintain the trust afforded to us by our customers. We recognize that unless our products meet high standards for security, customers will not be able to use them with confidence. To achieve this, the Tanzu Product Security Incident Response Team maintains a program to identify, respond to, and address vulnerabilities.
This publication documents our policies for addressing vulnerabilities in Tanzu Products, describes under what circumstances we will issue a CVE identifier and Tanzu Security Advisory. It explains how to report a vulnerability in Tanzu-maintained code, defines terminology used in our publications, documents our commitment to safe harbor practices, and provides information about how Tanzu processes vulnerabilities.
Resolution
How to Report Vulnerabilities
If you believe you have found a vulnerability in a Tanzu product or service, please let us know by sending a private email to [email protected] or by opening a support ticket. We suggest that you use encrypted email to submit your reports. Please be sure to contact your account team so they can assist in coordinating meetings as necessary with the Tanzu Security Team.
Tanzu follows responsible vulnerability disclosure guidelines, during which the researcher privately reports the newly discovered vulnerability in Tanzu’s products and services directly to Tanzu. This allows Tanzu to address the vulnerability in the impacted product and services before any party publicly discloses the vulnerability/exploit details. Tanzu may credit the researcher following responsible vulnerability disclosure guidelines for vulnerability discovery and reporting.
Tanzu response timelines are dependent upon several factors such as severity, complexity, impact, and product life cycle. Tanzu aims to publish fix or corrective actions to customers as follows:
-
- Critical: Begin work on a fix or corrective action immediately and provide the fix to customers in the shortest commercially reasonable time.
- Important: Deliver a fix in the next planned maintenance or update release of the product, where relevant.
- Moderate, Low: Deliver a fix with the next planned release of the product.
If you are a Tanzu customer, we advise you to create a support request (SR) with the Broadcom Global Support Services team.
Understanding Severity & Common Vulnerabilities and Exposures
Tanzu Severity Definitions
Tanzu publications use the industry-standard Common Vulnerability Scoring System (CVSS), in addition to qualitative severity terminology that aligns with FIRST standards.
Tanzu Qualitative Rating FIRST Qualitative Rating CVSS Score
Critical Critical 9.0 – 10.0
Important High 7.0 – 8.9
Moderate Medium 4.0 – 6.9
Low Low 0.1 – 3.9
None None 0.0
Note: The Tanzu qualitative rating may change and does not depend only on the CVSS scoring. The rating given to a specific vulnerability may change at the discretion of Tanzu's security team and our engineering triage process.
Common Vulnerabilities and Exposures (CVEs) Identifiers
Tanzu uses VMware as an approved CVE Numbering Authority (CNA), VMware is authorized to assign CVE identifiers to vulnerabilities affecting products within our distinct, agreed upon scope.
VMware shall issue a Tanzu CVE identifier for a vulnerability when it meets all the following criteria:
-
- The vulnerability is the result of unexpected behavior in Tanzu-maintained code.
- The vulnerability results in a concrete confidentiality, integrity, or availability compromise.
- The vulnerability exists in one or more currently supported Tanzu products documented in the Broadcom Support Portal Product Lifecycle section (requires a free account in the Broadcom Support portal) or the vulnerability exists in a Tanzu-maintained open-source project that is currently supported.
Tanzu Security Advisories
Tanzu discloses vulnerabilities in Tanzu Security Advisories, may include the following information:
-
- Qualitative Severity Information
- CVSS Scoring
- Affected product suites that are currently supported
- Vulnerability Descriptions
- Currently Known Attack Vectors
- Remediation Information
- Workarounds for Critical Severity Vulnerabilities (if possible)
- Notes containing confirmation, if exploitation is happening in the wild
Keep up to date on the latest vulnerabilities
Tanzu Security Advisories (requires Registration/Login)
Cloud Foundry Weekly - Security Update "into the DMZ"
Tanzu Vulnerability Processes
Vulnerabilities are discovered through customer or third party submissions to the Tanzu Security Response Center, or through internal tooling used by Tanzu: the Tanzu Vulnerability Service, or TVS. TVS enables Tanzu to track vulnerabilities and triage through its products, product components, and release lines that customers depend on.
Tanzu performs regular penetration tests on its products and services.
The vulnerability triage data is available to customers through Tanzu Security Advisories, Tanzu Telemetry reports, Tanzu Platform Vulnerability Insights (upcoming release), Product Release notes (e.g. available at VMware Tanzu® Platform for Cloud Foundry), or custom reports generated by Tanzu Security and your Tanzu Account Team.
Tanzu aims to address software vulnerabilities, including reports from the How to Report Vulnerabilities section above, and to provide updates to customers in the shortest commercially reasonable time. This can take place in the next GA or patch release, or for vulnerabilities deemed highly critical, work-arounds or patches will be available as fast as reasonably possible.
Every product is a collection of release artifacts. For example, Tanzu Platform for Cloud Foundry has multiple Buildpacks and Diego cells, plus CredHub, BOSH, Tanzu Operations Manager, UAA, Cloud Controller, etc. Each of these components is included in a release artifact and every component has an associated SBOM that makes up the inventory of every component build.
Tanzu aims to continuously scan SBOMs for all supported product lines. Any CVEs identified result in internal tickets in the product ticketing system. Tanzu engineering teams review the tickets and update the vulnerable dependencies, or document the triage status for vulnerabilities following the CycloneDX analysis specification, as detailed in the next section.
When a component team updates a product component dependency and create a new build that resolves a vulnerability, TVS will process the new build SBOM and automatically close the ticket, documenting in the CycloneDX analysis section that the vulnerability was resolved.
CycloneDX analysis - TVS Triage Data Field Values
Triage data is entered using the CycloneDX specification for vulnerability analysis.
An abbreviated guide to the CycloneDX triage state used by Tanzu and the associated values is provided below.
State:
"in_triage"
-
-
- The vulnerability is being investigated. This is the default state for all new CVEs in TVS.
-
"resolved"
-
-
- The vulnerability has been remediated. This is generally automated when the component SBOM reflects that the vulnerable component has been updated.
-
"exploitable"
-
-
- If the vulnerability has been correctly identified and may have impact (even if that impact differs from the scored severity). When “exploitable” is selected, the response field will contain “can_not_fix” if there is no fix available, or will_not_fix if the fix will not be done; details will be included in the Notes field.
-
"false_positive"
-
-
- The vulnerability is not specific to the component or service and was falsely identified or associated. Context on “false_positive” status is available in the Notes field. For example, this state might be used if a component was misidentified or a vulnerability was incorrectly matched by the scanner or if the component version and vulnerability matching is correct, but the vulnerability database incorrectly lists this version as affected.
-
exploitable: "not_affected"
-
-
- The component or service is not affected by the vulnerability. Justification should be specified for all “not_affected” cases.
-
Justification:
"code_not_present"
-
-
- This status is used for scenarios in which vulnerable source code has been correctly identified, but we have validated that this code is not present or not executable; e.g., source code containing the vulnerability is on disk, but is not used.
-
"code_not_reachable"
-
-
- This status is used for scenarios in which vulnerable code is correctly identified, but which cannot possibly be executed via an “expected interaction.”
-
"requires_configuration"
-
-
- If the vulnerability only occurs with a particular configuration that is not being used and that cannot be configured by the customer; e.g., if a particular option is turned on, a service has a vulnerability, but our configuration sets this to off and it is not possible for a customer to change this configuration via normal means.
-
"requires_dependency"
-
-
- If the vulnerability is only exploitable when another piece of software is present, and that software is not present and cannot be configured to be present by the customer via normal means.
-
"requires_environment"
-
-
- If the vulnerability is only exploitable if the software in question is deployed on a particular type of machine that it is not, and cannot be, deployed on; e.g., the vulnerability is an exploit executed via a web interface, but this code is never deployed alongside a web server.
-
"protected_by_compiler"
-
-
- If the vulnerability is only exploitable when a specific compiler flag is used, and this flag is not normally used, and its use cannot be configured by the customer.
-
"protected_at_runtime"
-
-
- If the vulnerability is correctly identified as present, but there is no normal way for it to be executed at runtime; e.g., exploitable web application code that is not actually served.
-
"protected_at_perimeter"
-
-
- If the vulnerability is correctly identified as present, but its deployment is configured such that there are no normal ways for an attacker to reach the code and no ways for a customer to configure the deployment such that it could be.
-
"protected_by_mitigating_control"
-
-
- If the vulnerability is correctly identified as present, but specific actions have been taken that prevent an exploit from taking place ;e.g., the vulnerable code exists as part of a Ruby library, but other app code has been added to monkey-patch this library with additional checks that prevent the attack.
-
Response / Detail (Notes):
The Detail or Notes string will document any workarounds or details regarding the status, or other information relevant to the vulnerability.
"can_not_fix"
-
-
- Cannot fix, or the fix is unavailable; e.g., there is an upstream security notice for a vulnerability stating that it will not be fixed.
-
"will_not_fix"
-
-
- Will not fix. The Notes field will briefly describe what complicates the fix and the expected impact, in addition to describing any workaround.
-
Terminology
Many familiar words in the software vulnerability domain are overloaded, so our team uses some very specific terms to describe the concepts involved in the triage process.
Release Artifact
“Release Artifacts” are the versioned components that make up a product. In almost all cases in Tanzu Platform for Cloud Foundry, these are BOSH releases. The system assumes that each release artifact version represents a unique set of bits.
Product
A product is any versioned collection of release artifacts that ship together. In the case of TPCF, products are generally one-to-one with software that is shipped to customers e.g. TPCF, the MySQL tile, etc.
Product Line
A product line is the name we use to refer to the set of patch versions for a given major.minor semver line. e.g., 10.0.x is a Tanzu Platform for Cloud Foundry product line that includes 10.0.1, 10.0.2, and so on.
GA Release
GA Release or “Generally Available” Release is the term is used to refer to any officially released patch version in a product line e.g. 6.0.5 is currently the most recent GA Release for the Tanzu Application Service 6.0.x product line.
SBOM
SBOM is an acronym for “Software Bill of Materials,” and is technically an inventory of components that make up a software release. However, in the Tanzu Platform for Cloud Foundry system, it is used casually to refer to CycloneDX JSON-format documents that contain both inventory and vulnerabilities, and which affect analysis for those vulnerabilities. This is not an uncommon usage, but is mentioned here to prevent confusion, especially for those who understand SBOMs to only contain an inventory.
Triage
Similarly, triage is commonly used to describe the data that results from an analysis of a vulnerability’s impact, whereas it might be more proper to use the word triage to describe the act of assembling that impact analysis.
Feedback
