diff --git a/docs/Using-Fleet/Security-best-practices.md b/docs/Using-Fleet/Security-best-practices.md
index 75bf788780..b992557d63 100644
--- a/docs/Using-Fleet/Security-best-practices.md
+++ b/docs/Using-Fleet/Security-best-practices.md
@@ -13,12 +13,16 @@ The Fleet community follows best practices when coding. Here are some of the way
### Describe your secure coding practices, including code reviews, use of static/dynamic security testing tools, 3rd party scans/reviews.
-Every piece of code that is merged into Fleet is reviewed by at least one other engineer before merging. We don't use any security-specific testing tools.
+Code commits to Fleet go through a series of tests, including SAST (static application security testing).
+
+Every piece of code that is merged into Fleet is reviewed by at least one other engineer before merging.
The server backend is built in Golang, which (besides for language-level vulnerabilities) eliminates buffer overflow and other memory related attacks.
We use standard library cryptography wherever possible, and all cryptography is using well-known standards.
+Libraries are inventoried and monitored for vulnerabilities. Our process for fixing vulnerable libraries and other vulnerabilities is available in our [handbook](https://fleetdm.com/handbook/security#vulnerability-management).
+
### SQL injection
All queries are parameterized with MySQL placeholders, so MySQL itself guards against SQL injection and the Fleet code does not need to perform any escaping.
@@ -53,4 +57,4 @@ We render the frontend with React and benefit from built-in XSS protection in Re
We rely on Github's automated vulnerability checks, community news, and direct reports to discover vulnerabilities in our dependencies. We endeavor to fix these immediately and would almost always do so within a week of a report.
-
\ No newline at end of file
+