Renaming appsec page + a few updates (#6358)

* Renaming appsec page + a few updates

Added a few details (name of appsec tools we use) and renamed the page to make it clearer this is about Fleet appsec and now how to secure a Fleet installation

* Apply suggestions from code review

Co-authored-by: Desmi-Dizney <99777687+Desmi-Dizney@users.noreply.github.com>

* Update Application-security.md

Fixed "merging"

Co-authored-by: Desmi-Dizney <99777687+Desmi-Dizney@users.noreply.github.com>
Co-authored-by: Kelvin Oghenerhoro Omereshone <kelvin@fleetdm.com>
This commit is contained in:
Guillaume Ross
2022-06-28 09:21:35 -04:00
committed by GitHub
co-authored by Desmi-Dizney Kelvin Oghenerhoro Omereshone
parent 255b670ce0
commit 2ef08265f6
@@ -1,4 +1,4 @@
# Security best practices
# Application security
- [Describe your secure coding practices](#describe-your-secure-coding-practices-including-code-reviews-use-of-staticdynamic-security-testing-tools-3rd-party-scansreviews)
- [SQL injection](#sql-injection)
@@ -13,16 +13,17 @@ 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.
Code commits to Fleet go through a series of tests, including SAST (static application security testing).
Code commits to Fleet go through a series of tests, including SAST (static application security
testing). We use a combination of tools, including [gosec](https://github.com/securego/gosec) and
[CodeQL](https://codeql.github.com/) for this purpose.
Every piece of code that is merged into Fleet is reviewed by at least one other engineer before merging.
At least one other engineer reviews every piece of code before merging it to Fleet.
This is enforced via branch protection on the main branch.
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.
@@ -55,6 +56,14 @@ We render the frontend with React and benefit from built-in XSS protection in Re
### Components with known vulnerabilities prevent the use of libraries, frameworks, other software with existing vulnerabilities.
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.
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.
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). We use
[Dependabot](https://github.com/dependabot) to automatically open PRs to update vulnerable dependencies.
<meta name="pageOrderInSection" value="800">