chore: update security policy (#222)

Makefile

@@ -33,10 +33,20 @@ test: .bin/shellcheck .bin/shfmt node_modules  # runs all linters
 	touch .bin/shellcheck   # update the timestamp so that Make doesn't re-install the file over and over again
 
 .bin/shfmt: Makefile
-	echo installing Shellfmt ...
+	echo "Installing Shellfmt ..."
 	mkdir -p .bin
-	curl -sSL https://github.com/mvdan/sh/releases/download/v3.5.1/shfmt_v3.5.1_linux_amd64 -o .bin/shfmt
+	if [ "$$(uname -s)" = "Darwin" ] && [ "$$(uname -m)" = "arm64" ]; then \
+		echo " - detected macOS ARM64"; \
+		curl -sSL https://github.com/mvdan/sh/releases/download/v3.9.0/shfmt_v3.9.0_darwin_arm64 -o .bin/shfmt; \
+	elif [ "$$(uname -s)" = "Linux" ] && [ "$$(uname -m)" = "x86_64" ]; then \
+		echo " - detected Linux AMD64"; \
+		curl -sSL https://github.com/mvdan/sh/releases/download/v3.9.0/shfmt_v3.9.0_linux_amd64 -o .bin/shfmt; \
+	else \
+		echo " - unsupported architecture: $$(uname -s) $$(uname -m)"; \
+		exit 1; \
+	fi
 	chmod +x .bin/shfmt
+	touch .bin/shfmt 
 
 node_modules: package.json package-lock.json
 	echo installing Node dependencies ...

SECURITY.md

@@ -1,27 +1,43 @@
-<!-- START doctoc generated TOC please keep comment here to allow auto update -->
-<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+# Ory Security Policy
 
-- [Security Policy](#security-policy)
-  - [Supported Versions](#supported-versions)
-  - [Reporting a Vulnerability](#reporting-a-vulnerability)
+## Overview
 
-<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+This security policy outlines the security support commitments for different
+types of Ory users.
 
-# Security Policy
+## Apache 2.0 License Users
 
-## Supported Versions
+- **Security SLA:** No security Service Level Agreement (SLA) is provided.
+- **Release Schedule:** Releases are planned every 3 to 6 months. These releases will contain all security fixes implemented up to that point.
+- **Version Support:** Security patches are only provided for the current release version.
 
-We release patches for security vulnerabilities. Which versions are eligible
-receiving such patches depend on the CVSS v3.0 Rating:
+## Ory Enterprise License Customers
 
-| CVSS v3.0 | Supported Versions                        |
-| --------- | ----------------------------------------- |
-| 9.0-10.0  | Releases within the previous three months |
-| 4.0-8.9   | Most recent release                       |
+- **Security SLA:** The following timelines apply for security vulnerabilities based on their severity:
+  - Critical: Resolved within 14 days.
+  - High: Resolved within 30 days.
+  - Medium: Resolved within 90 days.
+  - Low: Resolved within 180 days.
+  - Informational: Addressed as needed.
+- **Release Schedule:** Updates are provided as soon as vulnerabilities are resolved, adhering to the above SLA.
+- **Version Support:** Depending on the Ory Enterprise License agreement multiple versions can be supported.
+
+## Ory Network Users
+
+- **Security SLA:** The following timelines apply for security vulnerabilities based on their severity:
+  - Critical: Resolved within 14 days.
+  - High: Resolved within 30 days.
+  - Medium: Resolved within 90 days.
+  - Low: Resolved within 180 days.
+  - Informational: Addressed as needed.
+- **Release Schedule:** Updates are automatically deployed to Ory Network as soon as vulnerabilities are resolved, adhering to the above SLA.
+- **Version Support:** Ory Network always runs the most current version.
+
+[Get in touch](https://www.ory.sh/contact/) to learn more about Ory's security SLAs and process.
 
 ## Reporting a Vulnerability
 
-Please report (suspected) security vulnerabilities to
-**[security@ory.sh](mailto:security@ory.sh)**. You will receive a response from
-us within 48 hours. If the issue is confirmed, we will release a patch as soon
-as possible depending on complexity but historically within a few days.
+If you suspect a security vulnerability, please report it to
+**[security@ory.sh](mailto:security@ory.sh)**. We will respond within 48 hours.
+If confirmed, we will work to release a patch as soon as possible, typically
+within a few days depending on the issue's complexity.

templates/repository/common/.github/ISSUE_TEMPLATE/BUG-REPORT.yml

@@ -24,7 +24,9 @@ body:
     id: checklist
     type: checkboxes
   - attributes:
-      description: "Enter the slug or API URL of the affected Ory Network project. Leave empty when you are self-hosting."
+      description:
+        "Enter the slug or API URL of the affected Ory Network project. Leave
+        empty when you are self-hosting."
       label: "Ory Network Project"
       placeholder: "https://<your-project-slug>.projects.oryapis.com"
     id: ory-network-project

templates/repository/common/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml

@@ -34,7 +34,9 @@ body:
     id: checklist
     type: checkboxes
   - attributes:
-      description: "Enter the slug or API URL of the affected Ory Network project. Leave empty when you are self-hosting."
+      description:
+        "Enter the slug or API URL of the affected Ory Network project. Leave
+        empty when you are self-hosting."
       label: "Ory Network Project"
       placeholder: "https://<your-project-slug>.projects.oryapis.com"
     id: ory-network-project

templates/repository/common/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml

@@ -27,7 +27,9 @@ body:
     id: checklist
     type: checkboxes
   - attributes:
-      description: "Enter the slug or API URL of the affected Ory Network project. Leave empty when you are self-hosting."
+      description:
+        "Enter the slug or API URL of the affected Ory Network project. Leave
+        empty when you are self-hosting."
       label: "Ory Network Project"
       placeholder: "https://<your-project-slug>.projects.oryapis.com"
     id: ory-network-project

templates/repository/common/ADOPTERS.md

@@ -1,10 +1,12 @@
 <!--BEGIN ADOPTERS-->
 
 The Ory community stands on the shoulders of individuals, companies, and
-maintainers. The Ory team thanks everyone involved - from submitting bug reports and
-feature requests, to contributing patches and documentation. The Ory community
-counts more than 33.000 members and is growing rapidly. The Ory stack protects 60.000.000.000+ API
-requests every month with over 400.000+ active service nodes. None of this would have been possible without each and everyone of you!
+maintainers. The Ory team thanks everyone involved - from submitting bug reports
+and feature requests, to contributing patches and documentation. The Ory
+community counts more than 33.000 members and is growing rapidly. The Ory stack
+protects 60.000.000.000+ API requests every month with over 400.000+ active
+service nodes. None of this would have been possible without each and everyone
+of you!
 
 The following list represents companies that have accompanied us along the way
 and that have made outstanding contributions to our ecosystem. _If you think

templates/repository/common/CODE_OF_CONDUCT.md

@@ -38,8 +38,13 @@ Examples of unacceptable behavior include:
 
 ## Open Source Community Support
 
-Ory Open source software is collaborative and based on contributions by developers in the Ory community. There is no obligation from Ory to help with individual problems.
-If Ory open source software is used in production in a for-profit company or enterprise environment, we mandate a paid support contract where Ory is obligated under their service level agreements (SLAs) to offer a defined level of availability and responsibility. For more information about paid support please contact us at sales@ory.sh.
+Ory Open source software is collaborative and based on contributions by
+developers in the Ory community. There is no obligation from Ory to help with
+individual problems. If Ory open source software is used in production in a
+for-profit company or enterprise environment, we mandate a paid support contract
+where Ory is obligated under their service level agreements (SLAs) to offer a
+defined level of availability and responsibility. For more information about
+paid support please contact us at sales@ory.sh.
 
 ## Enforcement Responsibilities
 

templates/repository/common/CONTRIBUTING.md

@@ -144,7 +144,9 @@ checklist to contribute an example:
 1. Add a descriptive prefix to commits. This ensures a uniform commit history
    and helps structure the changelog. Please refer to this
    [Convential Commits configuration](https://github.com/$REPOSITORY/blob/master/.github/workflows/conventional_commits.yml)
-   for the list of accepted prefixes. You can read more about the Conventional Commit specification [at their site](https://www.conventionalcommits.org/en/v1.0.0/).
+   for the list of accepted prefixes. You can read more about the Conventional
+   Commit specification
+   [at their site](https://www.conventionalcommits.org/en/v1.0.0/).
 1. Create a `README.md` that explains how to use the example. (Use
    [the README template](https://github.com/ory/examples/blob/master/_common/README.md)).
 1. Open a pull request and maintainers will review and merge your example.
@@ -172,7 +174,9 @@ request, go through this checklist:
 1. Add a descriptive prefix to commits. This ensures a uniform commit history
    and helps structure the changelog. Please refer to this
    [Convential Commits configuration](https://github.com/$REPOSITORY/blob/master/.github/workflows/conventional_commits.yml)
-   for the list of accepted prefixes. You can read more about the Conventional Commit specification [at their site](https://www.conventionalcommits.org/en/v1.0.0/).
+   for the list of accepted prefixes. You can read more about the Conventional
+   Commit specification
+   [at their site](https://www.conventionalcommits.org/en/v1.0.0/).
 
 If a pull request is not ready to be reviewed yet
 [it should be marked as a "Draft"](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request).