The Secure stage aims to ensure that applications developed with GitLab are not affected by vulnerabilities that may lead to security problems and unintended use. This can be achieved by covering the entire DevOps lifecycle with features that allow both security teams and developers to know if there is something that they should consider in their apps, before it is too late to create a fix.
The classic DevOps includes security testing as an activity in the Verify stage.
GitLab has a broader approach. That's why we introduced a Secure stage that is transversal to all other stages.
Our Product Vision for 2019 aims to provide security support for all the stages in the DevOps lifecycle: Plan, Create, Verify, Package, Release, Configure, and Monitor.
This is possible because GitLab is a single application.
There are many advantages coming from complete coverage of all the stages with security features. It allows to shift-left security at a very early stage, even before the first lines of code are committed. If you start with security as a priority when you plan a new app, it is easier than just trying to add security later. Security should remain on the radar even when the create process happens, to support developers and help them to write secure code from the beginning. Security testing can then happen for any change, before it is merged into the stable branch of the application: in this way you can spot problems and fix them before they risk affecting the production environment or the stable version of your app. Packaging the app should also be done with security in mind, as well as the release process to the production environment: at that point, your code is publicly available and any remediation will impact heavily on your processes. You should also not forget about security after your code is online: new vulnerabilities are spotted every day, and you want to ensure that your deployed application is always protected and monitored, so any new threat will be detected in advance and you can give a prompt security response in case something should be done.
The following features are part of the future of GitLab, and will contribute to completing the coverage of all the DevOps stages:
This list is just a slice of what we want to do to increase security for our users' applications.
Security is a never-ending priority, and at GitLab we want to make it easy for our users to manage it.
GitLab security features support users in prioritizing, managing, and solving any security issue that may affect their environment. The primary focus is to increase awareness on security (onboarding) and to provide all the information needed to take decisions about that.
The approach is to support decision makers, not to replace them. Instead of enforcing security, we want to give a very simple way to take the right action, and learn from it. Keeping it simple is a key value to prevent security features from being considered at all because they require more effort than the perceived benefit.
That's why security features are not supposed to automatically block a pipeline nor prevent a new version from being released to production. Even accurate results may be considered false positives as this is somewhat subjective by nature. Risk assessment will be mostly a human process.
Tools are actionable: it means that users can interact with them and provide feedback about their content. When triaging vulnerabilities, users can confirm (creating an issue to solve the problem), or dismiss them (in case they are false positives and there is no further action to take). This information will be collected to improve the signal-to-noise ratio that the tool could provide in future executions.
They also need to be easy to use, and require the minimum amount of effort from users: We don't want to add extra workload on final users. Otherwise, security checks will likely be disabled or not considered at all, missing their primary goal. Imagine if users had to explain why they are marking an email as spam every time!
We want to support security teams as first class citizens. GitLab should be their primary tool to manage monitoring and remediation of security issues. Using the Security Dashboard security specialists know exactly which is the most important thing they need to take care of, while Directors of Security can manage workflows and analyze historical data to figure out how to improve the response time.
This is a vulnerability-centric approach where items are grouped and ordered to suggest what's most important in a group, or in the entire instance.
Nonetheless, we want to support developers and provide feedback during the application development. Security Reports in merge request widgets and pipelines allow early access to security information that can be used to fix problems even before they are merged into the stable branch or released to the public, embracing the idea of shift left testing.
This approach is valuable to highlight how specific changes could affect the security of the application.
We expect that in most of the cases the number of potential security issues will be high, and we don't want that users will struggle in figuring out which is the impact of any possible item for their environment. That's why GitLab will prioritize security vulnerabilities based on different factors. The value given with this process is defined as the impact.
These are examples of factors that may contribute to define the impact for a specific security issue:
For now, security features are available in the Ultimate/Gold tier because we think that security matters for everyone, but automation of security in the development lifecycle is more valuable for organizations who want to optimize their DevOps investment to run securely at the highest business velocity.
We also want to collect and provide metrics to better understand how the security workflow is performing. For example, the overall time taken to deploy a fix for a vulnerability once spotted could be useful for flow improvements.
Every month, a couple of weeks before the start of the development cycle, the team meets to plan what will be done in the upcoming milestone. Decisions are based on our general prioritization principles, and we specifically consider case by case what is most important to do next, since we always have so many awesome ideas but we have to choose what has to be done first.
The PM maintains a product roadmap for the next three milestones and beyond, to ensure that we are focusing on important things ahead of time and we can prepare them properly. We are always ready to adjust our plans and we normally commit only to issues that are scheduled for the current release: this is very important in order to guarantee that we can be fast enough to react to unexpected events.
We want everybody to be part of our prioritization process, that's why all the information is public. We encourage team members, customer, and the community to give feedback and to share what they consider very important to focus on in the future. This is a valuable help to make GitLab a great product.
There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!