-
Publish the point of contact for security reports on your website
-
Respond to security reports within a reasonable time frame
Minimum Viable Secure Product is a minimalistic security checklist for B2B software and business process outsourcing suppliers.
Designed with simplicity in mind, the checklist contains only those controls that must be implemented to ensure minimally viable security posture of a product.
We recommend that all companies building B2B software or otherwise handling sensitive information under its broadest definition implement at least the following controls, and are strongly encouraged to go well beyond them in their security programs.
1 Business controls | |
---|---|
Control | Description |
1.1 Vulnerability reports | |
1.2 Customer testing |
|
1.3 Self-assessment | Perform annual (at a minimum) security self-assessments using this document |
1.4 External testing | Contract a security vendor to perform annual, comprehensive penetration tests on your systems |
1.5 Training | Implement role-specific security training for your personnel that is relevant to their business function |
1.6 Compliance |
|
1.7 Incident handling |
|
1.8 Data sanitization | Ensure media sanitization processes based on NIST SP 800-88 or equivalent are implemented |
2 Application design controls | |
Control | Description |
2.1 Single Sign-On | Implement single sign-on using modern and industry standard protocols |
2.2 HTTPS-only |
|
2.3 Content Security Policy | Set a minimally permissive Content Security Policy |
2.4 Password policy | If password authentication is used in addition to single sign-on:
|
2.5 Security libraries | Use frameworks, template languages, or libraries that systemically address implementation weaknesses by escaping the outputs and sanitizing the inputs. Example: ORM for database access, UI framework for rendering DOM |
2.6 Dependency Patching | Apply security patches with a severity score of "medium" or higher, or ensure equivalent mitigations are available for all components of the application stack within one month of the patch release |
2.7 Logging | Keep logs of:
Logs must include user ID, IP address, valid timestamp, type of action performed, and object of this action. Logs must be stored for at least 30 days, and should not contain sensitive data or payloads. |
2.8 Backup and Disaster recovery |
|
2.9 Encryption | Use available means of encryption to protect sensitive data in transit between systems and at rest in online data storages and backups |
3 Application implementation controls | |
Control | Description |
3.1 List of data | Maintain a list of sensitive data types that the application is expected to process |
3.2 Data flow diagram | Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored |
3.3 Vulnerability prevention | Train your developers and implement development guidelines to prevent at least the following vulnerabilities:
|
3.4 Time to fix vulnerabilities | Produce and deploy patches to address application vulnerabilities that materially impact security within 90 days of discovery. |
4 Operational controls | |
Control | Description |
4.1 Physical access | Validate the physical security of relevant facilities by ensuring the following controls are in place:
|
4.2 Logical access |
|
4.3 Subprocessors |
|
License
This document is public domain under CC0 1.0 Universal license.