Hardening your CI/CD pipeline

Shipping a .NET build safely is more than compiling it. This is the release-pipeline checklist Nebula.NET is built to slot into — each step automatable in CI, and in the order that matters.

The order (this matters)

publish  →  obfuscate  →  sign  →  attest / release

Obfuscation rewrites IL, so it must run before signing — sign first and you invalidate both the Authenticode signature and Nebula’s own anti-tamper hash. Get the order wrong and the build either won’t verify or ships unprotected.

1. Obfuscate in the build

The MSBuild integration protects every assembly (and every target framework) as part of dotnet build / msbuild.exe — no separate step. On build servers, turn on the fail-closed switch so a missing/revoked license breaks the build instead of silently shipping readable code:

{ "requireLicensedEdition": true, "controlFlowObfuscation": true, "encryptStrings": true }

See MSBuild & CI and requireLicensedEdition. License only the build machine(s), not every developer.

2. Automate signing

Do strong-name and Authenticode signing in the same pass, right after obfuscation, so keys live in your CI secret store — never in the repo:

{
  "strongNameKeyEnvVar": "SNK_BASE64",
  "authenticodeCertThumbprint": "‹cert in the agent store›",
  "authenticodeTimestampUrl": "http://timestamp.digicert.com"
}

strongNameKeyEnvVar reads a base64 .snk from an environment variable (a pipeline secret), and Authenticode can sign from a .pfx, an env-supplied password, or a cert thumbprint in the machine store. See Signing. Because Nebula re-signs the obfuscated output, the strong name your consumers pin stays intact.

3. Scan artifacts for leaked secrets

Before you publish, check what a stranger could read out of the shipped binaries. The free Glass.NET includes a secret scanner — hardcoded keys, tokens and high-entropy strings — so you catch an accidentally-committed API key or connection string in the build, not after it’s in customers’ hands. Run it over your release output (GUI: View ▸ Sensitive-String Findings; or the exposure report for a full readability summary). Pair it with Nebula’s string encryption so anything that must stay in the binary isn’t sitting there in plaintext.

4. Build provenance & release

Nebula produces the hardened, signed artifact; pair it with your CI’s native artifact attestation (for example GitHub Actions’ attest-build-provenance) so downstream consumers can verify the exact binary came from your pipeline. Publish the signed artifact plus its SHA-256 (and attestation) as the release.

The result

A pipeline where every shipped assembly is obfuscated, signed, and secret-checked automatically — and where a licensing or ordering mistake fails the build loudly rather than leaking readable code. Nothing on a developer’s machine changes; the hardening lives on the build server.

Questions about wiring this into your specific CI (GitHub Actions, Azure DevOps, GitLab, TeamCity)? Ask us — or see the GitHub Actions walkthrough.