fix(ci): use ESRP Release for NuGet signing — fix 400 'must be signed' error

[Imran Siddique (imran-siddique)]

NuGet publish was failing with:
\
error: Response status code does not indicate success: 400
(This package must be signed with a registered certificate.)
\\

Root cause: Publish_NuGet stage used raw \dotnet nuget push\ which pushes unsigned packages. NuGet.org rejects unsigned packages from registered publishers.

Fix: Replace with \EsrpRelease@11\ task using \contenttype: Nuget, matching the pattern already used for PyPI, npm, and crates.io. ESRP handles signing + publishing.

[github-actions]

🤖 AI Agent: security-scanner — Security Review of PR: `fix(ci): use ESRP Release for NuGet signing`

Security Review of PR: fix(ci): use ESRP Release for NuGet signing

This PR addresses a critical issue where unsigned NuGet packages were being pushed to NuGet.org, which violates NuGet's requirement for signed packages from registered publishers. The proposed fix replaces the manual dotnet nuget push command with the EsrpRelease@11 task, which handles signing and publishing via Microsoft's ESRP (Extended Security Release Program).

---

Findings

1. Trust Chain Weakness: ESRP Configuration

Severity: 🔴 CRITICAL
Issue: The ESRP configuration relies on several pipeline variables (ESRP_KEYVAULT_NAME, ESRP_CERT_IDENTIFIER, ESRP_CLIENT_ID, etc.) to fetch signing certificates and credentials. If these variables are misconfigured, compromised, or improperly secured, the signing process could be bypassed or tampered with. Additionally, the usemanagedidentity: true setting assumes that the pipeline's managed identity has the correct permissions to access the ESRP Key Vault and perform signing operations. Any misconfiguration in these permissions could lead to a failure in signing or, worse, unauthorized access to the signing certificates.
Attack Vector: An attacker with access to the pipeline configuration or the Azure environment could manipulate these variables to use an unauthorized certificate or bypass signing altogether.

Recommendation:

• Validate that the pipeline's managed identity has the minimum required permissions to access the ESRP Key Vault and perform signing operations.
• Implement monitoring and alerting for any unauthorized changes to the ESRP-related pipeline variables.
• Use Azure Key Vault access policies or Azure RBAC to tightly control access to the signing certificates.
• Regularly audit the ESRP configuration and permissions to ensure compliance with security best practices.

---

2. Credential Exposure: Potential Leakage in Logs

Severity: 🟠 HIGH
Issue: The EsrpRelease@11 task includes sensitive inputs such as ESRP_KEYVAULT_NAME, ESRP_CERT_IDENTIFIER, ESRP_CLIENT_ID, and ESRP_DOMAIN_TENANT_ID. If these variables are not properly masked in pipeline logs, they could be exposed to anyone with access to the pipeline logs.
Attack Vector: An attacker with access to the CI/CD logs could extract sensitive information, such as the Key Vault name or client ID, and use it to attempt unauthorized access to the signing infrastructure.

Recommendation:

• Ensure that all sensitive variables are marked as secrets in the pipeline configuration. For example, in Azure DevOps, use the $(secretVariable) syntax to ensure they are masked in logs.
• Add a step to explicitly verify that no sensitive information is being logged during the ESRP task execution.
• Use the system.debug variable cautiously, as enabling verbose logging could inadvertently expose sensitive data.

---

3. Policy Engine Circumvention: Lack of Validation for ESRP Output

Severity: 🟡 MEDIUM
Issue: The pipeline does not include a step to validate the integrity of the signed NuGet packages after the ESRP signing process. If the ESRP service or the pipeline is compromised, there is no safeguard to ensure that the signed packages are legitimate and adhere to the expected policies.
Attack Vector: An attacker could tamper with the ESRP output or inject malicious packages into the pipeline, which would then be signed and published to NuGet.org.

Recommendation:

• Add a post-signing validation step to verify the integrity and authenticity of the signed NuGet packages. For example, use dotnet nuget verify to confirm that the package signature matches the expected certificate.
• Implement a checksum or hash validation mechanism to ensure that the signed packages have not been tampered with.

---

4. Supply Chain: Dependency on ESRP

Severity: 🔵 LOW
Issue: The pipeline introduces a dependency on the ESRP service for signing and publishing. While ESRP is a trusted Microsoft service, any downtime, misconfiguration, or compromise of ESRP could disrupt the pipeline or introduce vulnerabilities.
Attack Vector: If ESRP is unavailable or compromised, the pipeline could fail to publish signed packages, or worse, publish malicious packages signed with a compromised certificate.

Recommendation:

• Monitor ESRP service status and set up alerts for any disruptions.
• Implement a fallback mechanism to handle scenarios where ESRP is unavailable, such as delaying the release or using an alternative signing method.
• Periodically review ESRP's security practices and ensure they align with your organization's requirements.

---

Summary of Findings

