> For the complete documentation index, see [llms.txt](https://docs.snyk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snyk.io/scan-fix-and-prevent/fix/prioritize-issues-for-fixing/assets-and-risk-factors/risk-factor-os-condition.md). # Risk factor: OS condition Some vulnerabilities have specific constraints that must be met for the problem to be exploitable. One such constraint is the operating system. Some vulnerabilities are exploitable only when the affected package is executing on a specific operating system, for example, Windows. Snyk can compare the vulnerability condition specified in the package with the operating system used by the runtime environment executing the package. ## Vulnerability OS conditions and risk factors If the vulnerability condition matches the operating system used by the runtime environment or if there is no condition, meaning that the vulnerability applies to all operating systems, the OS Condition risk factor is generated. | OS condition value | Runner OS value | Result | | ------------------ | --------------- | ---------------------- | | Any OS | Unknown | No risk factor | | Linux | Unknown | No risk factor | | Windows | Unkown | No risk factor | | Any OS | Linux | Risk factor identified | | Linux | Linux | Risk factor identified | | Windows | Linux | No risk factor | | Any OS | Windows | Risk factor identified | | Linux | Windows | No risk factor | | Windows | Windows | Risk factor identified | When an image is scanned by Snyk Container, the information about which operating system the base of the image is running on is exposed. Therefore, whenever Snyk Issues can determine that a package is a dependency of the image or that the package has been included in the image, it compares the vulnerability information with the image specification. The same applies to problems identified directly in the image entity. ## Kubernetes Connector integration The OS condition risk factor works with your [Kubernetes Connector](/scan-fix-and-prevent/fix/prioritize-issues-for-fixing/set-up-insights/set-up-insights-kubernetes-connector.md) integrations. The Kubernetes Connector leverages the OS condition risk factors to enhance the identification of vulnerabilities within containerized applications. It continuously checks and compares the operating systems of running containers with the known risk factors from the Snyk database. This integration helps to detect potentially vulnerable packages or images in real-time based on the operating system conditions. It allows proactive security measures within Kubernetes environments. ## Technical details for OS condition risk factor Every hour, the data pipeline takes a snapshot of all Snyk Projects and data sources and extrapolates packages and images. This snapshot determines which images and packages are known to Snyk for any customer. Snyk Project tags are used to enable the customer to relate image assets to packages. This information is extracted from the hourly data snapshot, and a basic composition graph is generated between images and packages. The data pipeline examines all the issues reported for the package and image and attempts to map the vulnerability condition between them. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.snyk.io/scan-fix-and-prevent/fix/prioritize-issues-for-fixing/assets-and-risk-factors/risk-factor-os-condition.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.