MVSP: the security baseline that gets startups through procurement

1.1 External vulnerability reports

Appropriate processes are in place to accept and process external reports of security issues in your products and/or services.

MVSP requires:

• Publish a vulnerability disclosure policy that outlines the testing scope, provides a legal safe harbor, and gives contact details for security reports
• Develop and document procedures for triaging and remediating reported vulnerabilities
• Respond to reports within a reasonable time frame
• Patch vulnerabilities consistent with Control 3.4

On VendorDeck you are asked: Do you publish a vulnerability disclosure policy with a security contact and a legal safe harbour?

1.2 Customer testing

Appropriate processes are in place to allow customers to safely and effectively perform testing against your products and/or services.

MVSP requires:

• On request, enable your customers or their delegates to test the security of your application
• Test on a production or a non-production environment that closely resembles the production environment in functionality
• Ensure non-production environments do not contain production data
• Reasonable restrictions on testing can be defined

On VendorDeck you are asked: Will you let customers, or testers acting for them, security-test your application on request?

1.3 Self-assessment

Annual reviews of your application security controls are performed for each qualifying product or service in order to identify corrective actions or areas of continued improvement.

MVSP requires:

• Perform and make available security self-assessments for each qualifying product/service, using the latest MVSP release, at least annually

On VendorDeck you are asked: Do you complete an MVSP self-assessment at least once a year?

1.4 External testing

Processes are in place to schedule and perform regular third-party penetration testing against your products and/or services.

MVSP requires:

• Contract a security vendor to perform comprehensive penetration tests of your products, services, and dependent systems, at least annually

On VendorDeck you are asked: Do you commission an independent penetration test at least once a year?

1.5 Training

Processes are in place to provide regular and ongoing security awareness training. Example areas of training that should be considered are: >- Applicable company policies >- Proper data handling and protection of sensitive information >- How to report suspicious activities

MVSP requires:

• Implement role-specific security training for your personnel that is relevant to their business function

On VendorDeck you are asked: Does your team receive role-specific security training?

1.6 Compliance

Relevant compliance obligations are identified and completed based on your companies industry and regulatory requirements.

MVSP requires:

• Comply with industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18
• Comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as GDPR, Binding Corporate Rules, and Standard Contractual Clauses
• Ensure data localization requirements are implemented in line with local regulations and contractual obligations

On VendorDeck you are asked: Do you comply with the security standards and data-protection laws that apply to your business, such as UK GDPR?

1.7 Incident handling

Processes are in place to ensure the smooth handling of security and privacy incidents.

MVSP requires:

• Notify relevant parties about any security breach that affects sensitive information no later than 72 hours upon discovery, and upon learning any additional details of the breach
• Consider reporting the breach to relevant national cybersecurity agencies in line with local guidance and regulations
• Include the following information in the notification:
  • Nature of the breach
  • Relevant contact information
  • Consequences of the breach
  • Measures taken, or needing to be taken, to remediate the issue

On VendorDeck you are asked: Do you notify affected parties within 72 hours of discovering a breach?

1.8 Data handling

Data stored on removable or decommissioned hardware is appropriately handled.

MVSP requires:

• Ensure media sanitization processes based on NIST SP 800-88 (or equivalent) are implemented for storage media holding unencrypted production data

On VendorDeck you are asked: Do you securely wipe storage media holding unencrypted production data before disposal or reuse?

2.1 Single sign-on

MVSP requires:

• Implement single sign-on using modern, maintained, and industry-standard protocols for all customers at no additional cost

On VendorDeck you are asked: Do you offer single sign-on to all customers at no additional cost?

2.2 HTTPS-only

Sensitive data is encrypted in transit between the end-user and your product and/or service.

MVSP requires:

• Redirect traffic from HTTP protocol (port 80) to HTTPS (port 443) (This does not apply to secure protocols designed to run on top of unencrypted connections, such as OCSP)
• Scan and address issues using freely available modern TLS scanning tools
• Include the Strict-Transport-Security header with a long max-age value
• Set authentication cookies as Secure

On VendorDeck you are asked: Is all traffic HTTPS-only, with HSTS enabled and authentication cookies set as Secure?

2.3 Security headers

Appropriate browser protections are in place within your product and/or service to protect against common web threats.

MVSP requires:

• Apply appropriate security headers to reduce the application attack surface and limit post exploitation:
  • Set a minimally permissive Content Security Policy
  • Limit the ability to iframe the application by enabling framing controls with X-Frame-Options or CSP frame-ancestors
  • Disable caching for APIs and endpoints that return sensitive data

On VendorDeck you are asked: Do you set a Content Security Policy and framing controls on your application?

2.4 Password policy

Appropriate controls are in place to protect users who opt to use password-based authentication.

MVSP requires:

• If password authentication is used in addition to single sign-on:
  • Do not limit the permitted characters that can be used
  • Do not limit the length of the password to anything below 64 characters
  • Do not use secret questions as a sole password reset requirement
  • Require email verification of a password change request
  • Require the current password in addition to the new password during password change
  • Store passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash function
  • Enforce appropriate account lockout and brute-force protection on account access
  • Do not provide default passwords for users or administrators

On VendorDeck you are asked: If you offer password login, does your password policy follow modern guidance?

2.5 Security libraries

Standardized libraries are used to improve the security of your product and/or service.

MVSP requires:

• Use modern, maintained, and industry-standard frameworks, template languages, or libraries that systemically address implementation weaknesses by escaping the outputs and sanitizing the inputs

