Skip to content

Latest commit

 

History

History
141 lines (110 loc) · 10.8 KB

mitigations.md

File metadata and controls

141 lines (110 loc) · 10.8 KB

Mitigation Strategies Analysis for yarnpkg/berry

Mitigation Strategy: Code Review and Integrity Checks for PnP Files

  • Description:

    1. Establish a Policy: Mandate manual review of any changes to .yarn/cache, pnp.cjs, and .pnp.data.json. This is crucial because these files control package resolution in Berry.
    2. Automated Detection (Pre-Commit Hook): Use a pre-commit hook (e.g., Husky) to flag changes to these files, preventing accidental commits of malicious modifications.
    3. Manual Inspection: Reviewers should:
      • Diff Analysis: Carefully examine the diff of pnp.cjs and .pnp.data.json. Look for unexpected additions/removals/modifications of package mappings, paying close attention to paths and versions.
      • Contextual Understanding: Understand why a mapping was changed. Does it align with intended functionality?
      • Cross-Reference: Compare changes in PnP files with package.json and yarn.lock for consistency.
    4. Documentation: Changes to PnP files must be documented in commit messages and pull requests.
    5. Regular expression validation: Add validation of pnp.cjs and .pnp.data.json content using regular expressions. This validation should be part of pre-commit hook.

  • List of Threats Mitigated:

    • Malicious Package Redirection (High Severity): Prevents attackers from silently redirecting package resolution to compromised code without altering package.json or yarn.lock. This is unique to Yarn Berry's PnP.
    • Accidental Misconfiguration (Medium Severity): Reduces errors in PnP files that could break builds.
    • Supply Chain Attacks (via Cache Poisoning) (High Severity): Makes it harder to exploit a compromised package in the cache by manipulating PnP files (though not a complete solution).

  • Impact:

    • Malicious Package Redirection: Significantly reduces risk; manual review makes it much harder for malicious code to go unnoticed.
    • Accidental Misconfiguration: Reduces risk considerably; pre-commit hooks and reviews catch errors early.
    • Supply Chain Attacks (via Cache Poisoning): Provides a layer of defense, but other mitigations are needed.

  • Currently Implemented:

    • Example: Pre-commit hook in .husky/pre-commit. Code review policy in docs/development/code_review.md.

  • Missing Implementation:

    • Example: Automated diff analysis tool specifically for pnp.cjs is not implemented. Relying on manual diff review. Regular expression validation is not implemented.

Mitigation Strategy: Plugin Auditing and Pinning

  • Description:

    1. Plugin Inventory: Maintain a list of all Yarn plugins, including purpose, source, and version.
    2. Vetting Process: Before installing any plugin:
      • Source Code Review: Examine the plugin's source code (if available) for suspicious patterns.
      • Maintainer Reputation: Research the plugin's maintainer. Are they known and trusted?
      • Issue Tracker: Check for reported security issues.
      • Alternatives: Consider if there are more established plugins that do the same thing.
    3. Pinning: Use the @ syntax in yarn plugin import to specify a precise version: yarn plugin import https://example.com/[email protected]. Do not use version ranges. This is critical for plugins.
    4. Regular Review: Periodically review installed plugins and versions. Check for updates and advisories.
    5. Documentation: Document the rationale for choosing each plugin and its pinned version.

  • List of Threats Mitigated:

    • Malicious Plugin Execution (High Severity): Prevents installation/execution of plugins with malicious code. This is specific to Yarn's plugin architecture.
    • Vulnerable Plugin Exploitation (High Severity): Reduces risk of exploiting known vulnerabilities in outdated plugins.
    • Unintentional Functionality Changes (Medium Severity): Pinning prevents unexpected changes in plugin behavior.

  • Impact:

    • Malicious Plugin Execution: Significantly reduces risk by requiring vetting and preventing untrusted plugins.
    • Vulnerable Plugin Exploitation: Reduces risk by ensuring only specific, known-good versions are used.
    • Unintentional Functionality Changes: Eliminates risk of unexpected behavior changes from updates.

  • Currently Implemented:

    • Example: Plugin inventory in docs/development/yarn_plugins.md. Plugins pinned in .yarnrc.yml.

  • Missing Implementation:

    • Example: Automated vulnerability scanning for Yarn plugins is not implemented. Relying on manual checks.

