Static Security Analysis
Static analysis is an important part of the development process, and is required for ATO. There are two main types of static security testing that needs to be done:
- Code security analysis, in which your code is checked against a list of antipatterns.
There are tools for JS, Ruby, and Python, and you are encouraged to set up this scanning early on in the development cycle to prevent unexpected delays when it’s time to get your ATO. Note that there are many tools out there for doing code style linting, but this page is specifically security-focused.
Recommendations by language
|Language||Dependency analysis||Code security analysis|
|Go||Snyk||Go Meta Linter, with the security-related linters (like SafeSQL, if you’re doing SQL queries) enabled|
|Python||Snyk||Bandit with the provided config file; engine for Code Climate|
|Ruby||Code Climate or Snyk||Code Climate or Hakiri - Rails only|
- Code Climate only scans when the code is
pushed, meaning it won’t catch any vulnerabilities if the code isn’t being actively worked on.
- Wherever the table says “see below”, that means there is no service available for scanning. Therefore, the recommended tool(s) should be run in continuous integration. Alternatively, you can also look into building a Code Climate engine.
Use one of the services above, which should support adding public repositories yourself. If you need scanning on a private repository, file an issue in the Infrastructure repo.
When starting a new project for an agency partner, consider creating a new Snyk organization for your project and invite the agency partners (in addition to the 18F team). This will facilitate the project’s hand-off in the future.
For repositories which include multiple dependency manifests (e.g. due to multiple sub-projects or crossing languages), be sure to configure Snyk to track each dependency file. By default, Snyk’s import will stop after finding the first dependency manifest.
This is commonly referred to as “static analysis”. Code analysis can be done by a service (recommended), or within your existing continuous integration tool. Additional configuration information available below.
Basic config files for some static analysis tools can be found in the compliance-toolkit repo. These currently are little more than the default settings, but the recommendations may change. If you find a test that you believe is invalid, file an issue in the repo.
We are especially interested to know if you get lots of false positives. We believe the default config files will grow and evolve, but the most up-to-date versions will always be found in the repo.
More advanced configuration options for all the tools can be found in their respective docs.