Upgrade Model & SDLC

Glean maintains a robust software delivery model designed to ensure customers always have access to the latest features while maintaining the highest standards of security, privacy, and reliability.

Our Software Development Lifecycle (SDLC) follows strict processes to ensure only trusted and verified code runs in customer deployments.

Trust Chain Overview

Our SDLC implements a comprehensive chain of trust that governs code from development through deployment:

• Reviewed, validated, and approved code is merged only into trusted branches.
• A central, locked-down build service reads from trusted branches and produces signed artifacts.
• A restricted deployment workflow in each customer environment only accepts these signed artifacts and validates integrity before upgrade.

Development and Deployment Process

The following sections describe how code moves from development to production through a controlled, auditable pipeline.

Code Management

Protected Branches

Release branches are protected and only accept code after mandatory review through signed commits. Access to critical branches is tightly controlled and monitored.

Vulnerability Scanning

Continuous source and dependency scanning (for example, via SCM-native vulnerability scanners and dependency analysis tools) assists in early detection of potential security issues. Findings are triaged and turned into tracked remediation work validated before release.

Build Process

1

Central Build Service

A locked-down build service (implemented using Google Cloud Build) periodically fetches code from trusted branches in GitHub. The build service runs in a hardened project with restrictive IAM policies and minimal network access.

2

Container Building

The build service builds Docker container images for Glean services and signs them using binary authorization. Only a limited set of Glean engineers can trigger builds; they cannot modify the build pipeline itself.

3

Security Scanning

Multiple scanning tools are employed during the build process as defense in depth, including:

• Web application security scanning against key application surfaces
• Cloud asset configuration scanning to detect misconfigurations in cloud resources
• Container registry scanning to detect vulnerable OS and language packages in built images

These layers help ensure that vulnerabilities are detected as early as possible, before artifacts are promoted to customer environments.

Vulnerability Management

Vulnerability management is integrated directly into the SDLC and release pipeline so that every release is evaluated for security risk before it is made available to customers.

Per-Release Security Analysis

For every release that ships to customers, Glean runs an automated security analysis pipeline over all code and artifacts included in that release. This includes:

• Industry-standard security vendor tooling to:
  • Scan source code, dependencies, and container images for known vulnerabilities.
  • Identify misconfigurations and insecure defaults in the environment footprint associated with the release.
• Executable code reachability analysis to:
  • Determine whether vulnerable functions or code paths are actually loaded and reachable under expected configurations.
  • Distinguish between issues that are present in transitive dependencies but never exercised, and issues that are realistically invokable in production.

This analysis runs as part of the release process and is updated on every release, not just on a scheduled calendar.

Risk Ranking and Measurement

All identified vulnerabilities from the release analysis pipeline are normalized and ranked using Glean's internal risk measurement criteria. At a high level, this process:

• Aggregates findings across multiple scanners and analysis engines.
• Applies a risk scoring model that incorporates:
  • Upstream severity information.
  • Exploitability and reachability (for example, whether the vulnerable path is actually executable in our usage).
  • Potential impact in the context of how the affected component is used in Glean.
• Assigns each issue a criticality level (for example, Critical, High, Medium, Low) according to Glean's internal metric.

note

The exact details of this measurement metric and mapping from raw scanner output to final criticality levels are documented separately and can be shared under NDA.

Release Gating, Reports, and Timelines

The outcome of this vulnerability analysis is fed back into the SDLC and release process:

• Critical vulnerabilities:
  • Are heavily prioritized for patching and generally must be addressed before a release is allowed to ship.
  • May result in release gating, requiring a fix or a compensating control before the release can be promoted to customer environments.
  • Can trigger out-of-band patches when appropriate, rather than waiting for the next scheduled release.
• High and medium vulnerabilities:
  • Are scheduled into the engineering backlog according to their criticality.
  • Have target timelines for remediation based on risk, exposure, and customer impact.

For customer-hosted deployments only:

For each release, Glean produces a consolidated vulnerability report that:

• Summarizes the vulnerabilities relevant to that release and their final criticality ratings under Glean's metric.
• Highlights any reachable and exploitable issues and the actions taken (or planned) to mitigate them.
• Includes an expected timeline for resolution for issues that are not yet fixed, aligned with Glean's risk-based remediation policy.

Each report is exported as both an interactive HTML report and a machine-readable CSV file, stored in your deployment's release-notes bucket (S3 or GCS) alongside your regular release notes.

note

You should leverage this report to compare and contrast with your own security tooling to get a full understanding of which vulnerabilities are outstanding and how they rank. Please consult this report first before submitting a support ticket should you detect security vulnerabilities with your internal tooling.

Quality Assurance

info

All releases undergo comprehensive testing in separate tenancies before customer deployment. No production or customer data is ever used in testing.

Our QA process includes:

Internal Soak Testing

Extended soak periods for new releases in non-production environments, with monitoring for regressions in stability, performance, and correctness

Automated Testing

Comprehensive automated test suites covering unit, integration, end-to-end, and regression tests. CI pipelines enforce these checks before code can be promoted to release branches.

Manual Testing

Targeted manual verification for new or high-risk features, complex integration paths, and UX regressions that are hard to capture automatically

Security Testing

P0 security and permissions testing as part of release validation, including targeted regression testing for authentication, authorization, connector boundaries, and administrative surfaces

Deployment Process

1

Central Workflow

A central deployment workflow orchestrates upgrades across customer environments. The workflow is limited to invoking specific, pre-authorized cloud functions within customer tenants.

2

Release Specification

The only input to the customer-side upgrade function is the name of the approved release to upgrade to. Customer environments never receive arbitrary code or configuration from the central control plane.

3

Self-Upgrade

The system self-upgrades by downloading the signed release from a trusted storage location and verifying integrity using binary authorization policies. Only releases that pass these verification checks are allowed to run.

Security Measures

Access Control

Glean implements:

• Single Sign-On (SSO) with Multi-Factor Authentication (MFA) for all corporate systems
• Short-lived authentication sessions (for example, 24-hour sessions for cloud console access) that require re-authentication after expiry
• Centralized identity and access management with periodic reviews and revocation for unused or unneeded access

Access controls for source and build infrastructure include:

• Limited engineer access to private GitHub repositories, based on role and need-to-know
• Separation of duties: engineers who can trigger builds cannot modify the build pipelines; pipeline configuration changes require separate review and approval

Security Testing and Compliance

Security Exercises

Regular tabletop exercises to practice detection, response, and recovery for realistic incident scenarios, complemented by periodic external penetration testing by specialized security firms. Follow-up remediation and verification of findings are tracked to closure.

Compliance Standards

Glean maintains SOC 2 Type II compliance

note

Detailed reports including the latest penetration test results and full SOC 2 Type II documentation are available under NDA through your Glean account team.