> ## Documentation Index > Fetch the complete documentation index at: https://docs.getmilana.ai/llms.txt > Use this file to discover all available pages before exploring further. # Security Posture > How the Milana browser SDK is built, published, and maintained — open source, with a hardened supply chain and a minimal dependency footprint. The Milana SDK runs in your users' browsers, so its integrity is part of your attack surface. This page documents how the SDK is sourced, built, published, and maintained, for security teams evaluating Milana. ## Open source The SDK is open source and MIT licensed. The full source — including the release pipeline and dependency manifest described below — lives in a [public repository](https://github.com/VantaraAI/milana-sdk). The published [`milana-js`](https://www.npmjs.com/package/milana-js) npm package is built from this repository — and provenance attestations let you cryptographically verify that link, as described below. ## Supply-chain integrity Every release is produced by an auditable CI pipeline with no long-lived credentials. | Control | How it works | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **npm provenance** | Each published version carries a signed provenance attestation linking it to the exact source commit and CI workflow run that produced it, recorded in the public Sigstore transparency log. | | **Trusted publishing (OIDC)** | npm publishes authenticate via short-lived OIDC tokens, not a long-lived npm token. There is no static publish credential to leak. | | **Keyless cloud auth (OIDC)** | The pipeline authenticates to Google Cloud via Workload Identity Federation. No long-lived cloud keys are stored in the repository or CI. | | **Environment protection** | The publish step runs in a dedicated `release` GitHub Environment gated by required reviewers and branch restrictions — a designated reviewer must approve each release, and only authorized branches can trigger one. | | **Tag validation** | Releases are cut only from version tags matching `vMAJOR.MINOR.PATCH`; malformed tags fail the build before anything is published. | | **Verified build** | A release re-runs the full CI suite and rebuilds the package from source immediately before publishing — the published artifact is never a stale or local build. | | **Concurrency guard** | Releases cannot overlap; an in-progress publish is never cancelled or raced by another. | | **Least-privilege workflows** | Every workflow defaults to no permissions; each job opts into only the scopes it needs (for example, identity-token issuance is granted solely to the publish job). | | **Pinned GitHub Actions** | Every third-party action is pinned to a full commit SHA, not a mutable tag — blocking tag-hijack attacks against the build. | ### Verifying provenance You can verify the provenance and signatures of the installed package against the public registry at any time: ```bash theme={null} npm audit signatures ``` The package page on [npmjs.com](https://www.npmjs.com/package/milana-js) also displays the provenance for each published version, including the source commit and the workflow that built it. ## Dependency security The SDK keeps its runtime surface deliberately small and gates every dependency change. | Control | How it works | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Minimum release age** | A newly published dependency version must be public for at least 7 days before it can be installed, mitigating fast-pulled malicious releases. | | **Frozen lockfile** | CI and releases install from a committed lockfile with no resolution drift — the lockfile is the single source of truth for the dependency graph. | | **Vulnerability audit gate** | Every pull request runs a dependency audit that fails on any high- or critical-severity advisory. | | **Automated updates (Dependabot)** | Dependabot opens upgrade pull requests for dependencies and GitHub Actions; each one runs through the same audit, test, and build gates before it can merge. | ### Dependency footprint The SDK ships with a deliberately minimal runtime surface: * **A single production dependency** — `@rrweb/record`, the industry-standard session recording library (used by Sentry, Posthog etc.) * **React is an optional peer dependency** - The rrweb and React type packages are development-only — imported as types and erased at build time. A minimal direct surface keeps the transitive graph and the audit scope small. ## Code integrity gates Every pull request must pass the same checks before it can merge: * Lint and format, type checking, tests, build * Automated AI review * Human review ## Reporting a vulnerability Security issues are handled privately, never through public issues. The repository's [`SECURITY.md`](https://github.com/VantaraAI/milana-sdk/blob/main/SECURITY.md) is the canonical policy. * **Report to** [security@getmilana.ai](mailto:security@getmilana.ai). * **Acknowledgement** within 48 hours. * **Fix or mitigation** targeted within 7 days. * **Supported versions:** the `1.x` release line. ## Related Block, mask, or ignore sensitive elements before they are recorded. Keep session recordings in a storage bucket you own and control. For our platform security posture, including SOC 2 Type II certification, see the [Milana Trust Center](https://trust.getmilana.ai).