Application and Development Security

Your responsibility for security spans the entire lifecycle of your implementation—from the code you write to the configurations you deploy and maintain. While Guidewire manages the underlying cloud platform, you are responsible for embedding secure practices into your development and operational workflows.

This section outlines our recommended controls and best practices for building, deploying, and maintaining a secure application on the Guidewire platform.

Core Principle: Security is an Intrinsic Quality, Not a Final Step

Security should be integrated into every phase of your development process, not treated as an audit at the end. Every design decision, line of code, and configuration choice should be made with a focus on minimizing risk and building a defensible application in alignment with modern security best practices, such as the OWASP Top 10.

Principle 1: Secure the Foundation: Code and Components

Security starts with the integrity of your code and the third-party components you introduce.

Control Objective: Your Guidewire-provided SCM repository (BitBucket) should be treated as the single source of truth for all customer-managed configuration and code. All changes should be versioned and tracked through a pull request and review process.
Control Objective: You should formally adopt and follow a Secure Software Development Lifecycle (SSDLC) for all custom development work.
Control Objective: You are solely responsible for patching all customer-introduced Open-Source Software (OSS). You should continuously monitor security advisories (for example, CVEs) and use Software Composition Analysis (SCA) to find and remediate vulnerable dependencies before requesting a deployment.
- Example: You introduce a custom open-source library for image processing. A high-severity CVE is published for that library. Your team is responsible for identifying the risk, procuring the patch, testing it, and deploying the update.
Control Objective: You should not modify the core Guidewire layers. All custom development should be done in the customer layer.

Principle 2: Harden the CI/CD Pipeline and Deployments

Your Continuous Integration/Continuous Deployment (CI/CD) pipeline is a critical control plane that should be configured to prevent insecure code from reaching production.

Control Objective: All custom code should be reviewed for security vulnerabilities before promotion. This should include running Static Application Security Testing (SAST) tools and Guidewire Studio's Cloud Assurance Plugin to resolve all violations.
- Example: After running an inspection, your team identifies the use of a deprecated API. They refactor the code to use the supported, modern API and then revalidate the changes with the Cloud Assurance Plugin before committing.
Control Objective: You should leverage the Guidewire Quality Gates feature to automatically block the promotion of non-compliant builds. A "pass" signal from all your required security scans should be a prerequisite for any deployment to production.
- Example: Your pipeline runs an SCA scan and detects a new vulnerability in a library. The scan sends a "fail" signal to Quality Gates, which automatically blocks the build and alerts the team.

Principle 3: Minimize the Attack Surface

Every enabled feature, tool, and interface is a potential attack vector and should be explicitly secured.

Control Objective: Unused features, internal tools (for example, Profiler, Debug panels), and sample code should be disabled in all production environments.
- Example: Before promoting a configuration to production, you disable the Profiler and Debug panels and validate that no internal tools are exposed via user interface (UI) menus.
Control Objective: All API endpoints should enforce authentication and authorization using OAuth 2.0 bearer tokens issued by Guidewire Hub. All API inputs should be validated on the server side.
- Example: A billing microservice uses a scoped JWT with a scp.pc.acme_billingapp claim, and only the fields defined in its API role are returned in GET requests.
Control Objective: You should configure session timeout values appropriate for your security requirements and ensure secure cookie settings (HttpOnly, Secure) are used.
Control Objective: The use of custom servlets is not a recommended practice. All integrations should be implemented using the approved REST API framework.

Principle 4: Maintain Continuous Vigilance

Security verification is an ongoing process that extends beyond the initial deployment.

Control Objective: Your team should conduct periodic (for example, quarterly or pre-release) reviews of your InsuranceSuite security configurations, including roles and permissions, to identify and remove obsolete or overly permissive settings.
- Example: During a quarterly review, your team discovers a legacy user role with elevated permissions. You remove the role and update your provisioning process to ensure only approved, least-privileged roles are created.
Control Objective: You should regularly conduct security tests on your custom configurations and code, in alignment with Guidewire's official customer security testing policy.
Control Objective: You should subscribe to and review all Guidewire security bulletins and apply relevant updates in a timely manner, ensuring you stay current with supported application versions (N-2).

Resources

Guidewire Security Hub:

Guidewire Cloud Standards:

Guidewire Documentation:

OWASP:

Was this page helpful?

Core Principle: Security is an Intrinsic Quality, Not a Final Step​

Principle 1: Secure the Foundation: Code and Components​

Principle 2: Harden the CI/CD Pipeline and Deployments​

Principle 3: Minimize the Attack Surface​

Principle 4: Maintain Continuous Vigilance​

Resources​