Introduction
This document provides a high-level overview of the security posture for the Mall on Rails project, including an overview of the identified threat model, references to security-related requirements, and links to any available reviews or audits.
Threat Model Overview
This document contains an overview of the threat model, including identified risks and mitigations. A full threat model with illustrations, data flow diagrams, and more extensive documentation can be found in the code repository where this document originated.
Security Requirements Reference
This document contains references to other documents where security requirements for the Mall on Rails system can be found. To ensure a single source of truth, these requirements are not duplicated in this document directly.
Reviews and Audits
This document provides links to any external security reviews and/or audits that have been performed against the system. This can include both automated and manual scans.
Preface
This document contains preliminary information about a forthcoming software product from Wilcox Technologies Inc.
The information contained within may not reflect the final product, and may change rapidly during the development process.
Always ensure you have the latest document revision before raising an issue.
Abstract
This document describes identified dependencies of Mall on Rails, a software project being developed by Wilcox Technologies Inc.
Threat Model Overview
Systems In Scope
The Mall on Rails application server, job server, database server, and the WTI SSO authentication server are all in scope for the MoR threat model.
Ancillary services, such as GitLab (a malicious MR), are not specifically included in the MoR threat model. It is assumed that the development team will carefully monitor any external contributions for security threats.
Threat Actors
We prioritise network attackers as our primary threat actor. These attackers are external to WTI, and attempt to breach the system over the Internet.
We view physical attackers as a lower priority, but still present. There are two classes: physical attackers who gain access to a WTI office, and physical attackers who gain access to the datacentre. We have multiple layers of redundancy in place to prevent data leaks in these cases.
We class internal threats as the lowest priority. We still defend against this by using the principles of least privilege, in-depth non-repudiable logging, and user account-based auditing.
Mitigation of STRIDE threats
We have mitigations in place for all forms of STRIDE threats. The specific mitigations in place per-threat are considered to be sensitive information, as we do not want attackers to be aware of the countermeasures we have deployed. Registered store owners can request a copy of our full threat model and report via WTI Client Care. Interested security researchers and open-source community members may reach out via WTI Open Outreach; however, those without a "need to know" may receive limited information due to the sensitive nature of security-related documentation. We appreciate your understanding as we work to balance the need of security and the need of the greater community.
Security Requirements
While there is no dedicated SRS for the Mall on Rails project, the Software Quality Specification contains requirements pertaining to the three major axes of security (Confidentiality, Integrity, and Availability). Additionally, a further axis of Observability has been added to the SQS, which assists in both non-repudiability and availability.
The Software Quality Specification may be found in the same location as this
document, in the quality
directory.
Any security requirements identified during development cycles that are not documented in the SQS will be listed in this document.
Reviews and Audits
This section contains information on the security reviews and audits that have been performed against the Mall on Rails codebase, and when possible, a link to their results. The date of the most recent review/audit is also provided.
Semgrep (Continuous, Automated)
Semgrep is an automated platform that provides the following reviews:
- Static scan (SAST)
- Supply chain vulnerability scan (SCA)
- License compatibility scan
SAST
Semgrep SAST rates Ruby and the Rails framework as "generally available", meaning it is mature and commercially supported. Through Semgrep Pro, we additionally have more Pro-exclusive rules that we take advantage of.
SCA
Semgrep SCA supports reachability analysis, which is whether a vulnerable portion of a dependency is used or not in the project. It can also identify malicious dependencies.
Last report
Semgrep is run as part of our CI/CD pipeline, and each merge request is tested before merging to the current branch.
At the time of this writing, 2025-04-13, it has identified 16 issues. 13 have been flagged as "False positive". Three have been flagged as "acceptable risk", which are detailed below:
-
lib/active_setting/setting.rb:128
lib/active_setting/setting.rb:133 -
Rule violated: avoid html_safe
Reason: We use HTML Settings for HTML content provided by the storefront owner. This is intentional and by-design. - app/controllers/orders_controller.rb:40
-
Rule violated: avoid redirect
Reason: This is required to be able to render order success pages for guests.
A full report, including all false positives, can be obtained by any current store owner via WTI Client Care. Interested community members may request a copy of the full report in CSV format via WTI Open Outreach.
glsa-check
(Continuous, Automated)
Systems on the Finland hosting platform that run Gentoo Linux sync their
Portage repository nightly. After they complete the sync, each server emails
the output of glsa-check -t affected
to the administration team.
When discovered, vulnerabilities are triaged within 24 hours, and resolved on a timetable congruent to the risk.
Risk Category | Required Time to Fix |
---|---|
Critical | 24 hours |
High | 48 hours |
Medium | 72 hours |
Low | 10 days |
Last report
At the time of this writing, 2025-04-13:
host01 ~ # glsa-check -t affected
This system is not affected by any of the listed GLSAs
host02 ~ # glsa-check -t affected
This system is not affected by any of the listed GLSAs
ldap01 ~ # glsa-check -t affected
This system is not affected by any of the listed GLSAs