Mitigation Strategy: Immutable Infrastructure for CI/CD and Production (Focus on .yarn/cache)

  • Description:

    1. Containerization: Use Docker (or similar).
    2. Build Stage: In the Dockerfile:
      • Install Yarn Berry.
      • Run yarn install to populate .yarn/cache and generate PnP files. This is the key step for Berry.
      • Build the application.
    3. Runtime Stage:
      • Copy only necessary artifacts (including the built app, .yarn/cache, and PnP files) from the build stage.
      • Run the application. Do not run yarn install here.
    4. Immutable Image: Treat the Docker image as immutable after building.
    5. CI/CD Pipeline: Integrate this into the CI/CD pipeline. Each deployment uses a fresh, immutable image.
    6. Production Environment: Ensure production only runs these immutable images. Prevent modifications to the running container. The critical point is that the .yarn/cache is fixed at build time.

  • List of Threats Mitigated:

    • Runtime Tampering (High Severity): Prevents modifying the app, dependencies, or PnP files after deployment.
    • Cache Poisoning (in Production) (High Severity): Prevents exploiting a compromised package in the cache to inject code into the running application. This is directly relevant to Berry's offline cache.
    • Inconsistent Environments (Medium Severity): Ensures production is identical to the tested environment.

  • Impact:

    • Runtime Tampering: Eliminates the risk of runtime modifications.
    • Cache Poisoning (in Production): Significantly reduces risk by preventing modifications to the cache after the image is built.
    • Inconsistent Environments: Eliminates environment discrepancies.

  • Currently Implemented:

    • Example: Dockerfile in Dockerfile. CI/CD pipeline in gitlab-ci.yml builds/deploys immutable images.

  • Missing Implementation:

    • Example: Kubernetes deployment doesn't enforce immutability of running pods (e.g., read-only root filesystems).

Mitigation Strategy: Updated Tooling and Yarn-Specific Commands (Focus on Berry Compatibility)

  • Description:

    1. Dependency Analysis: Use yarn outdated, yarn why, and yarn audit. Do not rely on tools that parse the old yarn.lock format. This is essential for Berry.
    2. Vulnerability Scanning: Use scanners specifically designed for Yarn Berry (e.g., Snyk, Dependabot). Ensure they understand the yarn.lock and PnP.
    3. License Compliance: Use tools compatible with Yarn Berry for license checks.
    4. Regular Updates: Keep all tools updated to ensure compatibility with the latest Yarn Berry features and security fixes.
    5. Training: Train developers to use Yarn-specific commands.

  • List of Threats Mitigated:

    • Missed Vulnerabilities (High Severity): Ensures vulnerability scanners correctly identify vulnerabilities in dependencies managed by Yarn Berry (due to its different lockfile and PnP).
    • Incorrect Dependency Information (Medium Severity): Prevents reliance on outdated information.
    • License Violations (Medium Severity): Ensures accurate license compliance checks.

  • Impact:

    • Missed Vulnerabilities: Significantly reduces risk of deploying apps with known vulnerabilities.
    • Incorrect Dependency Information: Eliminates risk of relying on inaccurate data.
    • License Violations: Reduces risk of legal issues.

  • Currently Implemented:

    • Example: Snyk integrated into CI/CD. Developers use yarn audit and yarn outdated.

  • Missing Implementation:

    • Example: Automated license compliance checks are not fully integrated into CI/CD.

Mitigation Strategy: Workspace Isolation and Management (Yarn Workspaces Specific)

  • Description:

    1. Independent Audits: Treat each workspace as a separate entity for security auditing. Conduct independent vulnerability scans and code reviews.
    2. Dependency Definition: Explicitly define dependencies between workspaces in package.json using the workspace: protocol. Avoid implicit or wildcard dependencies. This is key to managing workspace relationships in Yarn.
    3. Circular Dependency Check: Regularly check for and eliminate circular dependencies between workspaces (e.g., using madge).
    4. Build Isolation (Ideal): If possible, build each workspace in a separate container/environment to prevent cross-contamination.
    5. Access Control: If using a monorepo with multiple teams, restrict write access to specific workspaces based on team responsibilities.
    6. Documentation: Document dependencies and relationships between workspaces.

  • List of Threats Mitigated:

    • Cross-Workspace Contamination (High Severity): Prevents a vulnerability in one workspace from affecting others. This is specific to how Yarn Workspaces manage dependencies.
    • Unintended Dependency Conflicts (Medium Severity): Reduces conflicts between dependencies in different workspaces.
    • Unauthorized Code Modification (Medium Severity): Limits the impact of unauthorized access.

  • Impact:

    • Cross-Workspace Contamination: Significantly reduces risk of cascading failures.
    • Unintended Dependency Conflicts: Reduces build failures and runtime errors.
    • Unauthorized Code Modification: Limits the scope of potential damage.

  • Currently Implemented:

    • Example: Dependencies between workspaces are explicitly defined. Circular dependency checks are run periodically.

  • Missing Implementation:

    • Example: Build isolation for each workspace is not implemented. Access control based on workspaces is not enforced.