SRTool Developer Page

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.

Design Philosophy

• Make the tool easy to use
  • Support a web-based interface
  • Support backend scripts
  • Make the next-steps easy to find and understand
  • On-line documentation
• Make the design modular
  • It must be easy to add new CVE upstream data sources
  • It must be easy to adapt the SRTool to a new orgainization
  • It must be easy to add new reports and exports
• Make the design adaptable
  • Use the Django migration feature for on-the-fly updates
  • Make the data/interface table driven, remove hard coding as much as possible
• Minimize the data in the database
  • Only put CVE summary information in the database
  • Extract CVE details on-the-fly from the source data files
  • Cache CVE data detail lookups for fast response
  • Only put Defect summary information in the database
  • Provide links to the Defect system, with its full defect data
• Use scripts to bulk load/update the database
  • Scripts can update the database 10x faster than the Django DB interface
  • Scripts support background cron-job driven updates
• Support data recovery
  • The system will fail, so be prepared
  • Provide data backup scripts, cron-job supportable
  • Provide backup data recovery
  • Make it easy to re-build the system from scratch
• Support audit trails
  • Every user change should be trackable
  • It must be easy to generate a report on a CVE's action history
• Support protected data
  • There must be a validated user model so that changes can be tracked
  • There must be a way to mark individual CVEs and there releated data private to specific users

SRTool Startup

This section describes how the STool gets started and initialized.

SRTool Start-up High-Level

High level actions from the "bin/srt" startup script.

Description	Code file	Data file	Comments
Check if the webport is already used	"manage checksocket ..."	.srtmain.pid	If already used, warn and halt
Check the database and schema is up to date	"manage migrate ..."	srt.sqlite	Create database if needed, assert migrations
Check database has fixtures and datasources	"manage checksettings ..."	Django/SRTool migration files	Apply fixtures, apply un-read datasource data
Start the server	"manage runserver ..."	.srtmain.pid	Start the server thread, open the webport

SRTool Start-up Details

Detailed actions from Django and "lib/*" startup scripts.

Major Components

Data Sources

• CVE upsteam data
• Initialization actions
• Update actions
• Management actions
• Backup actions

Defect System Integration

• Ability to import CVE affected defects from Defect system
• Ability to create new CVE affected defects to Defect system
• Ability to update CVE status from Defect system

Report/Export System

• Ability to export respective data from any page
• Ability to generate reports in multiple formats (e.g. text, CSV)
• Ability to easily add new reports and new output formats

Data backup and Recovery

• Ability regularly backup data via scripts and a CRON job
• Ability to restore data

SRTool Code Organization

• All of the scripts are under the "/bin" directory
• All of the Django files are under the "/lib" directory
• All of the GUI files are under the "/lib/srtgui" directory
• All of the database management files are under the "/lib/orm" directory (object-relationhip-model)
• All of the user management files are under "/lib/user" and "lib/srtmain/templates"
• The GUI starts from "lib/srtmain/urls.py"