Since day one, our philosophy for building Vev has been to make what we wanted in a design tool and website builder with a focus on security and accessibility.
Much of the web remains the wild west in terms of security and if you've used other website builders you are familiar with the vulnerabilities from using plugins and third-party services.
Rest assured, the websites made with Vev are highly secure and they have privacy and security built-in by default and by design.
You probably need to convince the security department, sourcing department and the data protection officer that this is a done deal. Look no further, share this link with your team and let them dive into the details.
We know you are busy so we will get right down to business.
In Vev, Security and Privacy is something we strive to build into our product by design and by default. We rely on international and recognized standards to ensure we get the best of both worlds — from design and ease of use, flexibility and security.
This chapter will focus on how we build security into the products for our customers.
These are the standards, best practices and principles that we at Vev use in our daily work and that helps guide us:
Attack Surface Analysis - OWASP Cheat Sheet Series: We focus on keeping the attack surface as small as possible. This is most clearly shown in the export as ZIP functionality.
OWASP Top Ten Web Application Security Risks | OWASP: Used for general security awareness and as part of manual and automated test procedures
Software development with Data Protection by Design and by Default: General design principles for inspiration.
OWASP Application Security Verification Standard: General security requirement list for inspiration
CIS Controls™: Infrastructure checklist for inspiration
Software development with Data Protection by Design and by Default - Inspiration for our Vev Secure Software Development LifeCycle (SSDLC)
Microsoft Security Development Lifecycle Practices: Inspiration for our Vev Secure Software Development LifeCycle (SSDLC)
OWASP Code Review Guide: Inspiration for parts of our Vev Secure Software Development LifeCycle (SSDLC)
General Data Protection Regulation (GDPR) – Final text neatly arranged: GDPR article §25 Data protection by design and by default
When a designer works within Vev to produce digital content, they have many standard components available for the project. These different standard components & features are what creates the Vev Design Editor.
To ensure we help designers produce code that is to the highest standard of security and privacy, we follow certain principles.
We have strict security requirements for the code we produce, with these main principles in mind:
Self-contained and transparent code: We strive to produce an end product that can is as self-contained and transparent as possible. This is a key principle that helps our customers achieve flexibility in their usage of our product, achieve full control over the deployment and environment. This is also the key designing principle that enables us to achieve the level of security and privacy that we want.
Attack surface reduction: The produced code from the Vev Design Editor once produced and deployed, default does not contain any input fields, parameters or other user-supplied input. This severely limits the possible attack vectors that can be used against our end product. We do this, all the while delivering a design experience allowing your marketing and design departments to produce beautiful websites. There are only a few areas that need to be considered:
Content delivery network (CDN):
We use a CDN to keep our scripts, visuals up to date: “cdn.vev.design”.
For users with enterprise licenses, we can bundle the entire content to make you independent of a CDN or put content on your own CDN.
External links and scripts:
It is possible for designers to add “iframes” and “external scripts” to the code. These are components outside of Vev control, but for our enterprise customers, it is possible to set up admin alerts via email as part of the build process that contains information regarding external links.
It is possible for designers to add custom react code to the websites or add from NPM. This functionality is a super-user feature that gives increased control over your builds.
Privacy by default and design: The standard code produced by Vev is free from external references and user tracking code. The code also does not process personal identifiable information (PII), this is also a key reason why we do not provide areas for user input. GDPR article “§25 Data protection by design and by default” is something we are very aware of.
Enterprise customers also have the option of sending a notification to the Privacy Officer and/or the Security team regards to changes that might change what PII is processed and to keep internal registers of processed PII up to date.
Please note that if you use external sources outside features available in Vev, you need to manually take into account the privacy impact.
External links and scripts: It is possible for designers to add iframes and external scripts to the code. These are components outside of Vev control, but for our enterprise customers, it is possible to set up admin alerts via email as part of the build process that contains information regarding external links.
Code and scanning: For most of our users, the standard delivered components are more than enough, but for our enterprise users more flexibility is needed. So to ensure a secure website we scan the produced code with Static Application Security Testing (SAST) tools through the build process and Dynamic Application Security Testing (DAST) tools through Burp Suite - Application Security Testing Software to ensure the code is thoroughly vetted. The results are then sent to your security or DevOps team.
Enterprise customers using our extended library of addons, user tracking and custom code features will also receive access to:
3rd-party library updates and notification of changes
Static and Dynamic scanning of code including custom code.
Deployment email with details relevant for Security Teams, DevSecOps teams and Data Protection Officers.
Once the code is produced, we offer a variety of different hosting options. The most secure setup being export through ZIP files.
To enable automation we can also set up a secure transfer of the produced file to your organization through either SFTP, FTP, Amazon, or via Webhooks. These options are needed if you want to host the site on a subdomain in your control.
In order to facilitate DevSecOps pipelines and rapid development and deployment in your environment, we store the relevant secrets in our encrypted and locked database. Secrets can be retrieved through your HSM (Hardware Security module), Azure keystore or other token storage account. Enterprise customers will get access to audit logs for both user login to the editor and usage of the stored secrets — if this is enabled.
This is our secure and hassle-free hosting option for users with a domain ready.
When deploying code from Vev, the code will be deployed on our hardened web servers with proper HTTP Security Headers.
Please note that customers using custom code or using external references will not be able to set custom SPF records. For users wanting the option of setting strict SPF records, we recommend you host the code yourself.