swift-lifetime is a concurrency-runtime support library; it does not handle credentials, network traffic, or persisted user data on its own. Most realistic security-relevant defects in this package will surface as incorrect cancellation, missed teardown, or unsoundness under Sendable checking — situations where ownership guarantees promised in the documentation are not actually honored.

The supported stable line starts at 1.0.0. Security fixes ship on current 1.x releases; pre-1.0 snapshots are out of scope.

Do not file a public GitHub issue for a suspected vulnerability.

Use GitHub's private vulnerability reporting to open a private advisory against this repository. Include:

• A description of the issue and the security impact.
• A minimal reproduction (ideally a Swift Testing case using the public API of one of the library targets).
• Affected versions and platforms.
• Any suggested mitigation.

Acknowledgement target: within 7 days. We may ask follow-up questions through the same private channel.

If you do not get a response within 14 days, you can escalate by emailing the maintainer listed in the repository's GitHub profile.

Reports that fit, with examples:

• A Scope.cancel() call returns before its registered teardown has actually finished, in a reproducible scenario.
• A Sendable annotation on a public type is unsound and allows a data race observable from supported Swift 6 + strict memory safety configurations.
• A Resource, Child, or supervised LifetimeHandle is reachable after teardown in a way the public API does not document.
• A factory throws something other than ScopeError.cancelled when its originating scope has ended.

Reports that are not in scope (please file as regular issues instead):

• Performance regressions that do not cross a published benchmark threshold.
• API ergonomic preferences.
• Issues only reproducible under runtime configurations the package does not claim to support (e.g. Swift 5 language mode, iOS 17, or custom executors not bridged through LifetimePolicies).

For accepted reports, we aim to ship a fix and a GitHub Security Advisory together. CVE assignment is at GitHub's discretion; we will request one when the impact warrants it.