The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Secure |
| Maturity | Viable |
| Content Last Reviewed | 2022-07-14 |
Thank you for visiting this category direction page on API Security Testing at GitLab. This page belongs to the Dynamic Analysis group of the Secure stage and is maintained by Derek Ferguson (dferguson@gitlab.com).
This direction page is a work in progress and everyone can contribute:
API Security is a broad category that incorporates everything from API discovery and management to DAST API and API fuzz testing to active API defense. GitLab's initial focus in API Security will be on DAST API scanning and API fuzz testing. As the category matures, we will explore expanding into API discovery and management and active API defense.
GitLab was recently named as a Challenger in the 2021 Magic Quadrant for Application Security Testing.
API Security currently supports REST, GraphQL, and SOAP APIs.
As API security has historically been the domain of security teams, rather than developers, testing the API in its running state often is overlooked during the development process. Since this type of testing requires an application to be deployed, the attack surface of the running application is usually not evaluated until the application has passed through the development cycle and is deployed to a staging server (or worse, to production!). Testing this late in the SDLC means that developers have little to no time to respond to any vulnerabilities that are found and trade-offs must be made between fixing vulnerabilities and releasing on time. This can lead to vulnerabilities being released into production either as a calculated risk or with no knowledge of the vulnerability at all.
We see API security testing as an ideal collaboration point between established security teams and developers, leading to finding and fixing vulnerabilities earlier in the SDLC and reducing the number of vulnerabilities released to production. By integrating API security into their pipelines and leveraging review apps to dynamically test applications, developers can be more conscious of the security impact of their code on the running application. This awareness enables them to take the initiative to fix these issues before merging features into the default branch. Similarly, the security team member can take a proactive, rather than reactive, approach to security by reviewing pipeline results or running on-demand scans and creating issues for any vulnerability found earlier in the SDLC. All of this allows these teams to work together to reduce the overall risk of deploying new code to a production application.
Our goal is to provide API Security scanning as part of the standard development process. This means that API security is executed every time a new review app is available or a build is deployed to a server.
Since API Security requires a running application, we can provide results for feature branches leveraging Review Apps, temporary environments that run the modified version of the application. We can also provide results for applications running on other servers, such as staging or development environments, either through a CI/CD pipeline scan or a manually-triggered on-demand scan.
API Security results can be consumed in the merge request, where new vulnerabilities are shown. A full report is available in the pipeline details page.
API Security results are also a part of the Security Dashboard, where Security Teams can check the security status of their projects.
We also want to ensure that the production environment is always secure by allowing users to run an on-demand API Security scan on a deployed app even if there is no change in the code. On-demand scans will allow for out-of-band security testing and issue reproduction, without needing any code changes or merge requests to start a scan.
We are integrating the Peach API Security scanner into DAST to give us an immediate and major improvement in DAST API scanning coverage, configuration, and confidence. As soon as the API Security scanner is integrated, we will gain capabilities that will increase the number and type of APIs that we are able to scan. The new scanner allows for specifying API endpoints via Postman collections and HAR files, adding onto the OpenAPI specification we support currently. It also gives access to scan GraphQL and SOAP APIs, rather than being limited to REST APIs. Improved authentication support for more authentication methods is another major improvement that we will gain with the integration of the new scnner. This scanner was released as a beta feature in GitLab 14.1 and we are actively working on issues to release it as a GA feature.
As a part of bringing the API Security scanner to GA for DAST API, we are working on a number of speed improvements. Integrating any security test into the CI/CD pipeline brings the question of how long these tests will take to complete. We believe that while our API Security scanning is already fast enough for a large number of users, there is still room for some major improvements. We have already seen improvements of ~30% faster tests and expected to see even faster test times as more optimizations are put in place.
Moving past the GA of the API Security scanner, we want to address one of the biggest pain points in getting started with API Security testing - the lack of proper API specifications or definitions. While many organizations recognize the need to scan their APIs for security vulnerabilities, they often don't have a full API specification or definition (or any specification or definition at all) that they can use to configure the test. Since APIs cannot be discovered by crawling it in the same way you'd crawl a web application, API testing has to start (at a minimum) with an input of which API endpoints are available. Even better is being able to tell the test what methods the endpoint accepts and having example data to seed the test inputs. Currently, our API Security tests accept multiple inputs to help define the API that needs to be tested. OpenAPI specifications, Postman collections, and HAR files all provide the basis on which our tests are run. However, with our current capabilities, you need to provide those to the test yourself, rather than relying on a feature in GitLab to generate them. We want to be able to use the source code that is housed in GitLab to automatically build a specification as a step during the build process. This would be a separate job within a pipeline that output the specification as an artifact. After the artifact is available, it could be used to automatically configure an API scan, rather than relying on you manually adding the spec yourself. As the first step, we are going to focus on Java Spring Boot projects and automatically building REST API specifications for these projects.
We have an advantage of being able to provide testing results before the app is deployed into the production environment, by using Review Apps. This means that we can provide API security scan results for every single commit. The easy integration of API security scanning early in the software development life cycle is a unique position that GitLab has in the API Security market. Integrating other tools at this stage of the SDLC is typically difficult, at best.
We want to engage analysts to make them aware of the security features already available in GitLab. They also perform analysis of vendors in the space and have an eye on the future. We will blend analyst insights with what we hear from our customers, prospects, and the larger market as a whole to ensure we’re adapting as the landscape evolves.
