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||none known||Go Meta Linter, with the security-related linters (like SafeSQL, if you’re doing SQL queries) enabled|
|Python||Gemnasium||Bandit with the provided config file; engine for Code Climate|
|Ruby||Code Climate or Gemnasium||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.
Gemnasium is used to scan your code for possible security issues and provides alerts for new issues that come to light. Their list of supported dependency technologies is here.
Setting up your account
- Sign into Gemnasium using your GitHub account.
- Go to your settings page and change it to use your work email, if it isn’t already.
- Ask in #infrastructure to be invited to the email@example.com account.
- This provides you with access to the common dashboard for our projects. Make sure your project has multiple people with access to the gemnasium dashboard.
Do not add repos to Gemnasium on your individual account.
Unfortunately, Gemnasium struggles (as of 01/2017) to handle all of 18F’s repositories when adding a new one to monitor. Instead, use this work around:
- Go to https://gemnasium.com/projects/new_from_github?for=11206.
- Open the web developer console in your browser.
Edit this text (replacing
18F/repo-namefor your repo) and execute it:
$('[name=submit_github_projects]').before('<input type="hidden" name="full_names" value="18F/repo-name" />').click()
- Add the Gemnasium webhook to the GitHub repository.
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.
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.