docs: Add security reporting policy by WesleyRosenblum · Pull Request #5734 · aws/s2n-tls

WesleyRosenblum · 2026-02-13T23:42:49Z

Goal

Adds a SECURITY.md containing guidance around the s2n-tls threat model and other policies related to security

Why

Provide guidance to contributors on s2n-tls considers threats and how and when to report them

How

Providing guidance on out of scope threats, adversarial models, and examples of in and out of scope vulnerabilities.

Callouts

The Security Policy linked at https://github.com/aws/s2n-tls/security/policy is an AWS-wide policy that will remain in place, but I've linked this s2n-tls specific policy in the README.

Testing

Documentation-only change, no code modified.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

jmayclin · 2026-02-17T23:14:51Z

SECURITY.md

+
+Given the adversarial models above, the following are examples of issues considered security-relevant and should be reported in accordance with [Reporting Security Issues](#reporting-security-issues):
+
+* Implementation defects that compromise confidentiality, integrity, or availability (e.g. memory safety bugs, undefined behavior)


are examples of issues considered security-relevant

undefined behavior

I think that we need to qualify this. E.g. s2n-tls was adding 0 to a null pointer in a few places. That was technically undefined behavior, but I do not consider that security relevant.

I think I'm OK leaving this unqualified. The "adding 0 to NULL is UB" seems to be fixed more recently (llvm/llvm-project#113062), and I kind of doubt there are many more false-positive UB findings out there such that we can't handle them on a case by case basis (ie I'm fine treating them as security-relevant until proven otherwise)

jmayclin · 2026-02-17T23:15:50Z

SECURITY.md

+
+* Implementation defects that compromise confidentiality, integrity, or availability (e.g. memory safety bugs, undefined behavior)
+* Logic bugs that lead to incorrect TLS negotiation, handshake errors, or authentication bypass
+* Negotiation of weak or non-policy-approved cryptographic algorithms


Once again, tricky. Customers can allow themselves to negotiate RC4/SSLv3. I would bet that we also allow RSA1024

Yeah I was thinking about this one after the fact. If a took out "weak" would that be sufficient you think?

"Negotiation of non-policy-approved cryptographic algorithms"

or I could be more specific like:

"Negotiation of cryptographic algorithms not specified in the configured security policy"

jmayclin · 2026-02-17T23:23:22Z

SECURITY.md

@@ -0,0 +1,78 @@
+# Security Policy


I think there is a missing qualification here where s2n-tls supports a wide variety of behaviors that are not following best practice, but may be acceptable for some specific threat models.

non-PQ key exchange

TLS 1.2 session resumption

RSA key exchange

1024 bit RSA certs

RC4/3DES

SSLv3

But I think the security policy as written would immediately make these security vulnerabilities.

Obtain long-term secrets (e.g. private keys) of any client or server after a session is complete

This makes RSA key exchange and TLS 1.2 resumption a security issue

Record encrypted traffic now for future decryption once a cryptographically relevant quantum computer is available (harvest now, decrypt later)

This makes non-pq key exchange a security issue.

Good point, I've added some content to address this

maddeleine · 2026-02-17T23:52:33Z

SECURITY.md

@@ -0,0 +1,78 @@
+# Security Policy


What about Security Posture/threat model instead of Policy? I'd rather not overload our use of "Security Policy".

I went with "Security Reporting Policy"

maddeleine · 2026-02-17T23:58:07Z

SECURITY.md

+
+### Out of Scope Attacks
+
+Applications integrating with s2n-tls are responsible for the security of the host on which the process loading the s2n-tls library runs. This means the following attacks are considered out of scope:


I don't know if I agree with this. Yes, it's outside of our threat model, but I don't want people to stop reporting this stuff to us.
I want to encourage users to report stuff to us, rather than discouraging it. We should be biased towards fixing issues even if there is no practical exploit.

I also would like us to still accept reports of related issues, and clearly say we reserve the right to decide if mitigations in s2n-tls make sense.

I think physical observations likely remain out of scope, but thinks like fault injections where the advantage is due to easily improvement implementation with minimal impact to performance or maintainability, would be something we could accept as an improvement.

Thanks for the feedback, I've incorporated these suggestions

crlorentzen · 2026-02-19T21:09:39Z

SECURITY.md

+
+If you are unsure whether an issue is security-relevant, please err on the side of caution and report it through the [Reporting Security Issues](#reporting-security-issues) process.
+
+## Prenotification Policy


Is this intended to be a duplicate of the README.md policy that offers pre-notification of releases (not specifically security related issue/releases?)

Actually I see this policy is duplicated but both are in the Security issues area. I am okay with over-communicating in this instance because someone could get here without reading to the "Security issue notifications" section of the README.md

yeah, a few things are duplicated in various places but I had the same thought, that people will arrive at these different docs in different ways, so better to just include the information everywhere

github-actions bot added the s2n-core team label Feb 13, 2026

docs: Add security policy

3f6ca32

WesleyRosenblum force-pushed the WesleyRosenblum/secpolicy branch from 66180d1 to 3f6ca32 Compare February 13, 2026 23:46

WesleyRosenblum added 2 commits February 16, 2026 08:43

Merge branch 'main' into WesleyRosenblum/secpolicy

557ffbc

Merge branch 'main' into WesleyRosenblum/secpolicy

c744b06

WesleyRosenblum requested review from alexw91, jmayclin and maddeleine February 17, 2026 21:26

Merge branch 'main' into WesleyRosenblum/secpolicy

cf67d38

jmayclin reviewed Feb 17, 2026

View reviewed changes

maddeleine reviewed Feb 17, 2026

View reviewed changes

WesleyRosenblum and others added 4 commits February 18, 2026 23:43

Rename Security Policy to Security Reporting Policy

fe9b3f6

Incorporate PR feedback

a8c3460

Cleanup

cc79b3f

Merge branch 'main' into WesleyRosenblum/secpolicy

c923788

WesleyRosenblum requested review from crlorentzen, jmayclin and maddeleine February 19, 2026 00:47

maddeleine approved these changes Feb 19, 2026

View reviewed changes

crlorentzen reviewed Feb 19, 2026

View reviewed changes

crlorentzen approved these changes Feb 19, 2026

View reviewed changes

WesleyRosenblum changed the title ~~docs: Add security policy~~ docs: Add security reporting policy Feb 19, 2026


		Given the adversarial models above, the following are examples of issues considered security-relevant and should be reported in accordance with [Reporting Security Issues](#reporting-security-issues):

		* Implementation defects that compromise confidentiality, integrity, or availability (e.g. memory safety bugs, undefined behavior)


		### Out of Scope Attacks

		Applications integrating with s2n-tls are responsible for the security of the host on which the process loading the s2n-tls library runs. This means the following attacks are considered out of scope:


		If you are unsure whether an issue is security-relevant, please err on the side of caution and report it through the [Reporting Security Issues](#reporting-security-issues) process.

		## Prenotification Policy

Comments

Conversation

WesleyRosenblum commented Feb 13, 2026

Goal

Why

How

Callouts

Testing

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants