Update security process

Signed-off-by: Sascha Grunert <[email protected]>

README.md

@@ -93,6 +93,10 @@ Note that kpod and its container management and debugging commands have moved to
 | [registries.conf(5)](https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md) | Registries Configuration file         |
 | [storage.conf(5)](https://github.com/containers/storage/blob/main/docs/containers-storage.conf.5.md)     | Storage Configuration file            |
 
+## Security
+
+The security process for reporting vulnerabilities is described in [SECURITY.md](./SECURITY.md).
+
 ## OCI Hooks Support
 
 [You can configure CRI-O][podman-hooks] to inject [OCI Hooks][spec-hooks] when creating containers.

SECURITY.md

@@ -1,14 +1,33 @@
-## Report a Vulnerability
+# CRI-O Security
+
+CRI-O is used in production across many industries that rely on a stable and
+secure container runtime for critical infrastructure. Security is taken
+seriously and has high priority across all related projects to ensure users can
+trust CRI-O for their systems. This means that not only vulnerabilities for this
+project, but also for depending ones can be reported through our process, for
+example if a vulnerability affects [conmon][conmon] or [conmon-rs][conmon-rs].
+
+[conmon]: https://github.com/containers/conmon
+[conmon-rs]: https://github.com/containers/conmon-rs
 
 We're extremely grateful for security researchers and users that report
 vulnerabilities to the CRI-O community. All reports are thoroughly investigated
 by a set of community volunteers.
 
-To make a report, email your vulnerability to the private
+## Report a Vulnerability
+
+To make a report, email the vulnerability to the private
 [[email protected]](mailto:[email protected]) list
 with the security details and the details expected for [all CRI-O bug
 reports](https://github.com/cri-o/cri-o/blob/main/.github/ISSUE_TEMPLATE/bug-report.yml).
 
+You can expect an initial response to the report within 3 business days.
+Possible fixes for vulnerabilities will be then discussed via the mail thread
+and can be considered as automatically embargoed until they got merged into all
+related branches. A project approver or reviewer (as defined in the
+[OWNERS](./OWNERS) file) will coordinate how the pull requests and patches are
+being incorporated into the repository without breaking the embargo.
+
 ### When Should I Report a Vulnerability?
 
 - You think you discovered a potential security vulnerability in CRI-O