# Ensure Enforce Minimum Package Age of 60 Days Before Use

- Source: https://support.icompaas.com/support/solutions/articles/62000234957-ensure-enforce-minimum-package-age-of-60-days-before-use
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS GitHub Benchmark v1.0.0](https://support.icompaas.com/support/solutions/62000112695) › [CIS GitHub Benchmark v1.0.0](https://support.icompaas.com/support/solutions/folders/62000169264)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Profile Applicability:**  
Level 2

**Description:**  
All software packages or dependencies integrated into projects must be at least 60 days old from their initial release before they are allowed for use. This waiting period allows for initial vulnerabilities or critical bugs to be identified and resolved, reducing the risk of introducing unstable or insecure packages into the codebase.

**Rationale:**  
Newly released packages may contain undiscovered vulnerabilities or issues that could compromise software security or stability. Enforcing a minimum age policy helps ensure that only vetted, stable packages are used, minimizing supply chain risks and improving overall software quality.

**Impact:****Pros:**

-   Reduces exposure to unpatched vulnerabilities.  
      
    
-   Increases software stability and reliability.  
      
    
-   Supports risk management in dependency selection.  
      
    

**Cons:**

-   May delay adoption of new features or patches.  
      
    
-   Could limit availability of the latest package versions.  
      
    

**Default value:**  
Many organizations allow immediate use of newly released packages without age restrictions.

**Audit:**  
Review package version and release date metadata in project dependencies. Verify that no packages younger than 60 days are in use.

**Remediation:**  
Implement policies enforcing package age minimums. Integrate automated dependency scanning tools to flag packages violating the policy. Educate development teams on dependency risk management.

**References:**

1.  OWASP Dependency-Check: [https://owasp.org/www-project-dependency-check/](https://owasp.org/www-project-dependency-check/)
    
2.  The Update Framework (TUF): [https://theupdateframework.io/](https://theupdateframework.io/)
    
3.  CIS Controls v8, Control 4 - Secure Configuration of Enterprise Assets and Software: [https://www.cisecurity.org/controls/secure-configuration-of-enterprise-assets-and-software/](https://www.cisecurity.org/controls/secure-configuration-of-enterprise-assets-and-software/)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.