Skip to content

Latest commit

 

History

History
95 lines (66 loc) · 7.78 KB

mitigations.md

File metadata and controls

95 lines (66 loc) · 7.78 KB

Mitigation Strategies Analysis for square/leakcanary

Mitigation Strategy: Strict Debug Dependency Configuration

Mitigation Strategy: Strict Debug Dependency Configuration

  • Description:

    • Step 1: Open your project's build configuration file (e.g., build.gradle in Android projects using Gradle).
    • Step 2: Locate the dependency declaration for com.squareup.leakcanary:leakcanary-*.
    • Step 3: Ensure the dependency is declared using a debug-specific configuration keyword like debugImplementation (for Gradle in Android) or similar mechanism in your build system. This ensures LeakCanary is only included in debug build variants.
    • Step 4: Verify that release or production build variants do not include LeakCanary dependencies by explicitly checking the dependency configurations for those variants.
    • Step 5: Regularly review build files after dependency updates or changes to confirm this configuration is maintained for LeakCanary.

  • List of Threats Mitigated:

    • Accidental Inclusion of LeakCanary in Production Builds (High Severity): LeakCanary can expose sensitive memory details, class names, and potentially data snapshots in logs or UI if included in production. This could lead to information disclosure vulnerabilities specifically due to LeakCanary's functionality.

  • Impact:

    • High Risk Reduction: Effectively eliminates the threat of LeakCanary being present in production builds, thus preventing information disclosure through LeakCanary.

  • Currently Implemented:

    • Yes, implemented in project's build.gradle files (example for Android) by using debugImplementation for LeakCanary dependencies.

  • Missing Implementation:

    • N/A - Currently implemented in build configuration for LeakCanary.

Mitigation Strategy: Conditional LeakCanary Initialization in Code

Mitigation Strategy: Conditional LeakCanary Initialization in Code

  • Description:

    • Step 1: Locate the code where LeakCanary.install(this) or similar LeakCanary initialization is performed.
    • Step 2: Wrap the LeakCanary initialization code within a conditional statement that explicitly checks for a debug build flag, such as BuildConfig.DEBUG (Android) or equivalent environment/build system flags indicating a debug environment.
    • Step 3: Ensure the initialization code for LeakCanary only executes when the debug flag is true.
    • Step 4: Review initialization code during code reviews to confirm this conditional logic is in place and correctly implemented specifically for LeakCanary.

  • List of Threats Mitigated:

    • Accidental LeakCanary Initialization in Production (Medium Severity): Even if the LeakCanary dependency is somehow included in a production build (due to configuration error), this prevents LeakCanary from actually starting and functioning, reducing the risk of information exposure specifically from LeakCanary's runtime behavior.

  • Impact:

    • Medium Risk Reduction: Acts as a secondary safety net specifically for LeakCanary. While build configuration should prevent inclusion, this code-level check further reduces the risk of accidental LeakCanary activation in production.

  • Currently Implemented:

    • Yes, implemented in the Application class initialization code (example for Android) by wrapping LeakCanary.install() in a BuildConfig.DEBUG check.

  • Missing Implementation:

    • N/A - Currently implemented in application code for LeakCanary initialization.

Mitigation Strategy: Automated Build Verification for LeakCanary Absence in Production

Mitigation Strategy: Automated Build Verification for LeakCanary Absence in Production

  • Description:

    • Step 1: Integrate automated checks into your Continuous Integration/Continuous Deployment (CI/CD) pipeline.
    • Step 2: Implement a step in the CI/CD pipeline that analyzes the generated build artifacts (e.g., APK, AAB, JAR files for release builds) specifically for the absence of LeakCanary components.
    • Step 3: This automated check should specifically search for LeakCanary libraries or classes (e.g., by package name leakcanary, class names like LeakCanary) within the build artifact. Tools can be used to inspect dependencies or analyze compiled code.
    • Step 4: Configure the CI/CD pipeline to fail the build process if LeakCanary components are detected in release/production builds, ensuring no builds with LeakCanary are deployed.
    • Step 5: Regularly maintain and update these checks as dependencies or build processes evolve, specifically keeping LeakCanary in mind.

  • List of Threats Mitigated:

    • Accidental Inclusion of LeakCanary in Production Builds (High Severity): Provides an automated gate to catch errors in build configuration or dependency management that might lead to LeakCanary being included in production, preventing information disclosure due to LeakCanary.

  • Impact:

    • High Risk Reduction: Proactive detection and prevention of LeakCanary in production builds through automation, significantly reducing the risk of information disclosure specifically from LeakCanary.

  • Currently Implemented:

    • No, not currently implemented in the CI/CD pipeline specifically for LeakCanary detection.

  • Missing Implementation:

    • Missing in the project's CI/CD pipeline. Requires implementation of automated build artifact analysis specifically to detect LeakCanary presence.

Mitigation Strategy: Code Reviews Focused on LeakCanary Specific Usage

Mitigation Strategy: Code Reviews Focused on LeakCanary Specific Usage

  • Description:

    • Step 1: Incorporate specific checkpoints related to LeakCanary usage into the code review process.
    • Step 2: Train developers and code reviewers to specifically look for:
      • Correct debugImplementation dependency configuration for LeakCanary.
      • Conditional initialization of LeakCanary using debug flags.
      • Absence of any direct dependencies on LeakCanary classes in production code paths.
    • Step 3: Ensure code reviews are performed for all code changes, especially those related to dependency management, build configurations, and application initialization, with a focus on LeakCanary related changes.
    • Step 4: Maintain a checklist or guidelines for code reviewers to ensure consistent and thorough review of LeakCanary specific aspects.

  • List of Threats Mitigated:

    • Accidental Misconfiguration or Incorrect Usage of LeakCanary (Medium Severity): Human error in configuration or coding related to LeakCanary can lead to accidental inclusion or activation. Code reviews act as a manual verification step to catch these errors specifically related to LeakCanary.

  • Impact:

    • Medium Risk Reduction: Relies on human vigilance but provides a valuable layer of defense against configuration errors and incorrect usage patterns specifically for LeakCanary that automated checks might miss.

  • Currently Implemented:

    • Partially implemented. Code reviews are conducted, but specific focus on LeakCanary usage might not be consistently emphasized as a dedicated checkpoint.

  • Missing Implementation:

    • Requires formalization of LeakCanary-specific checkpoints within the code review process and training for reviewers to specifically look for these aspects related to LeakCanary.