From 703a76f0a3d557134a2ecf1e0e944c7bf79c3bb4 Mon Sep 17 00:00:00 2001 From: Wesley Rosenblum Date: Tue, 11 Aug 2026 14:48:28 -0700 Subject: [PATCH 1/7] docs: Add SECURITY.md with AWS-LC threat model AWS-LC has no repo-level security policy, so github.com/aws/aws-lc/security/policy falls back to the aws/.github org default. That default is reporting boilerplate with no threat model, so reporters have no stated basis for deciding what is in scope. Add a SECURITY.md adapted from the s2n-tls security policy, keeping its section order and the shared AWS reporting language. The threat model is rewritten for a cryptographic library: implementation defects are framed for C, and timing and cache-based side channels are in scope rather than out, since constant-time behavior is a core promise of libcrypto. Link the policy from README and CONTRIBUTING, both of which carry a security reporting section. --- CONTRIBUTING.md | 2 ++ README.md | 6 +++- SECURITY.md | 87 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 94 insertions(+), 1 deletion(-) create mode 100644 SECURITY.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 56f6b597114..0b02f7409ba 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -52,6 +52,8 @@ opensource-codeofconduct@amazon.com with any additional questions or comments. ## Security issue notifications If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/). Please do **not** create a public github issue. +See our [Security Reporting Policy](./SECURITY.md) for additional guidance on issues considered in-scope for our threat model. + ## Licensing diff --git a/README.md b/README.md index 98f971cd25d..0ba9d630649 100644 --- a/README.md +++ b/README.md @@ -201,7 +201,9 @@ We use [GitHub Issues](https://github.com/aws/aws-lc/issues) for managing featur bug reports, or questions about AWS-LC API usage. If you think you might have found a security impacting issue, please instead -follow our [Security Notification Process](#security-issue-notifications). +follow our [Security Notification Process](#security-issue-notifications). See our +[Security Reporting Policy](./SECURITY.md) for additional guidance on issues considered +in-scope for our threat model. ## Security issue notifications @@ -211,3 +213,5 @@ Security via our Please do **not** create a public GitHub issue. If you package or distribute AWS-LC, or use AWS-LC as part of a large multi-user service, you may be eligible for pre-notification of future AWS-LC releases. Please contact aws-lc-pre-notifications@amazon.com. + +See our [Security Reporting Policy](./SECURITY.md) for additional guidance on issues considered in-scope for our threat model. diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000000..d89128a0a18 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,87 @@ +# Security Reporting Policy + +## Reporting Security Issues + +We kindly ask that you **do not** open a public GitHub issue to report security concerns. + +Instead, please submit the issue to the AWS Vulnerability Disclosure Program via [HackerOne](https://hackerone.com/aws_vdp) or send your report via [email](mailto:aws-security@amazon.com). + +Amazon Web Services (AWS) practices industry-standard Coordinated Vulnerability Disclosure (CVD) with the goal of reducing adversary advantage while a security vulnerability is being addressed. The [CERT® Guide to Coordinated Vulnerability Disclosure](https://certcc.github.io/CERT-Guide-to-CVD/tutorials/cvd_in_a_nutshell/) provides information about the CVD process, and outlines tools and practices that can help achieve this goal. + +For more details, visit the [AWS Vulnerability Reporting Page](http://aws.amazon.com/security/vulnerability-reporting/). + +Thank you in advance for collaborating with us to help protect our customers. + +## Threat Model + +### Shared Responsibility Model + +Security is a shared responsibility between AWS-LC and the applications that use it. AWS-LC is a general-purpose cryptographic library, and its consumers include s2n-tls and aws-lc-rs. + +AWS-LC is responsible for correctly implementing the cryptographic algorithms and protocols it supports, for keeping secret-dependent operations free of observable timing and memory access variation, for zeroizing key material it owns, and for reporting failures accurately rather than returning a misleading success. + +Applications are responsible for the security of the host on which the process loading AWS-LC runs, and for using AWS-LC in a way that achieves their security goals. This includes selecting algorithms, key sizes, and parameters adequate for their own threat model, and calling the API correctly. AWS-LC is a C library with a large OpenSSL compatibility surface, so it offers weaker misuse resistance than an API designed for that purpose. + +Given this shared responsibility, the following attacks are considered out of scope for AWS-LC: + +* Attacks requiring access to the memory, files, or privileges of the calling process +* Side-channel attacks exploiting CPU or hardware flaws, such as Meltdown and Spectre +* Physical attacks, including fault injection, power analysis, and electromagnetic observation +* Defects in the operating system entropy source, or in the toolchain used to build AWS-LC + +If you are unsure whether an issue falls in or out of scope, we encourage you to report it; we'd rather investigate a potential concern than miss a real one. Even for out-of-scope attacks, we may still choose to apply mitigations after weighing the potential cost to performance, maintainability, and complexity. All reported findings will be investigated and mitigations will be decided on a case-by-case basis. + +### Adversarial Models + +The following adversarial models describe the threats that AWS-LC is designed to defend against. The protection actually achieved depends on the algorithms and parameters the application selects. For example, forward secrecy requires ephemeral key exchange, and resistance to harvest-now-decrypt-later attacks requires post-quantum key establishment. + +#### Untrusted Input Adversary + +An adversary who controls data an application passes to AWS-LC, such as certificates, signatures, ciphertexts, and encoded keys. This adversary can: + +* Send crafted encodings (e.g. DER, PEM) to exploit flaws in parsers +* Supply malformed public keys or group parameters to provoke invalid-curve or small-subgroup behavior +* Tamper with authenticated ciphertexts, or attempt to forge signatures and authentication tags +* Cause denial of service through resource exhaustion + +#### Network Adversary + +An active attacker with complete control over the network between a TLS client and server using AWS-LC's libssl. In addition to the untrusted input capabilities above, this adversary may: + +* Intercept, modify, replay, and inject messages sent on public network channels +* Attempt to downgrade the protocol version or cryptographic parameters negotiated between the peers +* Exploit timing differences practically measurable over a network +* Obtain long-term secrets (e.g. private keys) after a session is complete, or exploit weak long-term keys + +#### Co-located Adversary + +An unprivileged process on the same host, or a workload sharing the same physical CPU. In addition to the untrusted input and network capabilities above, this adversary may: + +* Measure fine-grained timing of cryptographic operations performed on secret data +* Observe microarchitectural state shared with AWS-LC, such as CPU cache access patterns + +### Vulnerability Scope + +Given the adversarial models above, the following are examples of security-relevant issues that should be reported in accordance with [Reporting Security Issues](#reporting-security-issues): + +* Memory safety defects, undefined behavior, integer overflow, or reads of uninitialized memory +* Secret-dependent timing, branching, or memory access in cryptographic operations +* Incorrect algorithm implementations that weaken confidentiality, integrity, or authentication +* Verification routines that accept an invalid signature, authentication tag, or certificate chain +* Failure to zeroize long-term or intermediate secret key material +* Weaknesses in random number generation, such as insufficient seeding or repetition across `fork` +* A security-relevant failure reported to the caller as success + +The following are generally not considered vulnerabilities in this project's context: + +* Caller-supplied invalid arguments, such as NULL pointers or undersized output buffers +* Use of deprecated OpenSSL compatibility APIs that behave as documented +* Weak algorithms or parameters that the caller explicitly selects +* Differences from OpenSSL behavior documented in the [porting guide](./PORTING.md) +* Findings requiring `BORINGSSL_UNSAFE_FUZZER_MODE` or `BORINGSSL_UNSAFE_DETERMINISTIC_MODE`, which disable checks for testing + +Please tell us if a report concerns a FIPS build. The FIPS module is validated separately, and its boundary and platform limitations are described in [FIPS.md](./crypto/fipsmodule/FIPS.md). + +## Prenotification Policy + +If you package or distribute AWS-LC, or use AWS-LC as part of a large multi-user service, you may be eligible for pre-notification of future AWS-LC releases. Please contact aws-lc-pre-notifications@amazon.com. From 4d16ab697248706881266672abb1cb8341cfc6ff Mon Sep 17 00:00:00 2001 From: Wesley Rosenblum Date: Tue, 11 Aug 2026 14:58:49 -0700 Subject: [PATCH 2/7] docs: Drop consumer list from threat model Naming downstream consumers does no work in a shared responsibility model, which is about which party is responsible for what rather than who depends on the library. Removing it also drops the only claim in the document that could not be verified from this repo's own source. --- SECURITY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index d89128a0a18..01bbf16cbc8 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -16,7 +16,7 @@ Thank you in advance for collaborating with us to help protect our customers. ### Shared Responsibility Model -Security is a shared responsibility between AWS-LC and the applications that use it. AWS-LC is a general-purpose cryptographic library, and its consumers include s2n-tls and aws-lc-rs. +Security is a shared responsibility between AWS-LC and the applications that use it. AWS-LC is responsible for correctly implementing the cryptographic algorithms and protocols it supports, for keeping secret-dependent operations free of observable timing and memory access variation, for zeroizing key material it owns, and for reporting failures accurately rather than returning a misleading success. From ce5e4b0ae1dabc2e5e586832865ca5fa554f7b88 Mon Sep 17 00:00:00 2001 From: Wesley Rosenblum Date: Tue, 11 Aug 2026 15:03:38 -0700 Subject: [PATCH 3/7] docs: Drop redundant error-reporting responsibility The clause restated the Vulnerability Scope bullet on failures reported as success without adding anything, and it broke the parallelism of a sentence whose other items are affirmative capability promises. The Vulnerability Scope bullet is the operative statement, since it tells a reporter what to report. --- SECURITY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index 01bbf16cbc8..8716bf6ba69 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -18,7 +18,7 @@ Thank you in advance for collaborating with us to help protect our customers. Security is a shared responsibility between AWS-LC and the applications that use it. -AWS-LC is responsible for correctly implementing the cryptographic algorithms and protocols it supports, for keeping secret-dependent operations free of observable timing and memory access variation, for zeroizing key material it owns, and for reporting failures accurately rather than returning a misleading success. +AWS-LC is responsible for correctly implementing the cryptographic algorithms and protocols it supports, for keeping secret-dependent operations free of observable timing and memory access variation, and for zeroizing key material it owns. Applications are responsible for the security of the host on which the process loading AWS-LC runs, and for using AWS-LC in a way that achieves their security goals. This includes selecting algorithms, key sizes, and parameters adequate for their own threat model, and calling the API correctly. AWS-LC is a C library with a large OpenSSL compatibility surface, so it offers weaker misuse resistance than an API designed for that purpose. From 69c91f55744dd7c06871a0e193871e820c378fb8 Mon Sep 17 00:00:00 2001 From: Wesley Rosenblum Date: Tue, 11 Aug 2026 15:08:08 -0700 Subject: [PATCH 4/7] docs: Keep responsibility statement high level Zeroization and constant-time behavior are mechanisms for discharging a duty, not the duty itself, and both are already listed as reportable issues under Vulnerability Scope. Mixing them into the responsibility statement put two abstraction levels in one sentence and duplicated the scope list. State the duty instead, matching the register s2n-tls uses in the same slot. --- SECURITY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index 8716bf6ba69..ddb9371347a 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -18,7 +18,7 @@ Thank you in advance for collaborating with us to help protect our customers. Security is a shared responsibility between AWS-LC and the applications that use it. -AWS-LC is responsible for correctly implementing the cryptographic algorithms and protocols it supports, for keeping secret-dependent operations free of observable timing and memory access variation, and for zeroizing key material it owns. +AWS-LC is responsible for correctly and securely implementing the cryptographic algorithms and protocols it supports, and for protecting the key material entrusted to it. Applications are responsible for the security of the host on which the process loading AWS-LC runs, and for using AWS-LC in a way that achieves their security goals. This includes selecting algorithms, key sizes, and parameters adequate for their own threat model, and calling the API correctly. AWS-LC is a C library with a large OpenSSL compatibility surface, so it offers weaker misuse resistance than an API designed for that purpose. From e73c4528e3155abfc13c0c0d4f6f4d28837ea697 Mon Sep 17 00:00:00 2001 From: Wesley Rosenblum Date: Tue, 11 Aug 2026 15:11:48 -0700 Subject: [PATCH 5/7] docs: Align scope with published advisory history All five advisories published against AWS-LC are certificate or signature validation logic errors, except one timing side channel. Two gaps followed. Revocation appeared nowhere, though CVE-2026-4428 is a revocation bypass, and the invalid-curve bullet it replaces has no counterpart in the record. Widen the verification bullet past chains so it also covers revocation and path constraints. --- SECURITY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index ddb9371347a..971f493e744 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -40,7 +40,7 @@ The following adversarial models describe the threats that AWS-LC is designed to An adversary who controls data an application passes to AWS-LC, such as certificates, signatures, ciphertexts, and encoded keys. This adversary can: * Send crafted encodings (e.g. DER, PEM) to exploit flaws in parsers -* Supply malformed public keys or group parameters to provoke invalid-curve or small-subgroup behavior +* Present revoked or misissued certificates, or chains that violate path constraints * Tamper with authenticated ciphertexts, or attempt to forge signatures and authentication tags * Cause denial of service through resource exhaustion @@ -67,7 +67,7 @@ Given the adversarial models above, the following are examples of security-relev * Memory safety defects, undefined behavior, integer overflow, or reads of uninitialized memory * Secret-dependent timing, branching, or memory access in cryptographic operations * Incorrect algorithm implementations that weaken confidentiality, integrity, or authentication -* Verification routines that accept an invalid signature, authentication tag, or certificate chain +* Verification routines that accept an invalid signature or authentication tag, or a certificate that should be rejected * Failure to zeroize long-term or intermediate secret key material * Weaknesses in random number generation, such as insufficient seeding or repetition across `fork` * A security-relevant failure reported to the caller as success From 8ebb588730c9946432e6f8e46cbe4628417a6614 Mon Sep 17 00:00:00 2001 From: Wesley Rosenblum Date: Tue, 11 Aug 2026 15:17:32 -0700 Subject: [PATCH 6/7] docs: Drop editorial aside on misuse resistance The sentence explained why AWS-LC is easy to misuse instead of stating whose duty it is, and compared the library unfavourably to an unnamed alternative. Declining to promise misuse resistance is expressed by not promising it and by the Vulnerability Scope carve-outs for invalid arguments, deprecated compatibility APIs, and caller-selected algorithms, all of which remain. --- SECURITY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index 971f493e744..26ac057bbaa 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -20,7 +20,7 @@ Security is a shared responsibility between AWS-LC and the applications that use AWS-LC is responsible for correctly and securely implementing the cryptographic algorithms and protocols it supports, and for protecting the key material entrusted to it. -Applications are responsible for the security of the host on which the process loading AWS-LC runs, and for using AWS-LC in a way that achieves their security goals. This includes selecting algorithms, key sizes, and parameters adequate for their own threat model, and calling the API correctly. AWS-LC is a C library with a large OpenSSL compatibility surface, so it offers weaker misuse resistance than an API designed for that purpose. +Applications are responsible for the security of the host on which the process loading AWS-LC runs, and for using AWS-LC in a way that achieves their security goals. This includes selecting algorithms, key sizes, and parameters adequate for their own threat model, and calling the API correctly. Given this shared responsibility, the following attacks are considered out of scope for AWS-LC: From 5e624f092a1f27663a2215859110abe557cabbb6 Mon Sep 17 00:00:00 2001 From: Wesley Rosenblum Date: Thu, 20 Aug 2026 11:07:32 -0700 Subject: [PATCH 7/7] PR feedback --- CONTRIBUTING.md | 2 +- README.md | 6 +----- SECURITY.md | 10 +++++----- 3 files changed, 7 insertions(+), 11 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0b02f7409ba..8d0f42f0e2d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -50,7 +50,7 @@ opensource-codeofconduct@amazon.com with any additional questions or comments. ## Security issue notifications -If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/). Please do **not** create a public github issue. +If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting/). Please do **not** create a public github issue. See our [Security Reporting Policy](./SECURITY.md) for additional guidance on issues considered in-scope for our threat model. diff --git a/README.md b/README.md index 0ba9d630649..3592ff3a726 100644 --- a/README.md +++ b/README.md @@ -201,9 +201,7 @@ We use [GitHub Issues](https://github.com/aws/aws-lc/issues) for managing featur bug reports, or questions about AWS-LC API usage. If you think you might have found a security impacting issue, please instead -follow our [Security Notification Process](#security-issue-notifications). See our -[Security Reporting Policy](./SECURITY.md) for additional guidance on issues considered -in-scope for our threat model. +follow our [Security Notification Process](#security-issue-notifications). ## Security issue notifications @@ -212,6 +210,4 @@ Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting/). Please do **not** create a public GitHub issue. -If you package or distribute AWS-LC, or use AWS-LC as part of a large multi-user service, you may be eligible for pre-notification of future AWS-LC releases. Please contact aws-lc-pre-notifications@amazon.com. - See our [Security Reporting Policy](./SECURITY.md) for additional guidance on issues considered in-scope for our threat model. diff --git a/SECURITY.md b/SECURITY.md index 26ac057bbaa..8f7fb933ac7 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -8,7 +8,7 @@ Instead, please submit the issue to the AWS Vulnerability Disclosure Program via Amazon Web Services (AWS) practices industry-standard Coordinated Vulnerability Disclosure (CVD) with the goal of reducing adversary advantage while a security vulnerability is being addressed. The [CERT® Guide to Coordinated Vulnerability Disclosure](https://certcc.github.io/CERT-Guide-to-CVD/tutorials/cvd_in_a_nutshell/) provides information about the CVD process, and outlines tools and practices that can help achieve this goal. -For more details, visit the [AWS Vulnerability Reporting Page](http://aws.amazon.com/security/vulnerability-reporting/). +For more details, visit the [AWS Vulnerability Reporting Page](https://aws.amazon.com/security/vulnerability-reporting/). Thank you in advance for collaborating with us to help protect our customers. @@ -24,7 +24,7 @@ Applications are responsible for the security of the host on which the process l Given this shared responsibility, the following attacks are considered out of scope for AWS-LC: -* Attacks requiring access to the memory, files, or privileges of the calling process +* Attacks requiring on-host root access to processes, memory, sockets or files * Side-channel attacks exploiting CPU or hardware flaws, such as Meltdown and Spectre * Physical attacks, including fault injection, power analysis, and electromagnetic observation * Defects in the operating system entropy source, or in the toolchain used to build AWS-LC @@ -64,7 +64,7 @@ An unprivileged process on the same host, or a workload sharing the same physica Given the adversarial models above, the following are examples of security-relevant issues that should be reported in accordance with [Reporting Security Issues](#reporting-security-issues): -* Memory safety defects, undefined behavior, integer overflow, or reads of uninitialized memory +* Implementation defects that compromise confidentiality, integrity, or availability, including memory safety defects, undefined behavior, integer overflow, or reads of uninitialized memory * Secret-dependent timing, branching, or memory access in cryptographic operations * Incorrect algorithm implementations that weaken confidentiality, integrity, or authentication * Verification routines that accept an invalid signature or authentication tag, or a certificate that should be rejected @@ -78,9 +78,9 @@ The following are generally not considered vulnerabilities in this project's con * Use of deprecated OpenSSL compatibility APIs that behave as documented * Weak algorithms or parameters that the caller explicitly selects * Differences from OpenSSL behavior documented in the [porting guide](./PORTING.md) -* Findings requiring `BORINGSSL_UNSAFE_FUZZER_MODE` or `BORINGSSL_UNSAFE_DETERMINISTIC_MODE`, which disable checks for testing +* Findings requiring the test-only modes described in [FUZZING.md](./FUZZING.md#fuzzer-mode): `BORINGSSL_UNSAFE_FUZZER_MODE` or `BORINGSSL_UNSAFE_DETERMINISTIC_MODE` -Please tell us if a report concerns a FIPS build. The FIPS module is validated separately, and its boundary and platform limitations are described in [FIPS.md](./crypto/fipsmodule/FIPS.md). +Please tell us if a report concerns a FIPS build. The FIPS module is validated separately, and its boundary and platform limitations are described in [FIPS.md](./crypto/fipsmodule/FIPS.md). See [VERSIONING.md](./VERSIONING.md) for information about which FIPS branches receive security patches. ## Prenotification Policy