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

2) Cloning the SRTool

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

3) Starting the SRTool

Restrict to the local browser:

  ./bin/srtool start webport=localhost:9000 

Enable remote browsers:

  ./bin/srtool start webport=0.0.0.0:9000 

4) 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 and loaded into the database. After that, the updates will be incremental.

5) Open browser to <IPADDR>:9000

Bugs and Enhancement Requests

The SRTool is track in Bugzilla here:

  https://bugzilla.yoctoproject.org/buglist.cgi?list_id=609538&bug_status=__all__&query_format=specific&order=relevance%20desc&product=Security%20Response%20Tool 

Development Overview

Here are the next steps in the SRTool development.

Timeframe	Phase	Description
< Oct 2018	Internal development	Initial exploration and coding
Oct,Nov 2018	Initial release preparation	Finalize schema, user model, initial reviews
Dec 2018 - March 2018	Initial release	Deploy, gather defects and enhancement requests
March 2018	Rebase	Rebase schema, code
> April 2018	In production	Increment ongoing development

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 product list

2) Add defect system import

You will implement a defect integration backend script 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 "Vunerability".

• 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.

Development Workflow

To contribute to the SRTool you will also need authorization to write to the upstream yocto project repository. Contact a member of the SRTool team for details.

1) Download the master branch of the SRTool

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

2) Add poky-contrib to the local repository you set up above

  git remote add poky-contrib ssh://git@git.yoctoproject.org/poky-contrib 

3) Fetch the poky-contrib branches

  git fetch --all 

4) Start your feature branch off of master, name style of branch is convention, but suggested.

  git checkout -b username/srtool/FeatureOrBug origin/master 

5) Do Work

6) Test the changes.

7) Rebase on master. It has probably changed while you were working (unless you are really really fast!)

  git rebase origin/master 

8) Push your feature branch to poky-contrib

 git push -u poky-contrib username/srtool/FeatureOrBug:username/srtool/FeatureOrBug

9) Send to the srtool-mailing list (TBD) using one of the methods outlined below.

10) NOTE: when the patch has been accepted upstream, you can clean up your poy-contrib branch with:

  git push -u poky-contrib :username/srtool/FeatureOrBug 

Developing the SRTool

Design

(in progress)

Data Sources

(in progress)

Tables and pages

(in progress)

Debugging the SRTool

The same basic techniques for debugging Toaster also apply to the SRTool. See this link for details [1].