What is the difference between a dry run and a live SDK release?

Why This Matters for Security Teams

A dry run and a live SDK release are not just different execution modes. They represent two different risk profiles for software supply chain change. Dry runs are used to validate build logic, dependency resolution, and release artifacts without making durable changes. Live releases commit the result into the repository workflow, which means pull request creation, test execution, approvals, and downstream publication can all be triggered. That distinction matters because release automation often touches secrets, CI/CD permissions, and privileged service accounts.

For NHI governance, the difference is operational: a dry run should stay ephemeral, while a live release often requires authenticated access, scoped tokens, and tightly controlled write permissions. NHI Management Group’s research shows that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which is exactly the kind of environment where release tooling becomes a high-value target. The question is therefore not only about developer convenience, but about whether automation is allowed to act with standing privilege. Current guidance from the NIST Cybersecurity Framework 2.0 supports tighter governance around protected workflows and access control. In practice, many security teams discover release-path abuse only after a CI job has already written to a repository or published an artefact, rather than through intentional release-stage design.

How It Works in Practice

In a dry run, the SDK release pipeline typically performs the same parsing, packaging, version calculation, and dependency checks as a real release, but it suppresses side effects. That means no pull request is opened, no tag is pushed, no publication occurs, and any generated output is discarded or written to a temporary location. This is useful for validating whether the release will succeed before credentials, branch protections, or approvers are involved.

A live release follows the same core path, but it executes the final actions that change state. In practice, that often means the pipeline must authenticate with a workload identity or short-lived secret, then prove it is allowed to modify a repository or publish to a package registry. For non-human identities, the safer pattern is to avoid long-lived static credentials and instead use ephemeral, task-bound access. That aligns with the broader NHI guidance in Ultimate Guide to NHIs — What are Non-Human Identities, especially where release automation is part of a larger zero-trust design.

• Dry run: validate the release plan without mutating repository or registry state.
• Live release: create real artefacts, open real pull requests, and trigger real approvals.
• Dry run: safe for testing permissions, formatting, and packaging logic.
• Live release: requires scoped credentials, change control, and audit logging.

Teams usually pair this with policy checks, for example requiring signed builds, approval gates, and a release identity that is separate from developer accounts. Authoritative identity guidance such as NIST Cybersecurity Framework 2.0 reinforces the need to manage access by function and risk, not by convenience. These controls tend to break down when the same automation token is reused across dry runs, staging, and production because the boundary between “test” and “publish” disappears.

Common Variations and Edge Cases

Tighter release controls often increase operational overhead, requiring organisations to balance validation speed against change assurance. That tradeoff becomes more visible when SDK releases are run in monorepos, multi-package pipelines, or agent-assisted build systems where the same job may generate both preview output and production artefacts.

There is no universal standard for naming or implementing dry runs, so one platform may suppress only publication while still creating PR metadata, whereas another may block all external writes. Best practice is evolving, but the safest interpretation is simple: if any action leaves durable state outside the runner, the job is no longer a dry run. That includes draft pull requests, tags, release notes, registry uploads, and webhook-triggered side effects. In environments with high secrets exposure, that distinction is critical because release jobs often have broader reach than they appear to on paper. NHI Management Group’s research also notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes token handling during release paths especially sensitive.

For regulated or production-critical software, the live release path should be treated as a privileged workflow with its own identity, logging, and revocation process. Dry runs can help verify expected output, but they do not prove that the live identity, approver chain, or publication target is safe. Use the Ultimate Guide to NHIs — What are Non-Human Identities as a reference point for separating ephemeral automation from standing access, especially when release pipelines are delegated to autonomous tooling.

Related resources from NHI Mgmt Group

• What is the difference between run, grow, and transform spend for identity teams?
• What is the difference between a source schema and generated SDK code?
• What is the difference between SDK monitoring and proxy-based monitoring for AI agents?
• What is the difference between passive access review and live governance write-back?