Loading...
Last Updated: 2026-05-28 Flexera's Production Security Controls are distinct from Corporate Security Controls. Production Security Controls focus on safeguarding Flexera's customer-facing systems, data, and operations not internal environments and data.
Flexera maintains a separation of concerns between Corporate and Production security operations to minimize the impact of an incident in either domain.
Flexera has policies and processes to ensure that accessible endpoint devices are appropriately secured, and that users are aware of the risks associated with using such devices. This includes mechanisms to ensure that only secure endpoint devices are used for Flexera business and that all relevant Organizational controls are properly applied to endpoint devices.
These devices fall under Corporate IT's management and are not covered by production specific controls. Flexera maintains a strict separation between corporate and production responsibilities, and the controls described in this section are focused on production systems and environments.
In particular, tools that allow access to production systems are restricted to secure endpoint devices where feasible.
Flexera has policies and processes to ensure that privileged access rights are assigned and managed appropriately, and that there is a process to manage and mitigate the risks associated with necessary access rights and privileged access rights.
Flexera uses a DevOps methodology for production development, and this means that developers, by necessity, have privileged access to a limited set of production systems. However, controls exist to ensure that the number of systems accessible to a particular development team are minimized and access is appropriately managed and monitored, and that risks associated with privileged access are mitigated.
Access rights are reviewed periodically using hybrid automated and manual processes to keep the task of reviewing access rights for all engineers manageable and effective. Access rights are also reviewed when an employee changes roles or leaves the company.
Flexera leverages a primary SSO system as the ultimate root of most access rights and this allows most rights to be removed immediately on employee offboarding, or in case of a credential compromise.
Flexera has policies and processes to ensure that access to information is restricted in accordance with defined access control policy, and that users are only provided with access to the information and resources necessary for their legitimate business purposes.
Flexera performs access reviews on a regular basis to ensure that access rights are appropriate and aligned with policy intent.
Flexera has policies and processes to ensure that access to source code is restricted in accordance with the access control policy, and that users are provided with access to source code in a manner aligned with the security of Flexera operations and assets.
Flexera uses GitHub Enterprise Managed Users for source code management. Access to repositories is controlled through GitHub's access control mechanisms. Repository deletion without approval is prohibited via supported GitHub technical measures.
Flexera has policies and processes to ensure that secure authentication methods are used, and that authentication credentials are properly protected.
Flexera uses SSO for authentication where possible, which enforces passwordless access mechanisms where available, and multi-factor authentication where stronger mechanisms are unavailable.
Access to cloud systems is gated through the primary SSO system, which allows gated permission to access the cloud native IAM capabilities.
Flexera has policies and processes to ensure that the capacities of information processing facilities and human resources are monitored, tuned and future capacity plans adjusted to ensure that the required capacity is available.
See the section on Logging for more on how Flexera ingests capacity management information for monitoring and management by devops teams.
See the section on Redundancy of processing facilities for more on how Flexera designs for and delivers resilience and availability.
Flexera policies address both capacity management of compute resources but capacity management of human resources as well, including the SOC team and other teams responsible for monitoring and responding to security events.
Teams are required to update a capacity plan on a regular basis, and to adjust the plan as needed based on monitoring of capacity, performance, and expected demands.
Flexera manages system capacity and availability to help ensure reliable platform performance as customer needs evolve. Capacity requirements are identified for new and existing services and reviewed as part of system design, change management, and release activities. Future planning considers product growth, customer demand, and usage trends to reduce the risk of service degradation. Capacity management covers both infrastructure and personnel requirements.
Flexera continuously monitors and tunes production systems to maintain performance and scalability. Cloud‑based services leverage auto‑scaling where appropriate, with limits and dependencies incorporated into capacity planning. Utilization of critical resources such as compute, storage, and network capacity is actively monitored, with added focus on high‑cost or long‑lead‑time components. Where possible, Flexera utilizes our proprietary commercial cluster scaling technology to optimize compute performance and cost.
Systems are designed for resilience using architect‑approved redundancy and replication strategies aligned with service needs, typically deploying across multiple availability zones. New systems, upgrades, and major changes undergo formal planning and acceptance before production release, including validation of:
Capacity management of cloud systems is largely automated with auto-scaling where possible, but policy requries teams to be mindful of the algorithms underlying their auto-scaling behaviors when making design changes.
Operational continuity is supported through qualified system expertise and consistently applied security and operational controls.
Flexera has policies and processes that ensure malware protections are implemented and monitored, and that users are aware of the risks associated with malware, and malware distribution mechanisms.
Flexera policy addresses the protection of information and other assets from malicious agents. Countermeasures include but are not limited to EDR/XDR software, drift detection, network boundaries, network monitoring, intelligent activity monitoring, and boundary controls.
Flexera's automated tooling includes vulnerability detection mechanisms to prevent malware attacks from exploiting known vulnerabilities that are handled as part of Flexera's vulnerability management program.
Flexera also has technical controls to prevent the deployment of vulnerable container images, and to monitor for vulnerabilities in deployed container images.
Image tracking extends to drift detection of executing container images along with other mechanisms to protect container hosts from malware attacks including sandboxed execution of container images, and monitoring of container activity for anomalous behavior.
Flexera services are protected by centrally managed WAF where appropriate, to reduce the possibility of successful remote attacks that could lead to malware infection.
Flexera also subscribes to threat intelligence services, both generic and with scanning for Flexera-specific indicators, to help identify and mitigate emerging threats.
Flexera has policies and processes to ensure that technical vulnerabilities are detected and remediated in a timely manner. The organization's exposure to vulnerabilities is evaluated, and appropriate measures are taken to address the associated risks.
Detection procedures include multiple layers of automated software security testing, including dependency scanning, static application security testing (SAST), dynamic application security testing (DAST), third party penetration testing, and manual code review. Vulnerability management also includes continuous monitoring of production systems.
Remediation policy establishes a remediation lifecycle with defined timelines based on severity, a process for assessing, approving, and documenting exceptions to remediation timelines, and formalized approval of risk acceptances.
Flexera has clearly defined accountable persons for vulnerability management, and these individuals are responsible for ensuring that vulnerabilities are identified, assessed, and remediated in accordance with policy.
Flexera has policies and processes to ensure that configurations, including security configurations, of hardware, software, services and networks are established, documented, implemented, monitored, and reviewed. See also Change Management and Installation of software on operational systems.
At the production level, Flexera makes infrastructure and configuration changes primarily through IaC gated through CI/CD systems. Changes to production systems should have testing in non-production environments, post-implementation validation, and deployment via a CI/CD system with an approval mechanism.
The use of IaC ensures that infrastructure and configuration changes are reviewed, tracked, auditable, and reversible. Use of IaC also allows securitys scanning of infrastructure changes prior to deployment, and automated testing of changes in non-production environments.
Flexera has policies and processes to ensure that information is deleted securely, and that system operators understand their data deletion responsibilities and the risks associated with data deletion.
This includes deletion activities mandated by GRPC and similar legal and regulatory requirements, as well as deletion of data that is no longer needed for business purposes.
Flexera retains customer data for a defined period after service provision has ended, and securely deletes data after the retention period has expired. Flexera also provides customers with the ability to delete their data upon request, in accordance with applicable laws and regulations.
Flexera policies and processes exist to limit the exposure of sensitive data including personal information, and to meet with legal, statutory, regulatory and contractual requirements. Solutions include, but are not limited to, data masking, pseudonymization, anonymization and encryption.
Flexera operates a DevOps operational model, and teams have access to the production systems that they develop. They do not have access to systems that they do not legitimately require access to. Access to production systems is monitored, and controls are in place to ensure that access is appropriate and that risks associated with access are mitigated.
Situations where pseudonymization or anonymization are appropriate are strictly limited and reviewed by SMEs to ensure that the risk level is appropriate for the particular use case.
Flexera has policies and processes to detect and prevent the unintended disclosure or extraction, of information by individuals or systems.
While Corporate implements controls to prevent accidental disclosure by employees, the production controls focus on preventing data leakage and malicious exfiltration through technical controls such as network monitoring, boundary controls, and intelligent activity monitoring.
A key cause of unwanted data leakage is breach of systems due to malware or theft of credentials, and Flexera has a broad range of controls to prevent and detect such breaches and to prevent and detect exfiltration of data in the event of a breach.
While use of production data in test environments is often considered a risk, Flexera does not use production data in testing without written customer consent, and if production data is used in testing with permission, it is appropriately protected.
Flexera has policies and processes that establish the capability to recover from data-loss scenarios. Flexera also has a business continuity and disaster recovery (BC/DR) program that includes regular testing of recovery procedures, and regular review and update of the BC/DR plan.
Production systems run in the cloud, and data is backed up according to defined policies. Backups are encrypted, and protected against unauthorized access.
Backup and restoration processes are regularly tested to ensure that they are effective and that data can be recovered in a timely manner.
Backups are required to be encrypted with compliant cryptography, and access to backups is restricted to authorized personnel.
Flexera has established baseline recovery time objectives (RTOs) and recovery point objectives (RPOs) for all production systems; and some systems may operate to even stricter standards.
The baseline recovery objectives for cloud systems are as follows:
However, some systems may set stricter standards based on the criticality of the system. Also, in certain cases, backup support may not be necessary for a servce, or longer recovery times may be acceptable due to the nature of the service and the data it handles.
Flexera has policies and processes to manage reliable provision of information processing facilities. Redundancy is a key element of service resilience, and production systems are designed for seamless automatic failover based on multiple availability zones, with appropriate monitoring and alerting to ensure that failover occurs as expected. In the case of sensitive systems, support may extend to multiple regions.
Flexera makes extensive use of its own "Spot" product for cluster scaling, which provides a high degree of redundancy and resilience for compute resources.
Flexera provides service level agreements (SLAs) for production services, and these SLAs are supported by the redundancy and resilience controls described above.
Flexera provides real-time information on service status and performance, and has defined processes for communicating with customers in the event of service disruptions.
Flexera has policies and processes to ensure that events, particularly those such as exceptions and faults, are logged, and that logs are protected and reviewed on a regular basis. See also Monitoring.
Logging is implemented uniformly across production systems, and logs are protected against unauthorized access and tampering. Logs are retained for a defined period to support incident response and forensic investigations.
Logging is implemented using a twofold process. One stream of logs is ingested into the SIEM, with a retention period exceeding 365 days. This information includes a broad range of events, focused on, but not limited to, security events.
The second stream of events is ingested into an observability system and retained for a shorter period. This information is focused on operational events and is used for capacity management, performance monitoring, and operational troubleshooting.
The retention period for the second log mechanism ranges from 90 days (typical) to as low as seven days for extreme high volume data. Data in this log system is not considered of high value for security purposes, and security logs are retained in the SIEM for at least 365 days.
Flexera has policies and processes to ensure that networks, systems, and applications
are monitored in order to detect actual and potential security incidents. This includes, but is not
limited to ingestion of security events into a SIEM, monitoring of network traffic, and monitoring
of devops activities. See also Logging.
Security monitoring is also delivered via EDR/XDR tools and cloud posture management and workload protection tools, which enable tracking of changes to infrastrucuture and detection of anomalous activity.
Flexera uses a range of tools from "best of breed providers" along with AWS native capabilities.
Monitoring involves both automated systems and human analysts. The SOC team is responsible for monitoring security events, analyzing alerts, and responding to incidents. The SOC team uses a combination of automated tools and manual analysis to identify and investigate potential security incidents.
Flexera attempts to tune automated alerts to be relevant and useful, but also recognizes that some level of false positives is inevitable. The SOC team is trained to investigate alerts in a systematic manner to determine their validity and potential impact. The SOC team also continuous reviews and improves alerting rules to reduce false positives and improve detection capabilities.
Flexera has policies and processes to ensure that clocks of relevant processing systems are synchronized to a reference time source within a reasonable tolerance of accuracy.
In the case of AWS and Azure this is a built-in feature of the cloud platform. Where necessary, Flexera uses automated services to synchronize clocks to a reference time source.
Flexera has policies and processes to ensure that the use of privileged utility programs is restricted and controlled, and that users are aware of the elevated risks associated when using such programs.
Flexera maintains a strong boundary beteween corporate and production environments such that privileges from one area cannot reach into another.
The definition of "privileged utility programs" is broad, and Flexera applies controls to elevated rights generally.
When utilities provide elevated access to production systems, any kind of write access is tightly controlled and narrowly provisioned to teams such as the SOC team, and access is appropriately monitored and logged.
When access can be appropriately controlled, devops teams may have access to privileged utilities but with tightly controlled rights and permissions. They are only allowed to view information about systems that they are responsible for.
The administration of rights for privileged utilities is subject to rigorous controls and restriction to a small number of individuals with a legitimate need for such access. Access is monitored and logged, and the risks associated with such access are mitigated.
Flexera has policies and processes to ensure that installation of software on operational systems is appropriately restricted and controlled, and that users are educated regarding the risks associated with installing and updating software on operational systems. See also Configuration Management and Change Management.
Software deployment typically occurs through a CI/CD pipeline using IaC. Deployments can be tested in sandbox and staging environments before being released to production. This allows for rigorous testing and validation of software changes before they impact production systems.
Automated security tooling is enabled to scan IaC for vulnerabilities and configuration errors prior to deployment.
Multiple layers of automated security tools monitor deployed infrastructure and infrastructure changes. Some changes are prohibited, or restricted by policy enforcement using technical controls. For example, opening a public S3 bucket requires an extra step of approval.
The vulnerability status of deployed software is continuously monitored by automated tooling. These vulnerabilities fall under Flexera's vulnerability management program, and are remediated according to defined timelines based on severity. Exceptions and risk acceptances are granted according to defined processes in accordance with policy.
Flexera has policies and processes to ensure that networks and network devices are sufficiently secured, managed and controlled to protect information in systems and applications.
In the context of production systems, network devices are almost always virtualized, and network security controls are implemented through a combination of cloud provider capabilities and third-party tools.
Hardware network devices for production are managed by a small spcialized network team.
For production systems, Flexera employs approaches such as centralized ingress and egress points, network segmentation, and microsegmentation to control and monitor network traffic. Network access controls are implemented to restrict access to production systems based on the principle of least privilege. Network traffic is monitored for anomalous activity, and alerts are generated for potential security incidents.
Internal traffic is encrypted where appropriate, and all traffic across public networks is encrypted using policy compliant technology. Policy requires all internal traffic to be encrypted where feasible, and in addition it is also strongly authenticated where possible.
Flexera has policies and processes to ensure that security mechanisms, service levels and management requirements of all network services are identified, implmented and monitored; also appropriate network requirements should be included in agreements with providers of network services, whether these services are provided in-house or outsourced.
Network service agreements are periodically reviewed to ensure compliance.
Flexera has policies and processes to ensure that information services, users, developers, and systems are highly partitioned at the network level as appropriate to meet risk minimization and operational requirements.
Production systems are segmented by purpose, and access between segments is controlled and monitored by a variety of layered technical controls including network infrastructure, auth mechanisms, and cryptography.
Production systems are also segregated from development staging systems, and from development sandbox systems at the infrastructure level.
Flexera maintains a strong boundary between corporate and production environments. Production data is not permitted to flow into corporate environments. Policy, process, and controls exist to ensure that data cannot flow through corporate environments into staging or sandbox environments.
Network access to production systems can be achieved from a corporate context via a controlled VPN system; this mechanism is monitored and access is restricted to secure endpoint devices. Access is also limited to accounts that the developer has a legitimate need to access.
It should be noted that "jump boxes" and bastion hosts are not commonly used to secure or isolate production systems, as the use of such devices can introduce additional attack surfaces, operational complexity, potential for configuration errors or patching concerns, and operational costs. Instead, Flexera relies on a combination of network segmentation, access controls, dedicated VPN, and monitoring to secure production systems. For developers using Flexera's secure production VPN access mechanism, a jump box or bastion host would add no additional security value but would create additional risks and operational cost.
Flexera uses jump boxes and bastion hosts in some cases to enable access for third-party penetration testing. Such deployments are temporary and bounded to the duration of a particular penetration test engagement. Access is tightly controlled and monitored, and the jump box or bastion host is decommissioned at the end of the engagement. In most cases, the environments accessed in such engagements are in a staging environment and are not hosted in production, but in rare cases may be production environments that are not customer-facing.
Some minimal controlled access is provided between staging and sandbox environments, but data cannot flow outwards from production to any other environment. Such rare cross-connects are restricted to particular accounts where the complexity of test environments means that sandbox development needs access to complex infrastructure in staging to operate effectively.
For cases where data has a "dual use" for both production and staging purposes, the data must reside entirely within production systems and cannot be copied or transferred out to staging or sandbox environments. Monitoring systems that compare production and staging performance must reside in production systems and be secured to production standards. Policy, process, and controls exist to ensure that data cannot flow out to staging or sandbox environments in such cases.
Flexera has policies and processes to ensure that access to websites is restricted as appropriate to meet risk minimization and operational requirements, and that users are aware of the risks associated with accessing websites.
This is primarily a corporate concern, and production envronments are not generally permitted to access the public internet. Access to the public internet from production environments is restricted to specific accounts and is monitored.
Flexera has policies and processes to ensure that cryptographic controls are used in a manner that ensures the confidentiality, integrity and availability of production data, and that developers are aware of the risks associated with cryptography and how to avoid them. Rules for the effective use of cryptography, including cryptographic key management, are defined and implemented.
A cryptographic strategy is defined and implemented. The following aspects are considered:
Typically, encryption in cloud environments uses AES256 GCM or better, with key management via the cloud provider's key management service (KMS) or virtual HSM where appropriate.
Key management practices include strict access controls, regular key rotation, and secure storage of keys. Key management processes are regularly reviewed and updated to ensure they remain effective against evolving threats and to comply with industry best practices and regulatory requirements.
Build processes and CI/CD pipelines are designed to prevent the inclusion of sensitive information such as secrets and keys in code repositories. Secrets management solutions are used to securely store and manage sensitive information.
Flexera continuallyl scans code repositories for included secrets and treats any findings as vulnerabilities that are remediated according to the vulnerability management program.
Flexera has policies and processes to ensure that rules for security are integrated into the software development lifecycle, and that developers are aware of the risks associated with their work.
Key practices for incorporating security in the development process include a secure SDLC, i.e. integrating security requirements in all phases of the development lifecycle: product approval, architectural approval, coding, testing. pre-release and release.
A core element of the SDLC is security planning, and every development project must have a security impact analysis. The impact analysis must be reviewed and approved by the security team before development can begin. The impact analysis must identify security requirements, potential risks, and mitigation strategies. Review of the deliverables, which may include updates to security or architectural documentation is performed prior to acceptance of the impact analysis.
Requirements are defined and implemented for the following central elements:
Other concerns controlled by the SDLC include, but are not limited to:
The requirements for incorporating security in the system acquisition process include defining security requirements, security due diligence during acquisition, managing third-party security risks, secure configuration and deployment.
The SDLC mandates automated security scanning of code, dependencies, and deployed test infrastructure prior to production release. The SDLC also requires manual code review of all code changes, with a focus on security‑sensitive areas such as authentication, authorization, cryptography, and input validation.
Policies and processes exist to ensure that security requirements are identified, specified and approved when developing or acquiring applications, and that developers are aware of the risks associated with application security.
A security impact analysis is required for all development projects, and this analysis must be reviewed and approved by the security team before development can begin. The impact analysis must identify security requirements, potential risks, impacted environments, the sensitivity of data in scope and any changes that might occur for that, along with mitigation strategies.
A threat model is required for all development projects, and this model must be reviewed and approved by the security team before development may begin. The threat model must identify potential threats, vulnerabilities, and attack vectors. The threat model is required to be updated as needed throughout the development process to reflect changes in the design or implementation of the application.
Policies and processes exist to ensure that secure system architecture and engineering principles are established, documented, maintained and applied to development activities.
Appropriate architecture diagrams and documentation are required for all development projects, and these must be reviewed and approved by archtecture and the security team before development can begin. The architecture documentation must include a description of the system components, their interactions, and the security controls that are implemented to protect the system.
Data classification must be performed for all data in scope, and the architecture must be designed to protect data according to its classification. Potential changes to data classification must also be identified and reviewed by the security team to ensure that appropriate controls are in place to protect the data.
Policies and processes exist to ensure that secure coding principles are established, documented, maintained and applied to development activities.
A security champions program is in place to promote secure coding practices and to provide developers with resources and support for secure coding. Champions receive regular training on secure coding practices, and they serve as a resource for their teams to help identify and address security issues in code.
Champions also play a key role in promoting a culture of security within development teams and in advocating for security best practices throughout the development lifecycle.
The program helps to ensure that secure coding practices are consistently applied across development teams and that security is integrated into the development process from the outset.
The Flexera and Revenera champions programs are separate but share most practices and resources.
Annual mandatory training is required for champions as a supplement to the regular ongoing training.
Policies and processes exist to ensure that security testing processes are defined and implemented in the development life cycle.
Testing is automated as far as possible, though developers are expected to test security as part of test-driven-development practices. Flexera operates a broad range of automated security testing, including static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA) to identify vulnerabilities in code and dependencies before deployment. This testing extends to infrastructure as code (IaC) to identify vulnerabilities and misconfigurations in infrastructure changes before deployment.
Commits are gated on automated testing results using the GitHub push request review mechanims and AI-based code review is also performed.
Developers have access to AI tools to assist with secure coding and security testing throughout the development lifecycle. These tools can help identify potential security issues in code, suggest secure coding practices, and automate certain aspects of security testing.
Flexera does not outsource development. Outsourced development controls are considered non applicable for ISO 27001 certification purposes and similar representations are made with respect to other certifications and attestations.
Policies and processes exist to ensure that development, testing and production environments are separated and appropriately secured. The focus is on protection of the production environment from compromise originating or leveraging development and test environments or activities.
Segregation of environments exists at the cloud account level, at the VPC level, at the transit gateway level, and at the access control level. Access to production systems is monitored, and controls are in place to ensure that access is appropriate and that risks associated with access are mitigated.
Flexera has policies and processes to ensure that changes to information processing facilities and systems is subject to appropriately rigorous change management procedures.
Rigorous controls are implemented to ensure changes are appropriately tracked, reviewed and tested.
Infrastructure changes rely on IaC so that changes are automatically tracked, auditable, and reversible. Use of IaC also allows securitys scanning of infrastructure changes prior to deployment, and automated testing of changes in non-production environments.
Changes to production systems require testing in non-production environments, post-implementation validation, and deployment via a CI/CD system with an approval mechanism.
Policies and processes exist to ensure that test data is appropriately sourced, protected and managed. Flexera requires written customer consent for the use of production data in testing, and production data is not used in testing without such consent. If production data is used in testing, it is appropriately protected and must remain with a production system boundary.
In most cases, synthetic data is used for testing purposes, and this data is generated in a manner that ensures that it does not contain any real customer data or personally identifiable information (PII). When synthetic data is used, it is designed to be representative of real data to ensure effective testing while minimizing risks and exercising edge cases.
Policies and processes exist to ensure that systems are protected during audit testing - assurance activities are planned and terms agreed with the tester and the process is managed.
Testing is performed in segregated systems where possible. When testing is performed within a production system a dedicated tenant is used.
Access to test systems is revoked as soon as testing is complete. Test systems are decommissioned as soon as they are no longer needed. Test systems are monitored for anomalous activity during testing, and alerts may be generated for potential security incidents.
Use of cloud computing services for Flexera business purposes requires formal authorization as well as cloud vendor assessment. The shared security responsibility model ensures that the division of responsibilities between Flexera and the provider is clearly defined.
Controls are in place covering all aspects of access management including cloud account assignment, privileged access, credential security and access keys.
The responsibilities of the assigned account owners are defined including asset classification, infrastructure compliance, patching and updating, vulnerability remediation, disaster recovery, etc.
Requirements for cloud data segregation are defined and implemented covering segregation of accounts, segregation of customer data, replication of customer data and segregation of network traffic by purpose.
Cloud privacy controls are implemented to ensure data sovereignty, account and network traffic segregation by region, and international data transfer.
Specific cloud security controls are defined and implemented for AWS and Microsoft Azure.
See Cloud Provider Shared Responsibility Models in the Resources Section for more information on the shared responsibility model established for Flexera's cloud providers.
Flexera has a comprehensive framework for security incident management. The framework covers all stages in the incident management process including events to report, reporting mechanisms, detection and investigation, analysis, activation and evidence collection, containment and remediation, recovery and post-incident review.
Flexera has defined and documented Privacy and Incident Response Plan, Cloud Security Incident Response Plan and Crisis Communication Plan.
Flexera has a dedicated SOC team responsible for monitoring, detecting, and responding to security incidents across production infrastructure.
Flexera maintains a vulnerability management program to identify, assess, and remediate security vulnerabilities across systems and applications using a risk‑based approach. Application and system owners actively monitor trusted sources for security advisories and vendor patch releases.
Flexera uses a shift-left approach to vulnerability management, incorporating security testing and scanning early in the development lifecycle. This includes static application security testing ( SAST), dynamic application security testing (DAST), and software composition analysis (SCA) to identify vulnerabilities in code and dependencies before deployment.
Flexera uses industry‑standard vulnerability scanning tools to assess both pre‑production and production environments. External-facing systems are scanned prior to deployment, and identified vulnerabilities are remediated before systems are moved to production, where appropriate. Production external‑facing systems undergo regular scanning, and findings are prioritized and addressed based on severity.
Security patches are applied according to defined timelines. Exceptions to remediation timelines are reviewed, risk‑assessed, and documented. These activities are aligned with Flexera’s broader risk management processes to reduce exposure, minimize attack surfaces, and maintain a strong security posture.