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

For our cloud-native environments, we deploy Docker containers to Kubernetes clusters.

For classic environments, 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

• An application Dockerfile.
• A kubernetes application deployment spec.
• Screenshot of Lens IDE showing a running QA staging environment.
• 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.

We additionally have event logging in our Akamai (formerly Linode) infrastructure management console.

Evidence

• Here are some screenshots of smon.
• Screenshot of Akamai event log