We're happy to announce that  latest monthly patch release for Data Platform, 5.5.49, is available as of the end of January 2022. This release is focused on fixing a few issues and usability improvements, which includes: fixes on issues with BMC API extractor as well as BigFix extractor the fix on the issue around adding new software component in private catalog the fix on the issue with passthrough process that was caused by inconsistency in data types performance improvement on reporting cubes in User Console Details on this release can be found in the  release notes  posted in the  documentation section  of Data Platform. ... View more

EDIT (2022-02-24): We're happy to deliver the good news that the same public-facing API is now available in our European (EU) cloud. Existing Flexera One customers on EU zone can take advantage of this capability. The title and content of this announcement have been updated to reflect this. *** EDIT (2022-02-02): This was announced prematurely because the public-facing API is only available in NAM Cloud as of today. Only the backend service is available in the EU Cloud. We are exploring the effort to make the API available in the EU Cloud and will update the communication accordingly. In the meantime, the title of this announcement has been updated to reflect this.  ***   We have been working in the past year to rebuild the foundation of Technopedia as well as reimagining how users access it through an API. We are excited to announce that the new Flexera One Technopedia API is now available in both the NAM and EU Cloud.   The new Technopedia is built upon a native cloud-based unified content environment. It fulfills the vision to have all content in one place,   to become the most trusted and comprehensive source of hardware, software, SaaS and cloud product information in the world.   Technopedia API provides a standard way to access various datasets in Technopedia. The API allows users to query information around manufacturers, software and hardware products, taxonomy, as well as enrichment content (aka "content packs" such as lifecycle dates) that they’re entitled to.   This is a GraphQL API; it follows the standard GraphQL over HTTP with POST requests. The API supports the following capabilities:   the ability to iteratively get all data in batches access to data that the user's organization is entitled to (e.g., specific datasets, enrichments) expose specific properties based on access (i.e., certain properties, such as legacy Technopedia ID's, may be hidden from users since they're not relevant to the user's organization) query capabilities to fetch relations across different datasets use the API to get data and bring it to other tools (such as BI tools) to do analysis or generate report or to built an integration with other products   The following enrichments are available as part of this GA release: Base: enabled by default, which includes base information around manufacturers, products, versions, models, editions, etc. Base enrichment also includes access to Technopedia Taxonomy. Lifecycle and Support: which includes both Software Lifecycle and Hardware Lifecycle Hardware Specifications: which includes information around power consumption, environment specifications, and physical dimension of hardware models (Note that  Open Source Licensing as well as Vulnerability and Threat Intelligence enrichments will be coming later this year). The following tools and technologies are used to build and deploy the API: Golang and Goa framework to develop the backend code MongoDB Atlas for storing the data GraphQL to query the data IAM for Front-end authentication AWS Kubernetes (EKS) to deploy the service Travis CI for Continuous Integration Jmeter for performance testing Front end testing tools like Postman, Altair Github as a code repository Please reach out to your Flexera account representative if you're interested in the new API or Flexera One in general. Reference Links: Technopedia API documentation: https://developer.flexera.com/docs/api/content/v2 Main Flexera API's documentation:  https://developer.flexera.com/ Technopedia Datasets and their properties: https://developer.flexera.com/docs/page/datasets-v2 Login and Access Management (generate the Refresh Token from here): NAM Cloud:  https://app.flexera.com/ EU Cloud: https://app.flexera.eu How to generate Access Token: https://developer.flexera.com/docs/page/authentication#access-token-generation API URL to access: NAM Cloud: https://beta.api.flexera.com/content/v2/orgs/<ORG_ID>/graphql EU Cloud: https://beta.api.flexera.com/content/v2/orgs/<ORG_ID>/graphql GraphQL API and Altair Plugin usage - https://developer.flexera.com/docs/page/graphql-api-usage ... View more

At the high level, there are two types of taxonomy changes that can happen in Technopedia: Changes in the taxonomy structure: New categories/subcategories are introduced Existing categories/subcategories are deprecated Existing categories/subcategories are modified Changes in the category and/or subcategory associated with the product The   first   type of change only happens rarely and, when it happens, it has to go through a due diligent process within content process to make sure the impact is assessed and an advanced notification in the form of Content Change Notification is posted on the Community Portal to ensure that all customers are aware of the upcoming changes. Customers are given a "grace period" to absorb the changes before they get deployed (typically 2 weeks or more. See   here   for more details on the Content Release Notification process). The   second   type of change happens as part of the BAU process, where every effort is being made to always reflect the most accurate information that the Content Team discovers in their research: as part of curation,   new products   are being added into Technopedia and they will be associated with any of the existing categories/subcategories. This happens continuously, every day within Technopedia. as part of curation, more information is also discovered on   existing products   in Technopedia which may trigger updates to make sure they have the most accurate information, including their categories/subcategories. The new information comes through validated feedback from customers, partners, direct from the vendors, as well as further market and industry research by the Content Team. This only happens occasionally, and as the products have reached certain maturity in their curation and accuracy, the categories/subcategories associated with them are becoming static without any further changes. There is currently no mechanism for "advance notification" on this second type of change--customers see the changes as they happen. Flexera is exploring mechanisms that would allow customers to manage the changes, including tracing what have changed, what the changes are, and make the decision to absorb the changes.   ... View more

Happy 2022, Data Platform customers! As many of you have seen in this previous blog post, we released the patch release 5.5.48 earlier (it was made available as of December 27, 2021) to address the vulnerabilities associated with log4j. This latest patch release contains the latest version of log4j (2.17.0) which is not exposed to currently disclosed vulnerabilities. This patch also contains a few notable new features and other bug fixes: Enhanced Platform Types Identification Customers can see "platform types" (e.g., "Desktop", "Server", "Mobile", etc.) of the applications, depending on which operating system(s) they're compatible with Enhanced ARL-Technopedia "crosswalk" capabilities Our FlexNet Manager customers can see the corresponding ARL titles with each Technopedia titles that they have, powered by the ARL-Technopedia crosswalk that our Content team has diligently maintained Support for Windows Server 2022 Data Platform (both Admin Console and User Console) has been tested to work with Windows Server 2022 Details on this release can be found in the  release notes  posted in the  documentation section  of Data Platform. ... View more

Recently, a vulnerability within Apache Log4j caught widespread public attention and has security, operational and development teams alike scrambling for analyzing the impact within their own eco system and to apply mitigations if necessary. The wide use of Log4j and the ease of the exploitation of the vulnerability makes this vulnerability very suitable for quick and effective use within exploitation campaigns. Shortly after publication of the vulnerability Proof of Concepts (PoCs) and reports of exploitation began to arrive.  Various teams across different Flexera solutions have been working overtime to ensure that our customers get immediate visibility on the impact of this and other vulnerabilities. This article is intended to help explain how   FlexNet Manager   can help you identify and remediate this vulnerability. For the status of impacted Flexera products,   please see this announcement.   Vulnerability Details To have a look at how the vulnerability works, we must look at the Log4j functionality of lookups. Essentially, this functionality allows values to be added to the Log4j configuration [1]. One part of the functionality allows JNDI lookups where multiple protocols are supported – one being LDAP. If an attacker can control parts of what gets logged, then arbitrary code might be downloaded from an attacker-controlled LDAP server (or other JNDI endpoints). The request for the download will be initiated from your own system. Such control is not uncommon, just think about servers logging User-Agent HTTP headers, usernames or chat messages from chat interfaces. A logged string may contain something like the below string  and an attack will potentially go ahead. This vulnerability affects Apache Log4j versions prior to 2.15.0 and can be referenced via the CVE identifier CVE-2021-44228. However, the fix for CVE-2021-44228 in version 2.15.0 is incomplete, which led to the acknowledgment of a further vulnerability that is exploitable in certain configuration scenarios [3]. Essentially, exploitability relies on the use of a non-default Pattern Layout with a Context Lookup and where an attacker has control over Thread Context Map (MDC) input data. Said variant received the additional CVE identifier CVE-2021-45046. This vulnerability is fixed in version 2.16.0 of Apache Log4j. Initially, the vulnerability was only expected to be exploitable to result in a Denial of Service (DoS) impact and was rated with a lower severity, but Apache revisited their analysis and admitted that arbitrary code execution is possible [4]. To note, Apache also released a version 2.12.2 based on Java 7 even though the Apache Log4j team doesn’t support the Java 7 platform anymore. Users of Log4j need to keep in mind, that such lack of support will result in unfixed security issues down the road and thus can hardly be recommended. Even the Log4j 1.x version branch, which is End of Life (EOL) though, could be exposed to a similar exploitation scenario in the 1.2 version. However, the vector is severely more limited as the JMSAppender needs to be used by an application and any potential attacker needs write access to the Log4j configuration [2]. Typically, such write access will be restricted to privileged persons when following security best practices and thus will likely result in a lower risk from this specific variation of the vulnerability. This variation affecting Apache Log4j version 1.2 can be referenced via the CVE identifier CVE-2021-4104 and also is referred to as “Log4Shell”. Keep in mind, that using any product version that is EOL constitutes a large risk on its own as security issues won’t get fixed. The recommendation, as always, is to upgrade any EOL versions to a supported and secure product version. References [1]   https://logging.apache.org/log4j/2.x/manual/lookups.html [2]   https://mail-archives.apache.org/mod_mbox/www-announce/202112.mbox/raw/%3C1a5a0193-71c4-0613-ca92-f5... [3] https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f [4]   https://logging.apache.org/log4j/2.x/security.html    How FlexNet Manager Can Help FlexNet Manager customers can expect to see Apache log4j applications which are potentially impacted by this attack. Given the fact that applications granularity in the Application Recognition Library (ARL) is captured only at the major.minor version, further investigation may be needed to identify the subset of installations in their inventory with the exact build and/or patch levels.    How Other Flexera Solutions Can Help To see how other Flexera solutions can help customers get immediate visibility on the impact of this and other vulnerabilities, please go  this main article on the Community Hub  where you can find the complete detail across all Flexera solutions. ... View more

Recently, a vulnerability within Apache Log4j caught widespread public attention and has security, operational and development teams alike scrambling for analyzing the impact within their own eco system and to apply mitigations if necessary. The wide use of Log4j and the ease of the exploitation of the vulnerability makes this vulnerability very suitable for quick and effective use within exploitation campaigns. Shortly after publication of the vulnerability Proof of Concepts (PoCs) and reports of exploitation began to arrive.  Various teams across different Flexera solutions have been working overtime to ensure that our customers get immediate visibility on the impact of this and other vulnerabilities. This article is intended to help explain how   Flexera One IT Visibility and IT Asset Management   can help you identify and remediate this vulnerability. For the status of impacted Flexera products, please see this announcement.   Vulnerability Details The Beginning (Remote Code Execution, CVE-2021-44228) To have a look at how the vulnerability works, we must look at the Log4j functionality of lookups. Essentially, this functionality allows values to be added to the Log4j configuration [1]. One part of the functionality allows JNDI lookups where multiple protocols are supported – one being LDAP. If an attacker can control parts of what gets logged, then arbitrary code might be downloaded from an attacker-controlled LDAP server (or other JNDI endpoints). The request for the download will be initiated from your own system. Such control is not uncommon, just think about servers logging User-Agent HTTP headers, usernames or chat messages from chat interfaces. A logged string may contain something like the below string  and an attack will potentially go ahead. This vulnerability affects Apache Log4j versions prior to 2.15.0 and can be referenced via the CVE identifier CVE-2021-44228. Thread Context Map - Incomplete Fix (Remote Code Execution, CVE-2021-45046) However, the fix for CVE-2021-44228 in version 2.15.0 is incomplete, which led to the acknowledgment of a further vulnerability that is exploitable in certain configuration scenarios [3]. Essentially, exploitability relies on the use of a non-default Pattern Layout with a Context Lookup and where an attacker has control over Thread Context Map (MDC) input data. Said variant received the additional CVE identifier CVE-2021-45046. This vulnerability is fixed in version 2.16.0 of Apache Log4j. Initially, the vulnerability was only expected to be exploitable to result in a Denial of Service (DoS) impact and was rated with a lower severity, but Apache revisited their analysis and admitted that arbitrary code execution is possible [4]. Thread Context Map – The Sequel (Denial of Service, CVE-2021-45105) The story could have ended there, but, unfortunately, a further vulnerability has been acknowledged shortly after [5]. The vulnerability, associated with the CVE identifier CVE-2021-45105, has a lower impact, namely, its remote exploitation through Thread Context Map data results in a Denial of Service (DoS) condition solely. The issue results from an uncontrolled recursion when handling self-referential lookups and causes a stack overflow and process termination in the end. The Apache Log4j team has released the version 2.17.0 to fix this CVE. To note, Apache also released versions in the 2.3.x and 2.12.x branches even though the Apache Log4j team doesn’t support the Java 6 and Java 7 platforms anymore. Users of Log4j need to keep in mind, that such lack of support will result in unfixed security issues down the road and thus can hardly be recommended. End of Life Branch – The Prequel? (Limited Vector Code Execution, CVE-2021-4104) Even the Log4j 1.x version branch, which is End of Life (EOL) though, could be exposed to a similar exploitation scenario like the original vulnerability in the 1.2 version. However, the vector is severely more limited as the JMSAppender needs to be used by an application and any potential attacker needs write access to the Log4j configuration [2]. Typically, such write access will be restricted to privileged persons when following security best practices and thus will likely result in a lower risk from this specific variation of the vulnerability. This variation affecting Apache Log4j version 1.2 can be referenced via the CVE identifier CVE-2021-4104 and also is referred to as “Log4Shell”. Keep in mind, that using any product version that is EOL constitutes a large risk on its own as security issues won’t get fixed. The recommendation, as always, is to upgrade any EOL versions to a supported and secure product version. References [1]   https://logging.apache.org/log4j/2.x/manual/lookups.html [2]   https://mail-archives.apache.org/mod_mbox/www-announce/202112.mbox/raw/%3C1a5a0193-71c4-0613-ca92-f5... [3] https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f [4]   https://logging.apache.org/log4j/2.x/security.html  [5]   https://lists.apache.org/thread/6gxlmk0zo9qktz1dksmnq6j0fttfqgno   How Flexera One IT Visibility Can Help IT Visibility customers can expect to see any detected installations of impacted Apache log4j products and/or releases in their inventory, providing the evidence already exists in our recognition library (note that any net new evidence may still need to go through the gap-fill process). As IT Visibility is powered by Technopedia, the detection of the impacted products in your inventory will provide a directional assessment as the version granularity may not corresponding directly to the vulnerabilities. The capability to show the vulnerability information, however, is not currently available in IT Visibility. This is something that we’re actively working on to make available in the first half of 2022.   How Flexera One IT Asset Management Can Help Similar to IT Visibility, IT Asset Management customers can also expect to see Apache log4j applications which are potentially impacted by this attack. Given the fact that applications granularity in the Application Recognition Library (ARL) is captured only at the major.minor version, further investigation may be needed to identify the subset of installations in their inventory with the exact build and/or patch levels.    How Other Flexera Solutions Can Help To see how other Flexera solutions can help customers get immediate visibility on the impact of this and other vulnerabilities, please go  this main article on the Community Hub  where you can find the complete detail across all Flexera solutions. ... View more

Recently, a vulnerability within Apache Log4j caught widespread public attention and has security, operational and development teams alike scrambling for analyzing the impact within their own ecosystem and to apply mitigations if necessary. The wide use of Log4j and the ease of the exploitation of the vulnerability makes this vulnerability very suitable for quick and effective use within exploitation campaigns. Shortly after publication of the vulnerability Proof of Concepts (PoCs) and reports of exploitation began to arrive. For more details on this vulnerability and how it works, please see “Vulnerability Details” at the end of this article. This article is intended to help explain how Flexera security products can help you identify and remediate this vulnerability. For the status of impacted Flexera products, please see this announcement. Various teams across different Flexera solutions have been working overtime to ensure that our customers get immediate visibility on the impact of this and other vulnerabilities.   Software Vulnerability Research (SVR) Alerts will be generated based on configured watch lists and configured notification settings. SVR customers can expect to see: Up-to-date Secunia Advisories (SA105630, SA105605, SA105601) and further third-party product-related Secunia Advisories which contain detailed information on the vulnerability and its variants, including the solutions/patches and available CPEs CVEs associated with the vulnerability and its variants as published by a trusted source (for example, the vendor Apache or MITRE) Threat intelligence information associated with the vulnerability and its variants (if entitled to our Threat Intel module)   Software Vulnerability Manager (SVM) Vulnerable products can be detected via file signatures which provide a definitive, actionable status. Where available, security updates may be published to remediate vulnerable instances detected in your environment. SVM customers can expect to see: Impacted software product versions being detected in their inventory NEW   SVM's Single Host Agent (v7.6.0.19) can now detect the log4j-core*.jar files installed on a host machine. See details   here. We are and will continue, actively working to obtain more vulnerable product versions in order to create file signatures. If you are aware of a software version that is impacted but not yet detected, please submit it via the normal software suggestion process to help us to get the details necessary to create a file signature. CVE associated with the vulnerability and its variants as published by a trusted source (for example, the vendor Apache or MITRE) Threat intelligence information associated with the vulnerability and its variants (if entitled to our Threat Intel module) Patches you can publish to remediate this vulnerability and its variants for covered products as they are released by their respective vendors. This vulnerability will be the cause of many software vulnerability disclosures, but each application including and exposing it will typically issue its own disclosure. Our Secunia Research team will continually monitor for such and will create a file signature for SVM to detect and assess specific versions as vulnerable as appropriate.    AdminStudio AdminStudio recently added a new Windows Risk Assessment test rule to detect the presence of log4j files in your deployment packages. See details here. AdminStudio customers can expect to see: NEW A warning when log4j jar file is found in a package In cases where the data to assess the presence of Log4j is not possible, a message will be shown.    Data Platform (with Technopedia) Affected products may be detected in your inventory to provide a directional assessment. This can help you determine where to look closer, but a definitive vulnerability status may not be possible due to a lack of version granularity depending upon the application in question. Data Platform customers can expect to see: All impacted Apache log4j products and/or releases are captured in Technopedia Any existing discovered data (a.k.a. evidence) that maps to the impacted products and/or releases are recognized. Note that any new evidence that customers bring in their inventory may still need to go through the gap-fill process. If the entitlement to InfoSec Content Pack is active: impacted products will be identified with any CPE’s associated with the impacted products and/or releases are linked up-to-date Secunia Advisory information linked to the available CPE’s is provided  CVE references associated with the vulnerability and its variants. The publication is dependent upon review/approval by the National Vulnerability Database (NVD). threat intelligence associated with the advisories (as provided by Flexera’s Secunia Research)   Flexera One IT Visibility IT Visibility customers can expect to see any detected installations of impacted Apache log4j products and/or releases in their inventory, providing the evidence already exists in our recognition library (note that any net new evidence may still need to go through the gap-fill process). Similar to Data Platform (as both solutions are powered by Technopedia), the detection of the impacted products in your inventory will provide a directional assessment as the version granularity may not correspond directly to the vulnerability and its variants. The capability to show the vulnerability information, however, is not currently available in IT Visibility. This is something that we’re actively working on to make available in the first half of 2022.   FlexNet Manager Suite (FNMS) and Flexera One IT Asset Management Similar to IT Visibility, FNMS and ITAM customers can also expect to see Apache log4j applications which are potentially impacted by this attack. Given the fact that applications granularity in the ARL library is captured only at the major.minor version, further investigation may be needed to identify the subset of installations in their inventory with the exact build and/or patch levels.    -   For details on the Log4j vulnerability please see Apache Log4j "Log4Shell" and Beyond   ... View more

Recently, a vulnerability within Apache Log4j caught widespread public attention and has security, operational and development teams alike scrambling for analyzing the impact within their own eco system and to apply mitigations if necessary. The wide use of Log4j and the ease of the exploitation of the vulnerability makes this vulnerability very suitable for quick and effective use within exploitation campaigns. Shortly after publication of the vulnerability Proof of Concepts (PoCs) and reports of exploitation began to arrive.  Various teams across different Flexera solutions have been working overtime to ensure that our customers get immediate visibility on the impact of this and other vulnerabilities. This article is intended to help explain how   Flexera Data Platform (with Technopedia)   can help you identify and remediate this vulnerability. For the status of impacted Flexera products, please see this announcement.   How Flexera Data Platform (with Technopedia) Can Help Affected products may be detected in your inventory to provide a directional assessment. This can help you determine where to look closer, but a definitive vulnerability status may not be possible due to a lack of version granularity depending upon the application in question. Data Platform customers can expect to see: All impacted Apache log4j products and/or releases are captured in Technopedia Any existing discovered data (a.k.a. evidence) that maps to the impacted products and/or release are recognized. Note that any new evidence that customers bring in their inventory may still need to go through the gap-fill process. If the entitlement to InfoSec Content Pack is active: impacted products will be identified with any CPE’s associated with the impacted products and/or releases are linked up-to-date Secunia Advisory information linked to the available CPE’s is provided  CVE references associated with the vulnerabilities. The publication is dependent upon review/approval by the National Vulnerability Database (NVD). threat intelligence associated with the advisory (as provided by Flexera’s Secunia Research) If the entitlement to Lifecycle and Support Content Pack is active: lifecycle dates (EOL and/or Obsolete dates) for Apache log4j releases which can help you determine supported versions and the upgrade path(s)   Vulnerability Details The Beginning (Remote Code Execution, CVE-2021-44228) To have a look at how the vulnerability works, we must look at the Log4j functionality of lookups. Essentially, this functionality allows values to be added to the Log4j configuration [1]. One part of the functionality allows JNDI lookups where multiple protocols are supported – one being LDAP. If an attacker can control parts of what gets logged, then arbitrary code might be downloaded from an attacker-controlled LDAP server (or other JNDI endpoints). The request for the download will be initiated from your own system. Such control is not uncommon, just think about servers logging User-Agent HTTP headers, usernames or chat messages from chat interfaces. A logged string may contain something like the below string  and an attack will potentially go ahead. This vulnerability affects Apache Log4j versions prior to 2.15.0 and can be referenced via the CVE identifier CVE-2021-44228. Thread Context Map - Incomplete Fix (Remote Code Execution, CVE-2021-45046) However, the fix for CVE-2021-44228 in version 2.15.0 is incomplete, which led to the acknowledgment of a further vulnerability that is exploitable in certain configuration scenarios [3]. Essentially, exploitability relies on the use of a non-default Pattern Layout with a Context Lookup and where an attacker has control over Thread Context Map (MDC) input data. Said variant received the additional CVE identifier CVE-2021-45046. This vulnerability is fixed in version 2.16.0 of Apache Log4j. Initially, the vulnerability was only expected to be exploitable to result in a Denial of Service (DoS) impact and was rated with a lower severity, but Apache revisited their analysis and admitted that arbitrary code execution is possible [4]. Thread Context Map – The Sequel (Denial of Service, CVE-2021-45105) The story could have ended there, but, unfortunately, a further vulnerability has been acknowledged shortly after [5]. The vulnerability, associated with the CVE identifier CVE-2021-45105, has a lower impact, namely, its remote exploitation through Thread Context Map data results in a Denial of Service (DoS) condition solely. The issue results from an uncontrolled recursion when handling self-referential lookups and causes a stack overflow and process termination in the end. The Apache Log4j team has released the version 2.17.0 to fix this CVE. To note, Apache also released versions in the 2.3.x and 2.12.x branches even though the Apache Log4j team doesn’t support the Java 6 and Java 7 platforms anymore. Users of Log4j need to keep in mind, that such lack of support will result in unfixed security issues down the road and thus can hardly be recommended. End of Life Branch – The Prequel? (Limited Vector Code Execution, CVE-2021-4104) Even the Log4j 1.x version branch, which is End of Life (EOL) though, could be exposed to a similar exploitation scenario like the original vulnerability in the 1.2 version. However, the vector is severely more limited as the JMSAppender needs to be used by an application and any potential attacker needs write access to the Log4j configuration [2]. Typically, such write access will be restricted to privileged persons when following security best practices and thus will likely result in a lower risk from this specific variation of the vulnerability. This variation affecting Apache Log4j version 1.2 can be referenced via the CVE identifier CVE-2021-4104 and also is referred to as “Log4Shell”. Keep in mind, that using any product version that is EOL constitutes a large risk on its own as security issues won’t get fixed. The recommendation, as always, is to upgrade any EOL versions to a supported and secure product version. References [1]   https://logging.apache.org/log4j/2.x/manual/lookups.html [2]   https://mail-archives.apache.org/mod_mbox/www-announce/202112.mbox/raw/%3C1a5a0193-71c4-0613-ca92-f5... [3] https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f [4]   https://logging.apache.org/log4j/2.x/security.html  [5]   https://lists.apache.org/thread/6gxlmk0zo9qktz1dksmnq6j0fttfqgno   How Other Flexera Solutions Can Help To see how other Flexera solutions can help customers get immediate visibility on the impact of this and other vulnerabilities, please go this main article on the Community Hub where you can find the complete detail across all Flexera solutions. ... View more

The latest monthly patch release for Data Platform, 5.5.47, is available as of the end of November 2021.   With this release, we shipped several enhancements on our extractors: HPUD extractor: extraction of network devices FNMS extractor:  improved performance of the OS query   We're also keeping up-to-date with issuing fixes to address various potential vulnerabilities, including: Java vulnerability in User Console potential vulnerabilities detected by a security scanning tool on User Console (e.g. web server misconfiguration, privacy violation, insecure default configuration, http verb tampering, cross-site request forgery, and cookie security issues) potential vulnerabilities detected by a security scanning tool on Admin Console (e.g. error handling exception, cookie security issues)   Details on this release can be found in the  release notes  posted in the  documentation section  of Data Platform. ... View more

We’re excited to announce the patch release 5.5.46 for Data Platform (shipped out on the last day of October 2021). Our team has been working on addressing several usability issues as well as delivering performance improvements which includes: Exposing API extractor for HCL BigFix on Admin Console Adding the ability to load software install path from ServiceNow Performance improvement for catalog sync on Oracle Removing deleted Private Catalog data from Analyze reports and a few other bug fixes. Details on 5.5.46 (October 2021) release can be found in the  release notes  posted in the  documentation section  of Data Platform. ... View more