Browser extensions are still one of the highest-value — and highest-risk — elements in managed browser fleets. By mid‑2026, most large enterprises run dozens to hundreds of internal and third‑party extensions across Chromium and Firefox environments. A single compromised extension can exfiltrate credentials, intercept requests, or deliver persistent backdoors. This updated guide shows how to design a repeatable, auditable CI/CD pipeline for enterprise extension delivery that reflects developments through July 2026: SBOMs and artifact signing standards, wider adoption of Remote Browser Isolation (RBI) as a compensating control, sigstore-based signing workflows, and practical telemetry integrations for rapid revocation.

What you will learn and who this is for

This guide is for engineering, security, and endpoint teams responsible for extension lifecycle in large enterprises. You’ll get a step‑by‑step pipeline that covers governance, secure development, automated validation, SBOM generation, cryptographic signing, artifact hosting, policy-driven deployment, runtime telemetry, and incident response tuned for 2026 realities.

Prerequisites and context

Before implementing the recommendations, ensure you have:

  • Source control with protected branches and CI/CD (GitHub/GitLab/Azure DevOps)
  • An artifact repository (immutable storage or OCI registry) and key management (HSM or managed KMS)
  • Enterprise device management (GPO, Intune/Jamf, Chrome Enterprise, or equivalent)
  • SIEM/observability platform and, ideally, EDR that surfaces browser context

Newer considerations for 2026: require SBOMs for every extension build, adopt reproducible builds where practical, and incorporate sigstore/cosign (or equivalent) to bind source and artifact provenance.

High-level pipeline stages (updated for 2026)

  1. Governance and explicit risk policy
  2. Secure development standards, Manifest V3 readiness
  3. Automated static checks, SCA and SBOM generation
  4. Automated functional tests and isolated runtime testing
  5. Reproducible packaging and artifact signing (sigstore/cosign or HSM)
  6. Immutable artifact storage and internal catalog (OCI or blob + catalog)
  7. Policy-driven deployment and RBI where appropriate
  8. Runtime telemetry ingestion and alerting
  9. Incident response playbooks and practiced revocation

Step 1 — Governance and policy

Formalize an extension policy that covers approval criteria, permissions justification, deployment channels, and revoke authority. Updated best practices for 2026:

  • Require a documented business justification for any host_permissions beyond explicit URL lists; default to deny for "
  • Mandate SBOMs (CycloneDX or SPDX) as a required artifact for merge to main.
  • Define allowed update sources (internal OCI registry, corporate update server, private store) and require update URL whitelisting in ExtensionSettings.
  • Specify roles (developer, security reviewer, product owner) and require multi-party approval for high‑risk permissions.
  • Define SLAs for revocation (e.g., critical compromise: policy block within 1 hour) and tabletop exercise cadence.

Step 2 — Secure development standards

Secure coding remains foundational. Additions and clarifications for 2026:

  • Manifest compatibility: ensure MV3 compatibility for Chromium-family deployments; test for behavioral differences in Firefox where MV3 adoption may lag or require polyfills.
  • Secrets policy: never store long‑lived secrets in extension bundles; use short‑lived tokens and enterprise token exchange (backend mediated) when the extension needs auth credentials.
  • Least privilege by design: default to optional_permissions, declarativeNetRequest rulesets instead of blocking webRequest where MV3 allows, and granular host lists.
  • Require an automated SBOM generation step that captures direct and transitive JS/TS/package dependencies and native modules.
  • Use LLM tools for developer productivity (code suggestions, PR summaries) but always pair with deterministic static analyzers and human review to avoid over‑trusting AI outputs.

Step 3 — Automated static and dependency scanning

Run these checks early and gate merges:

  • Linters and security rules: ESLint + security plugins, TypeScript strictness, manifest schema validation.
  • Dependency SCA: Snyk/OSS SCA/Semgrep for known CVEs and risky transitive packages.
  • SBOM validation: ensure the SBOM matches built artifacts and is signed/recorded in CI.
  • Custom detectors: look for sensitive API usage (cookies, chrome.identity, cookies.getAll), remote code loaders, eval, dynamic script insertion.

Actionable example: block PR merges if SCA flags > critical severity OR if the manifest requests host_permissions covering 90%+ of domains without explicit business justification.

Step 4 — Automated functional testing

