Document response times, supported versions, access, secrets, and dependency policies (#5580)

Answer the OpenSSF Best Practices criteria that asked for policies the
project follows but had not written down:

- SECURITY.md: a first response within 14 days, publishing an advisory
  with credit once a fix is released, and that only the latest release
  receives security fixes.
- Governance: who has access to the project's resources, how write or
  admin access is granted, and how CI secrets are stored and rotated.
- Quality assurance: how dependencies of the build, test, and
  documentation tooling are pinned, scanned, and kept free of known
  vulnerabilities.

Also update the assurance case, since comparison no longer recurses per
nesting level (#5390), and point the best practices badge and links to
bestpractices.dev under the program's current name.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

.github/SECURITY.md

@@ -9,12 +9,23 @@ identified a security vulnerability in this repository, please use the GitHub Se
 Until it is published, this draft security advisory will only be visible to the maintainers of this project. Other
 users and teams may be added once the advisory is created.
 
-We will send a response indicating the next steps in handling your report. After the initial reply to your report, we
-will keep you informed of the progress towards a fix and full announcement and may ask for additional information or
-guidance.
+We will send a first response within 14 days, indicating the next steps in handling your report. After the initial
+reply to your report, we will keep you informed of the progress towards a fix and full announcement and may ask for
+additional information or guidance.
 
 For vulnerabilities in third-party dependencies or modules, please report them directly to the respective maintainers.
 
+## Disclosure and credit
+
+Once a fix is released, we publish the security advisory and list the fixed vulnerability in the release notes. We
+credit the reporter in both, unless they ask not to be named.
+
+## Supported versions
+
+Security fixes are made on the `develop` branch and shipped with the next release. Only the latest release receives
+security fixes; they are not backported to older releases. A release stops receiving security fixes when the next
+release is published, so please update to the latest release to get them.
+
 ## Unofficial packages
 
 This project does not publish an official npm package. The npm package

README.md

@@ -17,7 +17,7 @@
 [![GitHub Downloads](https://img.shields.io/github/downloads/nlohmann/json/total)](https://github.com/nlohmann/json/releases)
 [![GitHub Issues](https://img.shields.io/github/issues/nlohmann/json.svg)](https://github.com/nlohmann/json/issues)
 [![Average time to resolve an issue](https://isitmaintained.com/badge/resolution/nlohmann/json.svg)](https://isitmaintained.com/project/nlohmann/json "Average time to resolve an issue")
-[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/289/badge)](https://bestpractices.coreinfrastructure.org/projects/289)
+[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/289/badge)](https://www.bestpractices.dev/projects/289)
 [![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/nlohmann/json/badge)](https://scorecard.dev/viewer/?uri=github.com/nlohmann/json)
 [![Backup Status](https://app.cloudback.it/badge/nlohmann/json)](https://cloudback.it)
 [![GitHub Sponsors](https://img.shields.io/badge/GitHub-Sponsors-ff69b4)](https://github.com/sponsors/nlohmann)
@@ -63,7 +63,7 @@ There are myriads of [JSON](https://json.org) libraries out there, and each may
 
 - **Trivial integration**. Our whole code consists of a single header file [`json.hpp`](https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp). That's it. No library, no subproject, no dependencies, no complex build system. The class is written in vanilla C++11. All in all, everything should require no adjustment of your compiler flags or project settings. The library is also included in all popular [package managers](https://json.nlohmann.me/integration/package_managers/).
 
-- **Serious testing**. Our code is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](https://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [Core Infrastructure Initiative (CII) best practices](https://bestpractices.coreinfrastructure.org/projects/289). See the [quality assurance](https://json.nlohmann.me/community/quality_assurance) overview documentation.
+- **Serious testing**. Our code is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](https://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [OpenSSF Best Practices](https://www.bestpractices.dev/projects/289). See the [quality assurance](https://json.nlohmann.me/community/quality_assurance) overview documentation.
 
 Other aspects were not so important to us:
 

docs/mkdocs/docs/community/assurance_case.md

@@ -43,8 +43,8 @@ that an attacker controls, passed to [`parse`](../api/basic_json/parse.md), [`ac
   user code. The destructor does not recurse, so destroying a deeply nested value does not exhaust the stack.
 - **Bounded recursion.** The JSON parser and the binary readers keep their state in explicit stacks instead of
   recursing per nesting level. Operations that walk a value, such as [`dump`](../api/basic_json/dump.md), copying,
-  hashing, and [`merge_patch`](../api/basic_json/merge_patch.md), recurse only up to a fixed depth and continue with an
-  explicit stack below it. Some operations, such as comparison, [`diff`](../api/basic_json/diff.md),
+  comparison, hashing, and [`merge_patch`](../api/basic_json/merge_patch.md), recurse only up to a fixed depth and
+  continue with an explicit stack below it. Some operations, such as [`diff`](../api/basic_json/diff.md),
   [`flatten`](../api/basic_json/flatten.md), and the binary writers, still recurse once per nesting level; work on them
   is in progress. Applications that process untrusted input can limit its nesting depth with a
   [parser callback](../features/parsing/parser_callbacks.md).

docs/mkdocs/docs/community/governance.md

@@ -91,6 +91,31 @@ activities include (but are not limited to):
 Users who continue to engage with the project and its community will often find themselves becoming more and more
 involved. Such users may then go on to become contributors, as described above.
 
+## Access to project resources
+
+The project's resources are the [GitHub repository](https://github.com/nlohmann/json) with its settings, CI workflows
+and secrets, and the documentation at [json.nlohmann.me](https://json.nlohmann.me), which is built and deployed from
+the repository. Currently, the project lead is the only person with write or admin access to them.
+
+### Granting access
+
+Write or admin access is only granted by the project lead, and only to a contributor whose track record in the project
+the project lead has reviewed first. The role is assigned manually and is the lowest one that is needed for the task.
+Access is removed when it is no longer needed. GitHub requires two-factor authentication for everyone who can modify the
+repository.
+
+### Secrets
+
+The CI workflows mostly use the token that GitHub creates for each workflow run. It is read-only by default, and each
+workflow requests only the additional permissions it needs. The few other credentials, such as the token for
+[Semgrep](https://semgrep.dev), are stored as encrypted GitHub Actions secrets:
+
+- Only people with admin access can create, change, or delete them. Their values cannot be read back, not even by
+  admins.
+- They are not passed to workflows that run for pull requests from forks.
+- They must never be committed to the repository or printed in logs.
+- They are rotated whenever someone with admin access leaves the project, and immediately if a leak is suspected.
+
 ## Support
 
 All participants in the community are encouraged to provide support for new users within the project management

docs/mkdocs/docs/community/quality_assurance.md

@@ -200,6 +200,25 @@ Note: Some modern features (like C++20 ranges or filesystem support) may be disa
 - [x] The test suite is executed with [Sanitizers](https://github.com/google/sanitizers) (address sanitizer, undefined
   behavior sanitizer, integer overflow detection, nullability violations).
 
+## Dependencies
+
+!!! success "Requirement: No vulnerable dependencies"
+
+    The library has no dependencies besides the C++ standard library. The tools used to build, test, and document it
+    are kept free of known vulnerabilities.
+
+- [x] GitHub Actions are pinned to a commit hash, and the Python packages used by the documentation and the tools are
+  pinned to exact versions.
+- [x] [Dependabot](https://docs.github.com/en/code-security/dependabot) checks these dependencies daily and proposes
+  updates as pull requests.
+- [x] Every pull request is checked with the
+  [dependency review action](https://github.com/actions/dependency-review-action). A pull request that adds a
+  dependency with a known vulnerability of any severity fails this check and is not merged.
+- [x] Vulnerability alerts for dependencies are fixed or dismissed with a documented reason before the next release.
+  No release is made while such an alert is open.
+- [x] Third-party code included in the repository for testing, such as [doctest](https://github.com/doctest/doctest),
+  is updated manually.
+
 ## Style check
 
 !!! success "Requirement: Common code style"

docs/mkdocs/docs/home/design_goals.md

@@ -6,7 +6,7 @@ There are myriads of [JSON](https://json.org) libraries out there, and each may
 
 - **Trivial integration**. Our whole code consists of a single header file [`json.hpp`](https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp). That's it. No library, no subproject, no dependencies, no complex build system. The class is written in vanilla C++11. All in all, everything should require no adjustment of your compiler flags or project settings.
 
-- **Serious testing**. Our class is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](http://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [Core Infrastructure Initiative (CII) best practices](https://bestpractices.coreinfrastructure.org/projects/289).
+- **Serious testing**. Our class is heavily [unit-tested](https://github.com/nlohmann/json/tree/develop/tests/src) and covers [100%](https://coveralls.io/r/nlohmann/json) of the code, including all exceptional behavior. Furthermore, we checked with [Valgrind](http://valgrind.org) and the [Clang Sanitizers](https://clang.llvm.org/docs/index.html) that there are no memory leaks. [Google OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/json) additionally runs fuzz tests against all parsers 24/7, effectively executing billions of tests so far. To maintain high quality, the project is following the [OpenSSF Best Practices](https://www.bestpractices.dev/projects/289).
 
 Other aspects were not so important to us: