Customer-Introduced Open-Source Software (OSS)
Guidewire is committed to a secure, reliable, and compliant Guidewire Cloud Platform (GWCP). While customers may introduce third-party open-source software (OSS) to meet unique business requirements, such as incorporating a specialized PDF generation library for custom policy documents or an advanced charting tool for internal claims analysis, it is crucial to understand the associated responsibilities. Customers are fully responsible for the security, compliance, risk management, and lifecycle of any OSS they introduce into their Guidewire solutions.
Why Should Customers Care About Introducing OSS?
Security Vulnerabilities: Customer-introduced OSS can contain flaws that, if not vetted and patched by customers, can lead to unauthorized data access, potential data loss, or system compromise. For example, an older version of a common data parsing library might have a known deserialization vulnerability that, if exploited, could allow an attacker to execute arbitrary code.
System Instability: Incompatible or poorly implemented OSS may cause application crashes, performance degradation, or obstruct Guidewire platform upgrades. This can occur if a customer introduces an alternate version of a library already used by Guidewire, especially one with known issues or custom modifications, leading to conflicts, unexpected behavior in standard functionality, or difficulties during platform maintenance and upgrades.
Increased Costs & Delays: Issues arising from OSS customers' integration can result in unforeseen expenses, rework, and impact on project schedules.
Compliance & Licensing Issues: Compliance & Licensing Issues: Unmanaged OSS can violate licensing terms or introduce components that don't meet their regulatory security standards. For instance, inadvertently using an OSS component with a 'copyleft' license like AGPL that requires broader source code disclosure might conflict with a customer's own licensing or commercial objectives if not properly managed.
Missed Critical Updates: Failure to track and apply security patches for customer-introduced OSS exposes known vulnerabilities within their solutions.
Guidewire emphasizes customer responsibility for these aspects to maintain overall solution integrity and security.
| Risk Category | Description |
|---|---|
| Vulnerability Exposure | Customer-introduced OSS may contain known or unknown vulnerabilities. Without continuous scanning and patching by customers, these expose their systems. |
| Lifecycle Mismatches | OSS components have their own lifecycles. If customers do not align these with Guidewire updates or their business needs, they can cause conflicts or become unsupported. An example is relying on an OSS project for a critical custom integration point that later becomes unmaintained by its community, no longer receiving security updates or compatibility fixes for new Java versions. |
| License Non-Compliance | OSS licenses vary greatly. Customers must ensure compliance to avoid legal issues; some licenses may be incompatible with their intended use or enterprise policies. |
| Performance Degradation | Poorly optimized or unsuitable OSS can consume excessive resources, slowing down their applications or impacting overall stability. |
| Lack of Internal Governance | Without customer-defined criteria for OSS selection, vetting, and monitoring, risky components may be introduced into their solutions without due diligence. |
Guidance for Managing Customer-Introduced OSS
Customers who choose to introduce OSS must adopt robust management practices to mitigate the inherent risks:
Establish Clear Governance:
- Define internal OSS selection, approval, and usage policies, including acceptable license types, security standards, and prohibited components.
- Include early cost assessment for securing and maintaining customer-introduced OSS.
- Define internal OSS selection, approval, and usage policies, including acceptable license types, security standards, and prohibited components (e.g., explicitly forbidding the use of OSS with known critical vulnerabilities that lack patches, or libraries with licenses incompatible with commercial use unless a specific exception is granted).
- Establish guidelines for verifying the source and integrity of downloaded OSS packages (e.g., checking build processes, using trusted repositories).
Perform Rigorous Vetting:
- Thoroughly assess any OSS before integration for security vulnerabilities (e.g., using SAST/DAST tools), code quality, active maintenance, community support, and licensing implications.
- Specifically assess the OSS design for missing security features or necessary hardening configurations. For example, an introduced OSS component providing a web-based utility might default to HTTP and require explicit configuration to enforce HTTPS, or it might have default credentials that must be changed.
- Conduct historical vulnerability searches for any considered OSS component.
- Research the OSS community's security policies, vulnerability reporting/fixing processes, and typical timelines for fixes.
- Evaluate the health of the OSS project, including contributor participation, contribution acceptance, and long-term maintenance trends.
- Create or update a threat model for the application, considering the risks introduced by the specific OSS.
Implement Continuous Monitoring & Scanning:
- Utilize Software Composition Analysis (SCA) tools to identify all OSS components (including transitive dependencies), known vulnerabilities (CVEs), and license information on an ongoing basis.
Maintain an Inventory (SBOM):
- Keep an up-to-date Software Bill of Materials (SBOM) for all customer-introduced OSS to track versions, dependencies, and licensing accurately.
Ensure Timely Patching:
- Proactively monitor for security advisories and promptly apply necessary patches and updates to all customer-introduced OSS components in their environments.
Document Responsibilities:
- Clearly document within the customers' teams who is responsible for the ongoing management, security oversight, and incident response for each customer-introduced OSS component.
These practices are essential for mitigating risks associated with customer-introduced OSS and ensuring the long-term health and security of customers' Guidewire solutions.
Additional Resources
Guidewire:
NIST (National Institute of Standards and Technology):
- The Minimum Elements For a Software Bill of Materials (SBOM)
- Secure Software Development Framework (SSDF) Version 1.1 (NIST SP 800-218)
- Guide to Enterprise Patch Management Technologies (NIST SP 800-40 Revision 4)
OWASP (Open Web Application Security Project):
- OWASP Software Component Verification Standard (SCVS)
- OWASP Vulnerable Dependency Management Cheat Sheet
- OWASP Top 10 CI/CD Security Risks (Relevant for secure software lifecycle)
Linux Foundation (OpenSSF - Open Source Security Foundation):
IBM Developer:
Was this page helpful?