Finding	Severity	Recommendation
Trust Chain Weakness: ESRP Configuration	🔴 CRITICAL	Validate managed identity permissions, monitor variable changes, and audit ESRP configuration.
Credential Exposure: Potential Leakage	🟠 HIGH	Mask sensitive variables in logs and verify no sensitive data is logged during ESRP execution.
Policy Engine Circumvention: No Validation	🟡 MEDIUM	Add post-signing validation to ensure package integrity and authenticity.
Supply Chain: Dependency on ESRP	🔵 LOW	Monitor ESRP service status and implement fallback mechanisms for signing and publishing.

---

Final Recommendation

This PR addresses a critical issue with unsigned NuGet packages, but it introduces new risks related to the ESRP integration. Before merging, ensure that the recommendations above are implemented to mitigate these risks.

[github-actions]

🤖 AI Agent: code-reviewer

Review Summary

This pull request addresses a critical issue where unsigned NuGet packages were being rejected by NuGet.org. The proposed solution replaces the raw dotnet nuget push command with the EsrpRelease@11 task, which handles both signing and publishing via ESRP (Extended Security Release Process). This change aligns with the existing pattern used for other package managers (PyPI, npm, crates.io) and ensures compliance with NuGet.org's signing requirements.

Below is a detailed review of the changes, focusing on correctness, security, and backward compatibility.

---

🔴 CRITICAL

1. Key Vault Misconfiguration Risk:

   • The keyvaultname and signcertname parameters are being passed as pipeline variables ($(ESRP_KEYVAULT_NAME) and $(ESRP_CERT_IDENTIFIER)), but there is no validation or fallback mechanism in case these variables are missing or misconfigured.
   • Impact: If these variables are not properly set, the ESRP task will fail, potentially causing a disruption in the CI/CD pipeline.
   • Recommendation: Add a pre-check step to validate that all required ESRP-related variables are set before invoking the EsrpRelease@11 task. Alternatively, provide default values or fail gracefully with a clear error message.

2. Credential Handling:

   • The clientid and domaintenantid are being passed as pipeline variables ($(ESRP_CLIENT_ID) and $(ESRP_DOMAIN_TENANT_ID)), but there is no explicit mention of how these secrets are being stored or accessed.
   • Impact: If these secrets are not securely stored (e.g., in Azure Key Vault or a secure secrets manager), they could be exposed, leading to a potential compromise of the ESRP signing process.
   • Recommendation: Ensure that all sensitive credentials are stored securely in a secrets manager and are accessed using secure mechanisms (e.g., Azure Key Vault integration). Document this in the pipeline configuration or README.

---

🟡 WARNING

1. Potential Breaking Change:
   • The switch from dotnet nuget push to EsrpRelease@11 introduces a dependency on ESRP for NuGet publishing. If ESRP is unavailable or misconfigured, the pipeline will fail.
   • Impact: This could break existing workflows that rely on the previous dotnet nuget push implementation.
   • Recommendation: Clearly communicate this change in the release notes and ensure that all teams using this pipeline are aware of the new ESRP dependency. Provide a fallback mechanism or a way to toggle between the old and new behavior if possible.

---

💡 SUGGESTIONS

1. Error Handling and Logging:

   • The EsrpRelease@11 task includes a waitforreleasecompletion parameter set to true. If the signing or publishing process fails, ensure that the pipeline logs provide sufficient details for debugging.
   • Recommendation: Add a step to capture and log detailed error messages from the ESRP task. This will help in diagnosing issues quickly.

2. Documentation Update:

   • The change introduces a new dependency on ESRP for NuGet publishing. However, there is no mention of this in the repository's documentation.
   • Recommendation: Update the repository's documentation (e.g., README or a dedicated CI/CD guide) to include details about the ESRP integration, required environment variables, and troubleshooting steps.

3. Test Coverage:

   • While this change addresses a CI/CD pipeline issue, it would be beneficial to add a test or validation step to ensure that the signed NuGet package meets the expected criteria (e.g., signature verification).
   • Recommendation: Consider adding a post-publish validation step to verify that the package is correctly signed and available on NuGet.org.

4. Consistency Across Pipelines:

   • The ESRP integration for NuGet should be consistent with the configurations used for PyPI, npm, and crates.io. While this change appears to align with those patterns, it would be prudent to review the other pipelines to ensure consistency in error handling, logging, and variable management.
   • Recommendation: Conduct a cross-pipeline review to ensure uniformity in ESRP usage and best practices.

---

Summary of Actionable Feedback

1. 🔴 CRITICAL: Add pre-checks to validate ESRP-related variables and ensure secure storage of credentials.
2. 🟡 WARNING: Communicate the potential breaking change due to the new ESRP dependency and consider adding a fallback mechanism.
3. 💡 SUGGESTION: Enhance error handling and logging for the EsrpRelease@11 task.
4. 💡 SUGGESTION: Update documentation to reflect the new ESRP integration and required configurations.
5. 💡 SUGGESTION: Add a post-publish validation step to verify the signed NuGet package.
6. 💡 SUGGESTION: Ensure consistency in ESRP integration across all package manager pipelines.

This PR addresses a critical issue effectively, but the above improvements will enhance its robustness, security, and usability.