Skip to content

Latest commit

 

History

History
119 lines (94 loc) · 8.35 KB

mitigations.md

File metadata and controls

119 lines (94 loc) · 8.35 KB

Mitigation Strategies Analysis for nuke-build/nuke

Mitigation Strategy: Package Source Verification and Dependency Pinning (NUKE and its Dependencies)

Description:

  1. Trusted NuGet Sources: In NuGet.Config, explicitly define trusted NuGet package sources. Prioritize private, secured feeds. For public feeds (nuget.org), use HTTPS.
  2. Pin NUKE Version: In the project file (.csproj) or Directory.Build.props, specify the exact version of the Nuke.Common (and any other NUKE-related) packages. Do not use version ranges or wildcards. This is crucial for preventing automatic upgrades to potentially compromised NUKE versions. Example: 
    <PackageReference Include="Nuke.Common" Version="7.0.1" />
  3. Pin Transitive Dependencies (Ideally): While harder, strive to pin all transitive dependencies, including those brought in by NUKE. This provides the strongest protection against supply chain attacks. Tools like Paket can help manage this.
  4. global.json: Pin .NET SDK version.

Threats Mitigated:

  • Compromised NUKE Packages (Severity: High): Directly mitigates the risk of using a malicious version of NUKE.
  • Compromised NUKE Dependencies (Severity: High): Reduces the risk of NUKE itself pulling in compromised dependencies.
  • Supply Chain Attacks (targeting NUKE) (Severity: High): A key defense against supply chain attacks specifically targeting the NUKE build system.

Impact:

  • Compromised NUKE Packages: Significantly reduces the risk.
  • Compromised NUKE Dependencies: Significantly reduces the risk.
  • Supply Chain Attacks (targeting NUKE): Significantly reduces the risk.

Currently Implemented:

  • NuGet.Config with trusted sources.
  • Nuke.Common version is pinned in .csproj.

Missing Implementation:

  • Transitive dependencies (including those of NUKE) are not fully pinned.
  • global.json is not used.

Mitigation Strategy: Mandatory Code Reviews for NUKE Build Definitions

Description:

  1. Policy Enforcement: Enforce a strict policy requiring code reviews for all changes to NUKE build definition files (e.g., Build.cs, any .cs files defining targets or parameters).
  2. Pull Request Workflow: Use a pull request (PR) or merge request (MR) system. No changes to build scripts are merged without review.
  3. Security-Focused Review (NUKE-Specific): Reviewers must specifically check for:
    • Safe use of NUKE's features: Correct usage of [Parameter] attributes, proper handling of secrets passed to NUKE, safe execution of external tools via NUKE's helpers (e.g., DotNet, Npm, etc.).
    • Avoidance of risky patterns: Look for any code that might be constructing commands dynamically from user input or external data, which could lead to injection vulnerabilities within the NUKE script.
    • Proper secret handling: Ensure secrets are not hardcoded and are retrieved securely (see the next mitigation strategy).
  4. Multiple Reviewers (Recommended): For critical build definitions, require multiple reviewers, including someone with security expertise.

Threats Mitigated:

  • Malicious NUKE Build Scripts (Severity: High): Reduces the risk of intentionally malicious code within the NUKE definition.
  • Inadvertent Security Flaws in NUKE Scripts (Severity: Medium-High): Helps catch unintentional vulnerabilities introduced through misuse of NUKE's features.
  • Insider Threats (affecting NUKE scripts) (Severity: High): Mitigates the risk of a malicious insider modifying the NUKE build.

Impact:

  • Malicious NUKE Build Scripts: Significantly reduces the risk.
  • Inadvertent Security Flaws in NUKE Scripts: Moderately reduces the risk.
  • Insider Threats (affecting NUKE scripts): Significantly reduces the risk.

Currently Implemented:

  • Pull requests are required for all code changes.

Missing Implementation:

  • The code review policy doesn't explicitly highlight NUKE-specific security concerns.
  • Multiple reviewers are not required for NUKE build script changes.

Mitigation Strategy: Secure Secret Handling within NUKE

Description:

  1. Avoid Hardcoding: Never hardcode secrets directly in the NUKE build definition files.
  2. Use External Secret Store: Use a secure secret management solution (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, or the CI/CD system's built-in secrets).
  3. Secure Retrieval: Within the NUKE script, use the appropriate client library or mechanism to retrieve secrets from the secret store at runtime. Do not store secrets in environment variables unless those variables are securely managed by the CI/CD system and are not logged.
  4. NUKE Parameter Injection (with extreme caution): NUKE's [Parameter] attribute can be used to inject secrets, but only if the CI/CD system securely provides these parameters and they are never logged or persisted. This is generally less secure than using a dedicated secret store. Example (use with caution): 
    [Parameter("API key for service X")]
readonly string MyApiKey;
  5. Least Privilege (within NUKE): Ensure the NUKE build process only has access to the secrets it absolutely needs.
  6. Avoid logging secrets: Ensure that secrets are never printed to the console or build logs.

Threats Mitigated:

  • Secrets Exposure in NUKE Scripts (Severity: High): Prevents secrets from being exposed in the build definition.
  • Credential Theft (from NUKE context) (Severity: High): Reduces the risk of attackers stealing credentials used by the NUKE build.
  • Unauthorized Access (via NUKE) (Severity: High): Prevents unauthorized access to resources if NUKE's secrets are compromised.

Impact:

  • Secrets Exposure in NUKE Scripts: Significantly reduces the risk.
  • Credential Theft (from NUKE context): Significantly reduces the risk.
  • Unauthorized Access (via NUKE): Significantly reduces the risk.

Currently Implemented:

  • The project uses Azure Key Vault.
  • NUKE retrieves secrets from Azure Key Vault at runtime.

Missing Implementation:

  • The principle of least privilege is not fully enforced within the NUKE script's access to secrets.

Mitigation Strategy: Safe External Command Execution via NUKE

Description:

  1. Prefer NUKE's Tool Helpers: Use NUKE's built-in helpers for common tools (e.g., DotNet, Npm, Git, etc.) whenever possible. These helpers often provide safer ways to execute commands. Example: 
    DotNetBuild(s => s
    .SetProjectFile(Solution)
    .SetConfiguration(Configuration)
);
  2. Parameterized Commands (Always): If you must use Process.Start directly within the NUKE script, always use parameterized commands (with ProcessStartInfo) to prevent command injection. Never build commands by concatenating strings with untrusted input.
  3. Input Validation/Sanitization (for NUKE inputs): If command arguments are derived from NUKE parameters (e.g., [Parameter]) or other potentially untrusted sources, rigorously validate and sanitize the input before using it in any command.
  4. Whitelisting (if possible): If you have a limited set of external commands that NUKE needs to execute, consider maintaining a whitelist.

Threats Mitigated:

  • Command Injection (via NUKE) (Severity: High): Prevents attackers from injecting malicious code into commands executed by NUKE.
  • Unintended Code Execution (within NUKE) (Severity: Medium-High): Reduces the risk of NUKE unintentionally executing harmful commands.

Impact:

  • Command Injection (via NUKE): Significantly reduces the risk (with proper parameterization).
  • Unintended Code Execution (within NUKE): Moderately reduces the risk.

Currently Implemented:

  • The NUKE script primarily uses NUKE's built-in tool helpers.

Missing Implementation:

  • There are still a few places where Process.Start is used directly, and not all of them are fully parameterized.
  • Input validation for NUKE parameters used in commands is not consistently applied.