Endurecimiento de tu pipeline de CI/CD

Enviar una compilación .NET de forma segura es más que compilarla. Esta es la lista de verificación del pipeline de publicación en la que Nebula.NET está diseñado para encajar — cada paso automatizable en CI, y en el orden que importa.

El orden (esto importa)

publish  →  obfuscate  →  sign  →  attest / release

La ofuscación reescribe el IL, así que debe ejecutarse antes de la firma — si firmas primero, invalidas tanto la firma Authenticode como el propio hash de anti-manipulación de Nebula. Si te equivocas en el orden, la compilación o bien no se verifica o bien se envía sin protección.

1. Ofuscar en la compilación

La integración de MSBuild protege cada ensamblado (y cada target framework) como parte de dotnet build / msbuild.exe — sin paso aparte. En los servidores de compilación, activa el interruptor de fallo seguro para que una licencia ausente/revocada rompa la compilación en lugar de enviar silenciosamente código legible:

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

Consulta MSBuild y CI y requireLicensedEdition. Licencia solo la(s) máquina(s) de compilación, no a cada desarrollador.

2. Automatizar la firma

Haz la firma de nombre seguro y Authenticode en la misma pasada, justo después de la ofuscación, de modo que las claves vivan en tu almacén de secretos de CI — nunca en el repositorio:

{
  "strongNameKeyEnvVar": "SNK_BASE64",
  "authenticodeCertThumbprint": "‹cert en el almacén del agente›",
  "authenticodeTimestampUrl": "http://timestamp.digicert.com"
}

strongNameKeyEnvVar lee un .snk en base64 desde una variable de entorno (un secreto del pipeline), y Authenticode puede firmar desde un .pfx, una contraseña suministrada por entorno o una huella digital de certificado en el almacén de la máquina. Consulta Firma. Como Nebula vuelve a firmar la salida ofuscada, el nombre seguro que tus consumidores fijan permanece intacto.

3. Escanear los artefactos en busca de secretos filtrados

Antes de publicar, comprueba qué podría leer un desconocido de los binarios enviados. El gratuito Glass.NET incluye un escáner de secretos — claves codificadas, tokens y cadenas de alta entropía — para que detectes una clave de API o una cadena de conexión confirmada por accidente en la compilación, no después de que esté en manos de los clientes. Ejecútalo sobre tu salida de publicación (GUI: View ▸ Sensitive-String Findings; o el informe de exposición para un resumen completo de legibilidad). Combínalo con el cifrado de cadenas de Nebula para que todo lo que deba permanecer en el binario no quede ahí en texto plano.

4. Procedencia de la compilación y publicación

Nebula produce el artefacto endurecido y firmado; combínalo con la atestación de artefactos nativa de tu CI (por ejemplo, attest-build-provenance de GitHub Actions) para que los consumidores posteriores puedan verificar que el binario exacto provino de tu pipeline. Publica el artefacto firmado junto con su SHA-256 (y la atestación) como la versión.

El resultado

Un pipeline donde cada ensamblado enviado está ofuscado, firmado y verificado contra secretos automáticamente — y donde un error de licenciamiento o de orden hace fallar la compilación de forma ruidosa en lugar de filtrar código legible. Nada cambia en la máquina de un desarrollador; el endurecimiento vive en el servidor de compilación.

¿Preguntas sobre cómo conectar esto a tu CI concreto (GitHub Actions, Azure DevOps, GitLab, TeamCity)? Pregúntanos — o consulta el tutorial de GitHub Actions.