Application security
- Describe your secure coding practices (SDLC)
- SQL injection
- Broken authentication
- Sensitive data exposure
- Cross-site scripting
- Components with known vulnerabilities
The Fleet community follows best practices when coding. Here are some of the ways we mitigate against the OWASP top 10 issues:
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). We use a combination of tools, including gosec and CodeQL for this purpose.
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.
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.
Broken authentication – authentication, session management flaws that compromise passwords, keys, session tokens etc.
Passwords
Fleet supports SAML auth which means that it can be configured such that it never sees passwords.
Passwords are never stored in plaintext in the database. We store a bcrypt
ed hash of the password along with a randomly generated salt. The bcrypt
iteration count and salt key size are admin-configurable.
Authentication tokens
The size and expiration time of session tokens is admin-configurable. See The documentation on session duration.
It is possible to revoke all session tokens for a user by forcing a password reset.
Sensitive data exposure – encryption in transit, at rest, improperly implemented APIs.
By default, all traffic between user clients (such as the web browser and fleetctl) and the Fleet server is encrypted with TLS. By default, all traffic between osqueryd clients and the Fleet server is encrypted with TLS. Fleet does not by itself encrypt any data at rest (however a user may separately configure encryption for the MySQL database and logs that Fleet writes).
Broken access controls – how restrictions on what authorized users are allowed to do/access are enforced.
Each session is associated with a viewer context that is used to determine the access granted to that user. Access controls can easily be applied as middleware in the routing table, so the access to a route is clearly defined in the same place where the route is attached to the server see https://github.com/fleetdm/fleet/blob/main/server/service/handler.go#L114-L189.
Cross-site scripting – ensure an attacker can’t execute scripts in the user’s browser
We render the frontend with React and benefit from built-in XSS protection in React's rendering. This is not sufficient to prevent all XSS, so we also follow additional best practices as discussed in https://stackoverflow.com/a/51852579/491710.
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.
Libraries are inventoried and monitored for vulnerabilities. Our process for fixing vulnerable libraries and other vulnerabilities is available in our handbook. We use Dependabot to automatically open PRs to update vulnerable dependencies.