Skip to content

Latest commit

 

History

History
88 lines (69 loc) · 7.41 KB

mitigations.md

File metadata and controls

88 lines (69 loc) · 7.41 KB

Mitigation Strategies Analysis for gradleup/shadow

Mitigation Strategy: Careful Relocation Configuration

Description:

  1. Identify Conflicting Packages: Use tools or manual inspection to identify specific packages that are causing conflicts between different dependencies within the shadowed JAR.
  2. Minimize Relocation Scope: Relocate only the conflicting packages, not entire dependencies. This reduces the risk of unintended consequences and keeps the Shadow configuration as targeted as possible.
  3. Use Specific Rules: In your build.gradle.kts (or build.gradle), use Shadow's relocate directive with precise package names. Avoid wildcards unless absolutely necessary. Example: 
    shadowJar {
    relocate 'com.example.conflicting.package', 'com.yourproject.relocated.package'
}
  4. Thorough Testing: After relocation (and building the shadowed JAR), thoroughly test your application, paying close attention to areas that use the relocated classes. This testing is directly tied to the Shadow configuration.
  5. Documentation: Document each relocate rule within the build.gradle.kts (or next to it as a comment), explaining why it's necessary and what packages are affected. This is crucial for maintainability of the Shadow configuration.
  6. Avoid if possible: If it is possible try to solve conflicts by using never version of dependencies. This should be done before using relocation.

Threats Mitigated:

  • Dependency Conflict Leading to Unexpected Behavior (Medium Severity): Directly addresses this threat within the context of a shadowed JAR by resolving conflicts in a controlled manner.
  • Incorrect Relocation Breaking Functionality (Medium Severity): Minimizing the scope of relocation and thorough testing (specifically targeting the relocated code) reduce the risk of breaking functionality due to Shadow's actions.

Impact:

  • Dependency Conflict: High impact – resolves the conflict within the shadowed JAR.
  • Incorrect Relocation: Medium impact – reduces the risk of errors introduced by Shadow's relocation.

Currently Implemented:

  • Partially implemented. Some relocate rules exist in build.gradle.kts, but they are not comprehensively documented, and the testing after relocation (specifically focused on Shadow's changes) is not always rigorous.

Missing Implementation:

  • Comprehensive documentation of relocate rules within the build file is missing.
  • A standardized, rigorous testing process specifically for relocated code as a result of Shadow's configuration is not in place.

Mitigation Strategy: Explicit Dependency Inclusion/Exclusion (Shadow Filters)

Description:

  1. Identify Unnecessary Files: Analyze your dependencies and identify files or packages that are not needed at runtime within the context of the shadowed JAR (e.g., test code, documentation, sample code, specific resource files).
  2. Use include and exclude Filters: In your build.gradle.kts (or build.gradle), use Shadow's include and exclude filters directly within the shadowJar task configuration to control which files are included in the final JAR. Example: 
    shadowJar {
    exclude '**/test/**' // Exclude all files in test directories
    exclude 'META-INF/*.SF' // Exclude signature files
    include 'com/example/myproject/**' // Include only specific packages
    exclude '**/internal_implementation_details/**'
}
  3. Prioritize Exclusion: Focus on excluding files that are definitely not needed. It's generally safer to include something you might need than to exclude something you do need. This is a direct Shadow configuration decision.
  4. Regular Review: Review your include and exclude filters within the shadowJar task periodically to ensure they are still accurate. This is a Shadow-specific audit.

Threats Mitigated:

  • Vulnerability in Unused Code (within the Shadowed JAR) (High Severity): Reduces the risk of including vulnerable code that is not actually used by your application by directly controlling what Shadow packages.
  • Increased JAR Size (Low Severity): Reduces the size of the final shadowed JAR, improving deployment times and potentially performance. This is a direct consequence of Shadow's configuration.
  • Exposure of Unnecessary Information (Low Severity): Reduces the risk of exposing unnecessary information (e.g., test data, internal documentation) within the deployed shadowed artifact.

Impact:

  • Vulnerability in Unused Code: High impact – directly reduces the attack surface of the shadowed JAR.
  • Increased JAR Size: Low impact – improves deployment and performance.
  • Exposure of Unnecessary Information: Low impact – reduces the risk of information leakage from the shadowed JAR.

Currently Implemented:

  • Partially implemented. Some basic exclude filters are used in the shadowJar task in build.gradle.kts, but a comprehensive analysis of unnecessary files (specifically for Shadow's packaging) has not been performed.

Missing Implementation:

  • A systematic process for identifying and excluding unnecessary files specifically for the shadowed JAR is missing.
  • More granular include and exclude filters could be used within the shadowJar configuration.

Mitigation Strategy: Regular Audits of Shadow Configuration (Specifically shadowJar Task)

Description:

  1. Schedule Regular Reviews: Establish a schedule for reviewing your Shadow configuration within the shadowJar task (e.g., every sprint, every release, or quarterly).
  2. Check for Updates: Check for updates to the Shadow plugin itself. Newer versions might include security fixes or improved features related to how it packages dependencies.
  3. Review Relocation Rules: Re-examine your relocate rules within the shadowJar task (see "Careful Relocation Configuration").
  4. Review Include/Exclude Filters: Re-assess your include and exclude filters within the shadowJar task (see "Explicit Dependency Inclusion/Exclusion").
  5. Document Changes: Document any changes made to the Shadow configuration within the build file or alongside it, explaining the rationale. This ensures the shadowJar task remains understandable and maintainable.

Threats Mitigated:

  • Outdated Shadow Plugin (Medium Severity): Ensures you're using the latest version of the Shadow plugin, with any security fixes related to its core functionality.
  • Suboptimal Shadow Configuration (Medium Severity): Helps identify and correct any configuration issues within the shadowJar task that might have crept in over time, leading to security or functional problems.

Impact:

  • Outdated Shadow Plugin: Medium impact – reduces the risk of using a vulnerable plugin version.
  • Suboptimal Shadow Configuration: Medium impact – improves the overall security and maintainability of the Shadow-specific configuration.

Currently Implemented:

  • Not implemented.

Missing Implementation:

  • No formal process for regularly auditing the Shadow configuration specifically the shadowJar task and its directives is in place.