diff --git a/SECURITY.md b/SECURITY.md
index d8709cd4a8c..d81a8bd428f 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -157,15 +157,14 @@ One of the most critical parts of any system is input handling. If malicious
 input can trigger side effects or incorrect behavior, this is a bug, and likely
 a vulnerability.
 
-**Note**: Assertion failures used to be considered a vulnerability in TensorFlow
-but, due to technical debt and the large number of them, coupled with the fact
-that an assertion failure may only lead to program termination and no other
-exploit, we will no longer consider assertion failures (e.g., `CHECK`-fails) as
-vulnerabilities. However, if the assertion failure occurs only in debug mode
-(e.g., `DCHECK`) and in production-optimized mode the issue turns into other
-code weakeness (e.g., heap overflow, etc.), then we will consider this to be a
-vulnerability. We recommend reporters to try to maximize the impact of the
-vulnerability report (see also [the Google VRP
+**Note**: Assertion failures used to be considered a vulnerability in
+TensorFlow. If an assertion failure  only leads to program termination and no
+other exploits, we will no longer consider assertion failures (e.g.,
+`CHECK`-fails) as vulnerabilities. However, if the assertion failure occurs only
+in debug mode (e.g., `DCHECK`) and in production-optimized mode the issue turns
+into other code weakness(e.g., heap overflow, etc.), then we will consider
+this to be a vulnerability. We recommend reporters to try to maximize the impact
+of the vulnerability report (see also [the Google VRP
 rules](https://bughunters.google.com/about/rules/6625378258649088/google-and-alphabet-vulnerability-reward-program-vrp-rules)
 and [the Google OSS VRP
 rules](https://bughunters.google.com/about/rules/6521337925468160/google-open-source-software-vulnerability-reward-program-rules)).