Functional tests catch real-world behavior that static scans miss:

  • End-to-end tests using Playwright or Puppeteer in CI that install the extension in clean, instrumented profiles and exercise permission flows and network calls.
  • Service integration tests for backend interactions, token exchange, and error handling.
  • Runtime isolation tests: exercise the extension in an RBI-enabled environment (if you use RBI) to validate that sensitive data does not reach local endpoints.
  • Fuzzing: targeted fuzz tests for HTML parsing and input processing to find DOM or XSS-like flaws.

Step 5 — Packaging and cryptographic signing

Practical options in mid‑2026:

  • Vendor-hosted private stores (Google, Microsoft) remain viable for ease of use and vendor signing.
  • Enterprise-hosted update servers or OCI registries: storing extension artifacts (crx/zip/zipx) as OCI artifacts is increasingly common; pair with an update manifest pointing to your controlled registry.
  • Artifact signing: use sigstore/cosign to sign artifacts and provenance metadata (recommended) and/or HSM-managed keys (Azure Key Vault, AWS KMS) for non-OCI flows.

Integrate signing into CI: only sign artifacts produced by a pipeline run that passed all gates, attach provenance, and store the signature alongside the artifact in your registry or artifact store.

Step 6 — Artifact storage and internal extension catalog

Store signed builds in immutable, versioned storage. Recommended approach:

  • Use an OCI registry or immutable blob storage with versioning and retention policies.
  • Publish a machine-readable internal catalog (JSON/GraphQL API) that includes: extension ID, version, signed SBOM pointer, build SHA, CI run ID, signer identity, allowed update URL, and approval metadata.
  • Expose a minimal UI for app owners and security reviewers to inspect provenance and approvals.

Step 7 — Policy-driven deployment

Deploy only using enterprise-managed policy channels. For Chromium-family browsers, prefer ExtensionSettings with explicit allowed update URLs and installation_mode settings. Deployment options:

  • Group Policy (Windows) and MDM (Intune, Jamf): set ExtensionSettings to block-by-default, then permit/force-install allowed IDs and controlled update URLs.
  • Cloud admin consoles and private store options: use private listings where available and ensure publisher accounts are protected with MFA and SSO.
  • Runtime controls: combine policy deployment with RBI for high-risk browsing profiles to limit extension-driven exfiltration.

Best practice: block all extensions by default and allow only signed, cataloged extension IDs with a documented update URL. Log and alert on any deviation.

Step 8 — Runtime telemetry and detection

Telemetry is essential to detect malicious updates or anomalous behavior. Recommended telemetry sources and fields:

  • Management APIs: Chrome Management API, Microsoft Graph/Intune reporting, and equivalent Mozilla telemetry for enterprise policies — collect installed extension list, version, install source, and update URL.
  • Endpoint telemetry: EDR agents that provide process and network context should report origin (extension ID, service worker script) for suspicious network flows.
  • SIEM/observability: ingest extension installation events, permission changes, sudden version bumps, and unknown update hosts. Create rules for: unexpected update URLs, version rollbacks, and service worker network patterns.

Example detection rule: alert if an installed extension's update URL changes from your OCI registry to a third‑party domain, or if a forced install appears outside configured OU/policy.

Step 9 — Incident response and revocation

Playbooks must be practiced and measurable. Key steps and metrics:

  1. Identify scope: list affected extension ID, version, devices, and OUs via management APIs.
  2. Immediate containment: update ExtensionSettings to block and force‑remove the ID, or use vendor blocklist features. If hosted, change update manifests or revoke signing keys.
  3. Rollback: re‑publish a safe, signed artifact from your artifact store and point update URL to the safe version if rollback is supported.
  4. Forensic analysis: preserve signed artifacts, CI logs, SBOM, and environment telemetry for root‑cause analysis.
  5. Communications: coordinate legal and privacy teams and notify impacted users/orgs per policy/regulatory requirements.

Metric: measure “time-to-policy-block” and “time-to-rollback”; target under one hour for confirmed critical compromises where policy and tooling allow.

Operational checklist and KPIs (updated)

  • All production extensions have a signed SBOM and are listed in the internal catalog (Yes/No)
  • Percentage of extensions blocked by default until approved
  • Mean time to policy block (goal: <1 hour for critical incidents)
  • Number of unauthorized installation attempts per month and detection coverage
  • Audit completeness: CI run IDs, signer, SBOM hash, approval records

