Skip to content

Latest commit

 

History

History
117 lines (88 loc) · 7.1 KB

mitigations.md

File metadata and controls

117 lines (88 loc) · 7.1 KB

Mitigation Strategies Analysis for lucasg/dependencies

Mitigation Strategy: Dependency Selection and Vetting

Mitigation Strategy: Choose Reputable Dependencies and Minimize Dependency Count

  • Description:

    1. Research: Before adding a dependency, research its reputation. Check its GitHub repository (stars, forks, issues, pull requests, last commit date). Look for signs of active maintenance and community engagement.
    2. Security Advisories: Search for known vulnerabilities in the dependency using resources like Snyk, OSV, and GitHub's security advisories.
    3. Alternatives: Consider alternative dependencies that might be more secure or better maintained.
    4. Necessity: Critically evaluate if the dependency is absolutely necessary. Could a small, in-house function achieve the same result?
    5. Documentation: Document the rationale for choosing a specific dependency, including the security considerations.

  • Threats Mitigated:

    • Vulnerabilities in Dependencies (Severity: High to Critical): Reduces the likelihood of introducing known vulnerabilities.
    • Malicious Dependencies (Severity: Critical): Reduces the chance of intentionally malicious code being included.
    • Outdated Dependencies (Severity: Medium to High): By favoring actively maintained dependencies, reduces the risk of using outdated versions.
    • Dependency Bloat (Severity: Medium): Reduces the overall attack surface.

  • Impact:

    • Vulnerabilities in Dependencies: Significantly reduces risk (e.g., 70-80% reduction).
    • Malicious Dependencies: Significantly reduces risk (e.g., 90% reduction).
    • Outdated Dependencies: Moderately reduces risk (e.g., 50% reduction).
    • Dependency Bloat: Directly reduces the attack surface.

  • Currently Implemented:

    • Basic research is performed before adding new dependencies (documented in pull request comments).
    • A list of preferred, commonly used dependencies is maintained.

  • Missing Implementation:

    • No systematic search for security advisories is performed before adding a dependency.
    • No documentation of the security rationale for choosing a dependency.

Mitigation Strategy: Dependency Updates and Patching

Mitigation Strategy: Regular Dependency Audits and Automated Updates (with Review)

  • Description:

    1. Automated Scanning: Integrate a dependency scanning tool (e.g., Snyk, Dependabot, Renovate) into the CI/CD pipeline. Configure it to run on every build and pull request.
    2. Update Tool: Use a tool like Dependabot or Renovate to automatically generate pull requests for dependency updates.
    3. Changelog Review: Review the changelog and release notes for the updated dependency to understand the changes and potential security fixes.
    4. Testing: Run the full test suite (unit, integration, end-to-end) after applying any dependency update.
    5. Emergency Patching: Define a documented procedure for quickly applying critical security patches, even if it means temporarily overriding dependency versions.

  • Threats Mitigated:

    • Vulnerabilities in Dependencies (Severity: High to Critical): Ensures timely patching of known vulnerabilities.
    • Outdated Dependencies (Severity: Medium to High): Keeps dependencies up-to-date.

  • Impact:

    • Vulnerabilities in Dependencies: Significantly reduces risk (e.g., 80-90% reduction).
    • Outdated Dependencies: Almost eliminates the risk (e.g., 95% reduction).

  • Currently Implemented:

    • Dependabot is enabled and generates pull requests for updates.
    • Basic unit tests are run after dependency updates.

  • Missing Implementation:

    • Integration and end-to-end tests are not consistently run after dependency updates.
    • No documented emergency patching procedure.
      • Snyk integration is not present in CI/CD.

Mitigation Strategy: Dependency Integrity and Supply Chain Security

Mitigation Strategy: Verify Dependency Integrity and Use a Private Dependency Proxy

  • Description:

    1. Checksum Verification: Ensure that the dependency management tool (and go.sum in the case of Go) automatically verifies checksums or signatures of downloaded dependencies.
    2. Proxy Setup: Set up a private dependency proxy (e.g., JFrog Artifactory, Sonatype Nexus). Configure the build system to use this proxy instead of public repositories.
    3. Proxy Configuration: Configure the proxy to:
      • Cache dependencies for faster and more reliable builds.
      • Allow only approved dependencies (whitelist).
      • Scan dependencies for vulnerabilities.
    4. Regular Audits: Regularly audit the proxy's configuration and logs.

  • Threats Mitigated:

    • Supply Chain Attacks (Severity: Critical): Protects against compromised repositories or man-in-the-middle attacks.
    • Dependency Confusion/Substitution (Severity: Critical): Prevents attackers from tricking the build system.
    • Malicious Dependencies (Severity: Critical): Adds an extra layer of defense.

  • Impact:

    • Supply Chain Attacks: Significantly reduces risk (e.g., 90-95% reduction).
    • Dependency Confusion/Substitution: Almost eliminates the risk (e.g., 99% reduction).
    • Malicious Dependencies: Moderately reduces risk (e.g., 50% reduction).

  • Currently Implemented:

    • go.sum is used, ensuring basic checksum verification for Go dependencies.

  • Missing Implementation:

    • No private dependency proxy is used.
    • No regular audits of dependency sources.

Mitigation Strategy: License Compliance

Mitigation Strategy: Automated License Scanning and Policy Enforcement

  • Description:

    1. Tool Selection: Choose a license scanning tool (e.g., FOSSA, ScanCode, LicenseFinder).
    2. Integration: Integrate the tool into the CI/CD pipeline to automatically scan dependencies on every build.
    3. Policy Definition: Define a clear license compliance policy, specifying allowed and disallowed licenses.
    4. Configuration: Configure the scanning tool to enforce the defined policy.
    5. Remediation: Establish a process for addressing license violations (e.g., replacing the dependency).
    6. Documentation: Document the license compliance policy and the process.

  • Threats Mitigated:

    • License Compliance Violations (Severity: Medium to High): Prevents the use of dependencies with incompatible licenses.

  • Impact:

    • License Compliance Violations: Significantly reduces risk (e.g., 90-95% reduction).

  • Currently Implemented:

    • None.

  • Missing Implementation:

    • No automated license scanning.
    • No defined license compliance policy.
    • No process for handling license violations.