# Ensure Mandate SECURITY.md File in Public Repositories

- Source: https://support.icompaas.com/support/solutions/articles/62000235212-ensure-mandate-security-md-file-in-public-repositories
- 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 1**

**Description**:  
 Every public repository must include a SECURITY.md file that outlines the project's security policies, vulnerability reporting guidelines, and responsible disclosure processes. This file provides clear instructions to users and security researchers on how to report security issues, thereby improving transparency and responsiveness to potential vulnerabilities.

**Rationale**:  
 Including a SECURITY.md file fosters effective communication regarding security concerns and encourages responsible vulnerability disclosure. It enhances trust within the user community and demonstrates a commitment to maintaining the security posture of the project.

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

-   Improves security awareness and communication.  
      
    
-   Encourages responsible reporting of vulnerabilities.  
      
    
-   Builds user and contributor confidence.  
      
    

**Cons**:

-   Requires maintenance to keep security policies current.  
      
    
-   May necessitate dedicated resources to handle security reports.  
      
    

**Default value:  
** Many public repositories do not have a SECURITY.md file by default, which can lead to unclear reporting channels for security issues.

**Audit**:  
 Verify that all public repositories contain a SECURITY.md file located in the root directory. Review the file to ensure it clearly defines security policies and reporting procedures.

**Remediation:  
** Create and maintain a SECURITY.md file in the root of each public repository using standard templates, such as those recommended by GitHub. Customize the file to specify the project’s security contact information, vulnerability reporting process, and any relevant security policies. Ensure the file remains up to date and accessible.

**References**:

1.  GitHub Documentation – About Security Policies: [https://docs.github.com/en/code-security/security-policy-framework/about-security-policies](https://docs.github.com/en/code-security/security-policy-framework/about-security-policies)
    
2.  OWASP – Responsible Disclosure Guidelines: [https://owasp.org/www-community/Responsible\_Disclosure](https://owasp.org/www-community/Responsible_Disclosure)
    
3.  CIS Controls v8, Control 16 – Application Software Security: [https://www.cisecurity.org/controls/application-software-security/](https://www.cisecurity.org/controls/application-software-security/)

## 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.