Secure Development Evidence Pack
This resource shares some general information about Skillstream's software development lifecycle, with particular reference to our security practices, and links to evidence for anyone undertaking due diligence.
The lifecycle is backed by a variant of the 'git-flow' branching strategy, with Atlassian Jira tracking features and issues, and GitHub supporting peer review, test automation and release tracking.
List of Tools
Day-to-day
Below is a list of tools we use during development to assist us, backed by Github Actions as laid-out in this sample workflow.
- bundler-audit checks 3rd-party libraries against the CVE database for known vulnerabilities in Ruby gems.
- Evidence: sample output from bundle audit
- yarn-audit checks 3rd-party libraries against the CVE database for known vulnerabilities in nvm packages.
- Evidence: sample output from yarn audit
- Brakeman analyses projects which use the Ruby on Rails framework for common vulnerabilities.
- Brief outline of how Brakeman helps test against some of the OWASP Top 10, from Stack Overflow
- Evidence: sample output from Brakeman
- Rubocop enforces in-house coding style and is also good at highlighting the subset of bugs which can arise from violating conventions, e.g. variable shadowing, method duplication after a merge, etc.
- Evidence: sample output from Rubocop
- RSpec is used to define expected behaviour and test those expectations. Some of those expectations explicitly cover access control, but other tests will prevent the many bugs that could also have had security implications.
- Evidence: sample output from RSpec
- Supporting tools:
- FactoryBot for churning-out randomised test objects
- Faker for generating realistic test data
- Capybara for front-end integration testing
Penetration testing
These are the main tools we use for periodic review of application security:
- OWASP ZAP to scan our web apps for vulnerabilities.
- Kali Linux VM because it comes pre-installed with ZAP and a lot of other useful tools, and is a safe environment for handling malware if required.
Evidence
- Here are some screenshots of ZAP in use.
Devops
Configuration
We manage the nodes hosting our applications using Chef. The provisioning and configuration of each node (where a node is a VM or dedicated server) is defined in our 'chef kitchen' repo, version-tracked and change-managed using git, GitHub and Jira.
Evidence
- A node definition for a disposable VM used during development for testing deployment configurations.
- A TLS certificate installed by certbot.
- The Nginx SSL (TLS) config.
Monitoring
Our live monitoring solution is an in-house tool we call smon. It was built as an aggregator of collectd statistics from our nodes, but has come to act as a central board for
- monitoring system health
- monitoring application installations
- tracking software releases through staging environments into production
In addition to smon, we also run Logwatch on each linux node (evidence: sample output from Logwatch). Using collectd to aggregate the same data as Logwatch is on the roadmap for smon.
Evidence
- Here are some screenshots of smon.