SDK Security & Release Integrity
Siebly SDKs are open source and released through a controlled pipeline designed to reduce operational and supply-chain risk. The engineering lead is the gatekeeper for production changes and publish approvals, with traceability from pull request to npm release.
Last updated: 27 February 2026
Risk Controls in Practice
PR-gated change control
Code changes flow through pull requests. Production branches are protected by review gates, and merges require approval by the engineering lead.
Automated live integration tests
End-to-end test suites run on change and exercise real API flows, including supported authentication variants, to detect regressions before release.
Manual review plus Snyk checks
Pull requests are required to undergo manual stability and security review, while automated Snyk checks run in parallel to catch known dependency and code risks.
Dependency intake policy
Third-party dependencies are kept intentionally lean. Newly published dependency versions are typically held for at least 30 days unless a manual review provides clear justification.
Tokenless npm publishing
SDK packages use npm Trusted Publishing via OIDC. This avoids long-lived npm publish tokens and limits release authority to approved CI identities.
Provenance-backed audit trail
Releases are published with provenance attestations so npm consumers can inspect where and how a package version was built and connect it to source control.
Release Control Chain
1. Controlled merge and release queue
Merged pull requests do not publish automatically. A release is queued manually in GitHub Releases and requires a separate approval step by the engineering lead.
2. Signed publish workflow with OIDC
The release pipeline uses trusted publishing identities instead of tokens. npm validates workflow identity before minting short-lived publish credentials for that run.
3. Provenance and traceability
Published versions carry provenance metadata, enabling independent checks against the originating repository and CI run.
4. Public, verifiable evidence
Consumers and exchange teams can inspect release history in GitHub and npm, use the aggregated /releases page, compare tags to commits, and validate package provenance details directly.
Independent Validation Checklist
Teams can independently validate trust in each update by applying checks such as:
- Inspect source and pull requests in the public repositories before adopting a release.
- Check release notes and tags via /releases and linked GitHub releases.
- On npm package pages, verify Trusted Publisher and Provenance indicators for each package version.
- Match provenance data to the originating repository commit and CI workflow identity where required by your internal review process.
Official Reference Material
npm Trusted Publishing (OIDC)
https://docs.npmjs.com/trusted-publishers
Open reference
npm Package Provenance
https://docs.npmjs.com/viewing-package-provenance
Open reference
npm OIDC GA Announcement
https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/
Open reference
Continuous Improvement
Security is an ongoing process. These controls are designed to materially reduce risk and improve release traceability for users and exchange partners. As ecosystem guidance evolves, Siebly reviews and updates release controls accordingly.
These controls are risk-reduction measures rather than an absolute guarantee, and production teams should maintain independent validation in their own change management workflows. Legal terms and scope apply as described in Terms & Conditions.