We are committed to maintaining the security of Infrahub and its users. We deeply appreciate any effort to discover and responsibly disclose security vulnerabilities. This policy outlines the process for reporting security issues to our team.

• You think you discovered a potential security vulnerability in Infrahub
• You are unsure how a vulnerability affects Infrahub
• You think you discovered a vulnerability in another project that Infrahub depends on

• You need help configuring Infrahub security settings (such as external authentication)
• You need help applying security related updates
• Your issue is not security related

If you believe you have found a security vulnerability in Infrahub, please report it via our private and secure channels. Do not disclose the vulnerability publicly (e.g., on GitHub Issues, social media, or forums) until we publish the security advisory for it. This applies even when the fix is already visible in a public pull request.

1. Use the GitHub Security Advisory feature: This is the preferred method for reporting vulnerabilities. It provides a confidential channel for communication and automatically handles private disclosure.

   • Report a Vulnerability

2. Contact us via email (alternative): If you are unable to use the GitHub Advisory feature, you may send an email to opensource-security@opsmill.com.

To help us triage and resolve the issue as quickly as possible, please provide as much of the following information as you can:

• Vulnerability Summary: A brief, clear description of the vulnerability.
• Steps to Reproduce: Detailed, step-by-step instructions that allow us to replicate the issue.
• Affected Components:
  • The version, tag, or commit hash of the Infrahub source code.
  • Full path(s) of any relevant file(s).
• Configuration: Any specific configuration or environment settings required to reproduce the issue.
• Impact: Describe the potential impact of the vulnerability, including how an attacker could exploit it.
• Proof-of-Concept (PoC): If available, include a PoC or exploit code to demonstrate the issue.

We are committed to resolving security vulnerabilities in a timely and coordinated manner. Our general timeline for this process, based on industry best practices, is as follows:

1. Initial Triage (1-3 business days): We will acknowledge receipt of your report within this timeframe. Our team will perform an initial assessment to validate the vulnerability and determine its severity.
2. Patch Development (Time Varies): Once the vulnerability is confirmed, our engineering team will begin working on a fix. The time required for this step depends on the complexity of the issue. We will keep you updated on our progress.
3. Coordinated Disclosure (Typically 90 days): Upon the development of a patch or a solid mitigation strategy, we will work with you to coordinate a public disclosure. The standard industry timeline for this is 90 days from the initial report. This period allows us to ensure a fix is widely available before the vulnerability is made public. For High, Moderate, and Low vulnerabilities, the fix itself is public before it is released, as described in How We Prepare and Release Security Fixes below.
4. CVE Assignment: As part of the coordinated disclosure, we will request a Common Vulnerabilities and Exposures (CVE) identifier for the issue. The CVE ID provides a standardized name for the vulnerability, allowing for easier tracking and communication across the security community.

The severity we assign during triage decides where we prepare the fix for a vulnerability in the code of the public Infrahub repository, which Infrahub Community and Infrahub Enterprise both include:

• Critical: We prepare the fix in a private repository and add it to the public Infrahub repository at release time. Infrahub Community and Infrahub Enterprise receive the fix in the same release. We publish the security advisory after that release is available.
• High, Moderate, or Low: We prepare the fix in a public pull request in the Infrahub repository. The fix is visible to everyone before it is released and before we publish the security advisory.

At every severity, we publish the security advisory and request a CVE as described in the timeline above.

Code that ships only in Infrahub Enterprise is not public, so we fix vulnerabilities in it in a private repository at every severity. The fix ships in an Infrahub Enterprise release.

When a vulnerability in a third-party package that Infrahub depends on is already published, we update that package in a public pull request whatever its severity.

We credit the reporter of a vulnerability in its security advisory, unless they ask us not to. The reporter can be a person or an organization, including an organization that found the vulnerability with an automated tool. If the report has an ID from the reporter's own system, we add that ID to the advisory.