Contribute to SRTool

This page summarizes the Security Response Tool (SRTool) development process. We hope this will help you start contributing to the project. The SRTool is based on the Toaster codebase, so many of the process and debugging techniques apply.

Set up the local repository and SRTool instance

1) Host requirements

The required host package installation instructions are the same as Toaster, and the instructions can be found here: Toaster documentation

The SRTool was developed and tested with:

 * Ubuntu 16.04
 * Django 1.11 LTS and Django 2.2 
 * Sqlite3 3.11

Later versions of the host or Django should work, but they have not been tested yet.

2) Cloning the SRTool

  $ git clone ssh://git@push.yoctoproject.org/srtool && cd srtool 

3) Starting the SRTool

Option #1: Restrict to the local browser:

  $ ./bin/srtool start webport=localhost:9000 

Option #2: Enable remote browsers:

  $ ./bin/srtool start webport=0.0.0.0:9000 

NOTE: The first time you run the SRTool, there will be a delay (30 to 60 minutes) as the default CVE repositories (NIST, Mitre, ...) are scanned, scored, and loaded into the database. After that, the updates will be incremental.

4) Create a superuser

You will need to create at least one super user account to promote users to higher permission levels:

  $ ./bin/srt manage createsuperuser 

5) Open browser to <IPADDR>:9000

This will bring up the SRTool page.

6) Read the "Guided Tour"

Click on the "Guided Tour" button on the home page to see the on-line tool and user information.

7) Create your guest account

Click on the "Login" button in the top bar, select "Request Account", fill in the information, Click "Sign Up", and then log in.

8) Promote your account to Admin level

Login as the superuser, click "Management > Manage Users", click the edit icon for your guest account row, change the "Group" to "Admin", and click "Submit Changes".

You can now log out of the superuser account and into your own account.

Sanity Test Bring-up

You can use these steps to start a minimal instance of the SRTool to help validate that the host and the code base are working on your system. This will for example set the environment variable "SRTDBG_MINIMAL_DB=1" which will only fetch a few representative records from each data source.

 $ git pull
 $ # Copy the dev tools to the base directory
 $ cp bin/dev_tools/* .
 $ # Source the debug environment
 $ . ./srt_env.sh debug
 $ # Start the system from scratch
 $ ./recreate.sh
 $ # Run the sanity test
 $ ./bin/common/srtool_sanity_test.py -i
 $ 

Sample output:

 $ ./bin/common/srtool_sanity_test.py -i
 Uname       = #35~16.04.1-Ubuntu SMP Thu Jan 25 10:13:43 UTC 2018 x86_64
 Django      = (1, 11, 8, 'final', 0)
 Python3     = Python 3.5.2
 Sqlite3     = 3.11.0 2016-02-15
 Server PID  = 10234
 Server Port = [10234](/opt/srtool/lib/manage.py runserver --noreload 0.0.0.0:9123)
 CVEs        = 64
 Users       = 5
 Data source = 22
 $ 

To re-start as the full instance, do this:

 $ # Source the standard environment
 $ . ./srt_env.sh
 $ # Start the system from scratch
 $ ./recreate.sh
 $ 

First Time Bring-up

• When you first start, you will have the CVEs from 2015 to 2018
• You will not have any Vulnerabilities, Investigations, or Defects until you (a) create them, and/or (b) integrate your defect system or other sustaining data.
• All CVEs will by default get the status "Historical".
  • The CVEs that were created in the previous 30 days will instead get the status "New"
  • This will allow you to immediately test the CVE triage features
  • The status settings are normally preset by your defect system or other sustaining data
• You can create a Vulnerability by:
  • Selecting a CVE
  • Click on "Create Vulnerability"
  • Follow the new link to the new Vulnerability
• You can create an Investigation by:
  • Open a Vulnerability record
  • Click on "Add Product"
  • Select one or more Products, and click "Submit"
  • Observe that the products are added together with new respective Investigations
  • Follow the new link to the new Investigations

SRTool Primary Goals and Workflows

• Goals
  • A common system to track and share security issues, combining community CVE's
  • A simple yet flexible interface for reporting and exploring the security issues
  • A place to upload and share attachments, including patches, fixes, emails, and documents
  • The ability to generate accurate and up-to-date reports and exports
  • A modular design for easy extension and adoption

• Primary Workflows
  • Guide and manage the incoming CVE triage process
  • Attach CVEs to specific company products and defects
  • Automated updates from upstream CVEs and internal defect system
  • Ability to generate reports
  • Correlate CVEs with products and release
  • Correlate CVEs with specific customer builds

SRTool CVE Lifecycle

• CVE are imported
  • New CVEs are imported and triaged from upstream (NIST/MITRE, 1000+/month)
  • Specific CVEs are requested by customers
• CVEs are managed
  • CVEs are investigated
  • Vulnerable CVEs are assigned to products via defects
  • SRTool manager tracks the progress of open CVEs
  • SRTool manager produces reports as required by customers, field, and management
• CVEs are resolved
  • CVEs are either fixed or declared not vulnerable
  • Releases are updated with the CVE fixes
  • Resolved CVEs are reported to customers, public website

Adapting SRTool to your Organization

1) Out of the box setup (NIST/MITRE)

 (a) When SRTool starts up, it will automatically load the preset data sources.

 (b) NIST and MITRE are examples of preset data sources, by default to import 2015 to 2018.

To extend the coverage for these sources you just need to edit the NIST and MITRE data source JSON files.

2) Instantiate your Organization

 (a) Rename the sample 'acme_sample' directory under "bin" to your organization's moniker, and remove "_sample" from the file names

 (b) Update that "datasource.json" file for the organizations settings

 (c) Define this "srtsetting" in that ""datasource.json" file to make this the default organization (not 'yp')

   {
     "name" : "datasource_org",
     "helptext" : "Bin directory for the ACME Organization",
     "value" : "acme"
   },

 (d) Instantiate the organization's product list, and user list (if any)

 (e) Adapt that "srtool_acme.py" script to manage your resources

 (f) Rename the "lib/acme" product to your organization's moniker

 (g) Use that directory's content as examples on how to extend the interface with custom pages

3) Add defect system import

You will implement a defect integration backend script (e.g. "bin/acme_sample/srtool_defect.py") to scan your defect system and instantiate the CVE defects in SRTool database.

 (a) Add the "--init" command

• This is the command that will initialize the SRTool database with your SRT related defects. Specifically, this command can used to bootstrap the SRTool database for you company's data.

• It should create an "Investigation" for each defects, and attach it to the respective product.

• It should create a "Vulnerability" to wrap the "Investigation".

• If should find the respective CVE record, and attach that to the created "Vulnerability".

• If a "Vulnerability" record already exists for the defect;s CVE, then this script should attach the new "Investigation" to that "Vulnerability" record.

 (b) Add the "--update" command

• This should scan your CVE related defects

• If the matching defect record in the SRTool database does not exist, then treat it like the "--init" command.

• Update the SRTool defect record with the current defect system state

• If the defect has changed priority (or any other important state information), consider creating a "Notification" event to the respective manager so that they can know that they need to act on the change.

SRTool Developer Page

Here is the link to the Developer's page: SRTool Developer Page