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:

  • Dependency analysis, where the Ruby gems, Python modules, and JavaScript packages your app uses are checked against a list of known vulnerabilities.
  • 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
JavaScript Code Climate or Gemnasium eslint-config-scanjs / eslint-plugin-security
Python Gemnasium Bandit with the provided config file; engine for Code Climate
Ruby Code Climate or Gemnasium Code Climate or Hakiri - Rails only

Notes

  • 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

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

  1. Sign into Gemnasium using your GitHub account.
  2. Go to your settings page and change it to use your work email, if it isn’t already.
  3. Ask in #infrastructure to be invited to the devops@gsa.gov account.
  4. 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.

Adding projects

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:

  1. Go to https://gemnasium.com/projects/new_from_github?for=11206.
  2. Open the web developer console in your browser.
  3. Edit this text (replacing 18F/repo-name for your repo) and execute it:

     $('[name=submit_github_projects]').before('<input type="hidden" name="full_names[]" value="18F/repo-name" />').click()
    
  4. Add the Gemnasium webhook to the GitHub repository.

Dependency analysis

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.

Code analysis

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.

Config files

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.