On VendorDeck you are asked: Do you use maintained, industry-standard frameworks that escape output and sanitise input?

2.6 Dependency patching

Processes are in place to identify, and maintain up-to-date components within your product and/or service. Vulnerabilities that are known to be exploited are appropriately prioritized.

MVSP requires:

• Ensure third-party dependencies are maintained and up-to-date, with security relevant updates having a severity score of "medium" or higher applied in line with your application patching schedule
• Upon becoming aware of a Known Exploited Vulnerability affecting a third-party dependency, the patch should be prioritized
• Where dependency patching or upgrades are not possible, equivalent mitigations should be implemented for all components of the application stack

On VendorDeck you are asked: Do you keep third-party dependencies patched on a defined schedule?

2.7 Logging

Appropriate logs are stored to assist with debugging and incident response activities.

MVSP requires:

• Keep logs of:
  • Authentication events (success and failure)
  • Create, Read, Update, and Delete (CRUD) operations on application and system users and objects
  • Security relevant configuration changes (including disabling logging)
  • Application owner access to customer data (access transparency)
• 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 at no additional charge, and should not contain sensitive data or payloads.

On VendorDeck you are asked: Do you log authentication and data-access events and retain them for at least 30 days?

2.8 Encryption

Sensitive data is encrypted at rest within your product and/or service.

MVSP requires:

• Use modern, maintained, and industry-standard means of encryption to protect sensitive data in transit between systems, and at rest in online data storages and backups

On VendorDeck you are asked: Is sensitive data encrypted in transit and at rest, including backups?

3.1 List of data

Information on the type and amount of data handled by your product and/or service is available for threat modeling or incident response purposes.

MVSP requires:

• Maintain a list of sensitive data types that the application is expected to process

On VendorDeck you are asked: Do you maintain a list of the sensitive data types your application processes?

3.2 Data flow diagram

Information on the flow of data through systems is available for threat modeling or incident response purposes.

MVSP requires:

• Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored

On VendorDeck you are asked: Do you maintain an up-to-date diagram of how sensitive data reaches and is stored in your systems?

3.3 Vulnerability prevention

Appropriate developer training on common security issues is performed.

MVSP requires:

• Train your developers and implement development guidelines to prevent at least the following vulnerabilities:
  • Authorization bypass — Example: Accessing other customers' data or admin features from a regular account
  • Insecure session management — Examples: Guessable token; a token stored in an insecure location (e.g. cookie without Secure and HttpOnly flags set)
  • Injections — Examples: (No)SQL injection, LLM / Prompt injection, XXE, OS command injection
  • Cross-site scripting — Examples: Calling insecure JavaScript functions, performing insecure DOM manipulations, echoing back user input into HTML without escaping
  • Cross-site request forgery — Example: Accepting requests with an Origin header from a different domain
  • Handling untrusted data — Example: Reusing data supplied by users within sensitive application contexts

On VendorDeck you are asked: Do your developers follow guidelines covering authorisation bypass, injection, XSS and CSRF?

3.4 Time to fix vulnerabilities

Identified vulnerabilities are patched within a reasonable time frame, and customers are informed where appropriate.

MVSP requires:

• Produce and deploy patches to address application vulnerabilities that materially impact security within 90 days of discovery
• For vulnerabilities with evidence of active exploitation, production and deployment of patches should be prioritized
• Publish a security bulletin that details the vulnerability and its root cause if the remedy requires action from customers

On VendorDeck you are asked: Do you produce and deploy patches for security-impacting vulnerabilities within 90 days of discovery?

3.5 Build and release process

Build processes are fully scripted/automated and generate provenance.

MVSP requires:

• Must use a version control system and consistent build process that generates provenance describing how the artifact was built (SLSA Build Level 1)
• Sensitive application credentials and tokens should be stored separately from the application’s source code

On VendorDeck you are asked: Do you use version control and a consistent build process, with credentials stored outside the source code?

4.1 Physical access

Sensitive data stored or accessible from trusted locations is secured effectively.

MVSP requires:

• Validate the physical security of relevant facilities by ensuring the following controls are in place:
  • Layered perimeter controls and interior barriers
  • Managed access to keys
  • Entry and exit logs
  • Appropriate response plan for unauthorized access

On VendorDeck you are asked: Are the facilities holding your systems physically secured, with entry logs and a response plan?

4.2 Logical access

Access to sensitive data is tightly controlled and regularly reviewed.

MVSP requires:

• Limit sensitive data access exclusively to users with a legitimate need. The data owner must authorize such access
• Deactivate redundant accounts and expired access grants in a timely manner
• Perform regular reviews of access to validate need to know
• Ensure remote access to customer data or production systems requires the use of Multi-Factor Authentication

On VendorDeck you are asked: Is access to customer data limited to those who need it, reviewed regularly, and protected by MFA?

4.3 Sub-processors

Understand where you may be sharing data with third-party sub-processors, and that suitable processes are in place to validate their security posture.

MVSP requires:

• Maintain a list of third-party companies with access to customer data, and make it available to clients and business partners upon request
• Assess third-party companies annually against the latest MVSP release

On VendorDeck you are asked: Do you maintain a list of third parties with access to customer data and assess them annually?

4.4 Backup and disaster recovery

Processes are in place to ensure backup and recovery of your product and/or service in the event of a disaster.

MVSP requires:

• Securely backup all data to a different location than where the application is running
• Maintain and test disaster recovery plans in concert with your incident response planning, at least annually or after significant changes

On VendorDeck you are asked: Do you back up data to a separate location and test your disaster recovery plan at least annually?