Common mistakes and how to avoid them

  • Relying on extension name or publisher display name: attackers spoof names. Always use extension ID and update URL.
  • Skipping SBOMs and provenance: makes forensics hard. Make SBOMs required and sign them.
  • Manual signing or ad‑hoc uploads: breaks traceability. Automate signing and persist signatures in the artifact registry.
  • No runtime telemetry: you will be blind. Integrate management APIs and endpoint telemetry into your SIEM.

Pro tips

  • Use sigstore/cosign to record provenance: it ties the CI run and source to the published artifact and is now supported by many registries.
  • Generate reproducible builds where practical so that the signed artifact hash can be rederived from source.
  • Adopt RBI for high‑risk users (admin, finance) — it limits local data exposure even if an extension is compromised.
  • Enforce MFA and SSO on vendor publisher accounts and minimize the number of people who can publish to private stores.
  • Run periodic simulated incidents (tabletops and engineering drills) to measure real time-to-revoke and improve runbooks.

Practical CI pipeline example (compacted and current)

  1. Checkout code; run ESLint, TypeScript checks, unit tests.
  2. Generate SBOM (CycloneDX), run SCA and Semgrep policies, block on critical findings.
  3. Build extension bundle; run Playwright end‑to‑end tests in instrumented, clean profile and an RBI environment (if applicable).
  4. Produce reproducible artifact; run cosign to sign artifact + SBOM and upload to OCI registry or immutable blob store.
  5. Publish metadata to internal catalog and trigger approval workflow (security + product). Only after approval, update internal policy manifests or private store.

Notes for Firefox and other browsers

Firefox still supports webextension manifests but has historically diverged in MV3 support and signing workflows. Principles remain the same: require SBOMs, sign artifacts or use Mozilla signing where required, host updates on controlled endpoints, and use enterprise policies to control installs. Test for Firefox behavioral differences: extension APIs and service worker lifecycle can vary.

Conclusion

Extension risk continues to be a mature threat vector in 2026, but the toolset and operational practices have advanced: SBOMs, sigstore-style provenance, reproducible builds, and RBI are now practical controls you should incorporate. Start with clear governance, require SBOMs and signed provenance, automate checks and signing in CI, deploy by policy, collect runtime telemetry, and practice your revocation playbooks. These steps give you auditable releases and the speed to act when a problem appears.

Common pitfalls — quick recap

  • Manual installs and unsigned artifacts → poor traceability
  • Allowlisting by name → easily spoofed
  • No SBOM → opaque dependency risk
  • No telemetry → blind to malicious updates

FAQ

Do I have to move to Manifest V3 now?

Manifest V3 is the default development direction for Chromium-based browsers and brings security advantages (service workers, declarativeNetRequest). For enterprise fleets, make MV3 compatibility a requirement for new extensions and add MV2-to-MV3 migration tests to CI. Maintain temporary compatibility layers for legacy requirements but plan migrations—vendor timelines and Firefox behavior can differ, so test both runtimes.

What is an SBOM and why require it?

An SBOM (Software Bill of Materials) lists all direct and transitive components of your extension (npm packages, native modules). Requiring a signed SBOM with every build makes dependency forensics fast, enables automated SCA correlation, and is increasingly expected by procurement and security teams.

When should we use vendor private stores vs. hosting updates ourselves?

Use vendor private stores when you want vendor-managed signing, simplified distribution, and integrated enterprise controls. Host updates yourself (OCI or update server) when you need tighter control over update URLs, faster emergency rollbacks, or must meet strict data residency/provenance requirements. Either approach must be paired with signed artifacts and policy whitelisting.

How fast should revocation be?

Define SLAs in policy. For confirmed critical compromises, aim for policy block within one hour if tooling and administrative processes allow; for lower-severity issues, a documented multi-step revocation (block, rollback, notify) within 24–72 hours may be acceptable. Practice to validate these SLAs.

Are AI tools safe to use in the pipeline?

LLMs and AI code assistants speed development and help triage alerts, but they can hallucinate or miss nuanced security contexts. Use them for developer productivity and initial triage, but retain deterministic static analysis, SCA tooling, and human security review for critical decisions.