Security capabilities are off to a great start!
This page represents how Forrester views our SCA capabilities in relation to the larger market and how we're working with that information to build a better product. It is also intended to provide Forrester with ongoing context for how our product is developing in relation to how they see the market.
"As developers continue to use open source to accelerate the release of new application functionality, remediation, policy management, and reporting will dictate which providers will lead the pack. Vendors that can provide developers with remediation advice and even create patches position themselves to significantly reduce business risk."
"GitLab is off to a fast start, but security pros will find developer focus frustrating. GitLab has been offering security products since 2017 and now offers static and dynamic analysis in addition to binary SCA. However, some of the developer use case-focused features of SCA will be uncomfortable to security pros. For example, the dismissing feature gives developers the ability to dismiss any vulnerability of any severity. This forces security pros to keep careful track of what vulnerabilities developers have chosen to ignore. Also, GitLab’s leaning is not to stop the build via quality gates. Instead, it recommends using a reviewer feature, which causes security pros to manually review the status of each build."
For our first official security-oriented analyst evaluation, we are excited to be included among the ten vendors evaluated and proud of where we stand for our very early security capabilities. This was a great opportunity for analyst feedback and objective insight into how GitLab compares. We take to heart not only areas where we shine - but also where improvement is needed. Based on this analyst report and analyst interaction feedback, we are already addressing improvement opportunities in our roadmap and vision. We also welcome your contribution and invite you to help us understand what you would like to see as our security capabilities grow.
As a company dedicated to releasing incrementally, delivering first on breadth and then on depth, it is not uncommon for GitLab to initially place in more of a challenger position, as our feature set generally does not have the same maturity as established players in the space. However, when GitLab enters a space, we do so boldly, with clear intentions and a solid strategy. GitLab’s strategy for application security testing and software composition analysis focuses more equally on both the developer and the security professional than traditional solutions. You will find some areas in strategy where we were not scored as highly as we believe we should be due to our more aggressive focus on development.
Forrester's takeaway above regarding developers continuing to use open source is closely aligned to the GitLab vision for application security testing and our work in progress for auto remediation. While not available in the evaluated version (11.6), a subsequent release can now detect a more current patch available and enable the developer to create a new branch and apply the patch with one click. Upcoming versions will automatically run the pipeline and present the results to the developer to accept or reject.
GitLab has provided a major new release every month for 90 consecutive months. Forrester evaluated version 11.6 for this report while versions 11.7, 11.8 and 11.9 have since been released. You will find several features that Forrester felt were lacking have already been added including improvements to the security dashboard, additional languages added to SAST scanning, and secrets detection.
Specifically, we have added the following since 11.6 was evaluated:
Note that as of August, 2019, the GitLab License Management capabilities have been renamed to License Compliance.
Dismissing vulnerabilities We understand that some security professionals may be uncomfortable that a developer can “dismiss” a vulnerability found in a scan. Vulnerabilities that are dismissed by the developer are still included in both the pipeline report and the security dashboards. Security can easily revert the dismissal if they disagree. If security wants to review every dismissal, they are easily identified. We are also adding the ability to capture comments for the dismissal to aid in communication between the developer and the security team. This aligns with our focus on providing as much visibility into all activities as possible to speed and simplify collaboration while maintaining accountability.
Quality gates A gated waterfall approach to security is incongruent with an iterative DevOps methodology. That is why GitLab’s preference is indeed to not “stop the build via quality gates”. For application security testing to scale alongside DevOps, developers must be empowered to find and resolve vulnerabilities on their own - without becoming security experts. Our vision is that many of the vulnerabilities will be fixed via auto remediation where the developer is informed of the fix, and may choose to review/approve but does not need to do the remediation tasks themselves. In the meantime, we recognize that some enterprises may still want a gated review. We currently offer merge request approval rules to aid in this workflow. With planned Security gates, GitLab will introduce a way to enable approval rules only if critical vulnerabilities are introduced with the new code, so the security team can focus on reviewing only those changes. We want to be clear that using manual approvals is not a requirement of the tool, though it may be a requirement of the user’s policy.
Policy management As a result of this report, in addition to Security gates, we have reprioritized adding the ability to block the merge request if blacklisted licenses are found, enabling users to set the policy and have it automatically enforced by GitLab.
Roadmap execution To put it simply, we disagree with Forrester’s assessment of this aspect. In fact we invite you to form your own opinion, taking into consideration that we are the only vendor that transparently publishes the entire roadmap, we have delivered a product, capable of consideration on the Wave in just over 18 months, and anyone can contribute.
Product vision Our principal takeaway from the Forrester assessment of product vision and buyer need alignment is that developer and security professional’s opinions on both the current and future state of good security practices continue to vary significantly. We do believe that empowering development to more easily achieve good security practices is the right approach and will continue to empower better Dev-Sec-Ops collaboration. For more on how we intend to do that, see the GitLab vision at: https://about.gitlab.com/direction/secure/.
SDLC integration Much like the difference of opinion regarding our roadmap and vision, we think that the value we provide in our complete SDLC product (no integration needed, but you can if you want to) is both compelling and competitive for DevOps teams, developers and security professionals working with those teams.
For those who want to integrate other tools into GitLab CI/CD in order to include the results from other scanners in the GitLab pipeline report, we offer many integrations including:
Build tools
IDE
Repositories
Browser extensions
Blacklisting/whitelisting In this analysis, we feel our Blacklisting/whitelisting capabilities may not have been fully appreciated. In addition to blacklisting a license from within the pipeline, we can also automate blacklisting with predefined lists in the manage project settings. This automation will apply to all further changes (merge requests) in the project. Each project can have its own policies. GitLab will also support defining policies at the group level, making life easier if multiple similar projects are in the same group.
Bill of materials How does the product proactively control or restrict components that don't meet policy guidelines from entering the SDLC? GitLab already has a way to determine which component is vulnerable using Dependency Scanning. It also has a similar check for license compliance. We know this capability needs to improve, and our plans are to provide a new dedicated view where dependencies are the main focus.
Reporting Reporting is intended for the developer in the pipeline report where he/she will also find all of the security scans (SAST, DAST, Container, Dependency, and License Management). For the security professional, unresolved and dismissed vulnerabilities are shown across projects in the Security Group Level Dashboard. Upcoming improvements to the dashboard include features targeting Security Directors, with metrics like showing mean time to resolution.
We believe GitLab is ideal for the enterprises who are: *Using GitLab for CI/CD *Practicing iterative development via DevOps *Using containers and serverless
For the enterprise that has not invested in app sec tools, GitLab can quickly provide scanning, often necessary for regulatory compliance, with one single application. GitLab offers SAST, DAST, Dependency, Container Scanning and License Management with one app - no need to evaluate and buy from multiple vendors then stitch together integration with the DevOps toolchain.
For the enterprise already deeply invested in traditional app sec tools, GitLab affords a broader and earlier scanning effort, using a tool that developers are already using. GitLab can scan every code change, much the way that every airplane passenger gets scanned through TSA security. Save the deeper scans for later and/or less frequent evaluation. Consider using GitLab on select projects to experience the more efficient workflow and potentially reduce your scanning costs from costlier tools.