This article will discuss how to report and address any vulnerabilities detected in an API Management product.
Broadcom considers the security posture of its products to be paramount to developing quality software. The API Management suite — including but not limited to the API Gateway, the API Developer Portal, and the Mobile API Gateway — are tested regularly by the Broadcom Engineering team to ensure compliance with contemporary security checklists and verify that no dependencies used by these products are subject to exploitation or other vulnerabilities.
Common Vulnerabilities & Exposures (CVEs) are incredibly important to stay on top of to avoid any negative consequences to the environment. Broadcom encourages all customers to always install the latest monthly platform patch in order to address all CVEs related to third-party dependencies. It is recommended that this become part of a monthly maintenance routine.
The definition of a CVE according to mitre.org is as follows: "A CVE is a list of information on security vulnerabilities and exposures that aims to provide common names for publicly known cyber security issues. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration."
This article applies to all CA API Management products
If an automated reporting tool or manual audit of a system implies that a security vulnerability exists on the API Gateway, then the following procedure should be executed prior to contacting Broadcom Support:
A note on generic security configuration recommendations by automated tools:
It should be understood that any configuration recommendations (non-CVEs) suggested by automated scanning tools are not generally recommended or encouraged by Broadcom. While in some cases the recommendation may be desirable or may work without issue, it is important to know that many of the configurations in the appliances come "out of the box" the way they are for a reason. Any changes to the configuration of such critical components such as MySQL or the appliance file system may negatively impact the environment. In addition, QA testing is done on the "out of the box" security configurations rather than any possible customizations, so there is an inherent risk to modifying any of these components. Any changes done to meet IT security policies are considered to be done "at your own risk".
When opening a new support case to report a vulnerability, the following items should be provided up front: