The GitLab team summit recently took place in Cape Town, South Africa, which, as you can imagine, promised to be memorable. When preparing to cross three continents over 22 hours on airplanes, you think carefully about what to pack. You are anticipating the most beautiful scenery ever and want to make sure you capture it in pictures. So you find your camera – the one you haven't used in a long time because you've grown accustomed to using your cellphone. After careful debate, you decide to take it because those awesome experiences and scenery deserve the best camera.
The camera requires certain things: You have to make sure it's charged or has batteries; it needs to have adequate storage; you may need additional lenses which also require special care. Everything must be protected and carefully packed, and requires additional space and weight to carry on board with you because it's too precious to put in checked baggage.
When you get to South Africa and you see this incredible scenery, you take out your wonderful camera and you realize a few things:
1. You have only a precious few moments to capture the image
Do I really have time to fidget with f-stops and customizations, or do I just want to capture the picture and perhaps customize it a bit later by cropping and adjusting the light?
2. It's difficult to share camera photos immediately
I'm anxious to share these images with friends and family back home. It occurs to me that with my phone I can share images immediately and effortlessly by email, text, Slack, or a variety of social media. If I take the pictures on my expensive camera, I can't share them immediately because it's not connected to anything. I'll have to wait until I get back to my hotel room so I can take the flash drive and put it in my laptop, log on to the Wi-Fi, and then share my images.
3. My camera photos aren't secure
If I lose that flash drive, all of my images are gone (unless I back them up immediately after capturing them – not likely!). While it is possible I could lose my cell phone and lose my pictures, it's less likely. My phone is an integral part of my daily workflow – an appendage even. How often do we feel naked if we forget our phone at home or even in the other room? I'm much less likely to leave my phone on the bus when I get off to explore then to leave my camera behind.
So, I choose to use my phone to capture these magnificent images. My primary objective is not taking fabulous pictures worthy of publication that I can sell or frame on my wall, but to take pictures that are good enough, that capture the special place, and that I can share with friends and family easily and effortlessly. If it's too hard to share, I may not do it, or it may take me a long time. In addition, I don't have to think ahead about how my phone will capture an image in such a way to send it to friends; the images automatically integrate with all of the other sharing mechanisms on my phone. It simply works. I am free to focus on my primary effort of capturing the images while I soak up the moments.
Now, how does this relate to cybersecurity?
Companies invest a great deal in application security to test their software for security vulnerabilities. It's a separate application that requires its own budget and maintenance. Like the specialized camera, the information it creates must be shared in order to be most useful. The security team can use it by itself, but to be truly effective, the vulnerabilities found must be shared with development so that they can be corrected. Yet developers have little interest in logging onto a security system to access the data. Would your friends and family want to physically turn on your camera to look at your pictures? Maybe, but it's very limiting as to whom you can reach.
The challenge then is how do you get the data found by the application security system into the hands of the developers? Today that is one of the greatest challenges to overcome, even in rare cases where the objectives of security and dev totally align.
What if you looked at application security the same way we look at photographing images?
Is the prime objective to do the most eloquent job of finding the vulnerabilities? Or, is the prime objective to get the vulnerabilities that we do find fixed? If it is the latter then the primary issue must be integrating with the developers’ workflow.
With GitLab application security testing, it is like the camera on your phone – maybe not superior to a dedicated tool in isolation, but good quality, and more importantly, integrated into the workflow to be the most useful. It is easily and efficiently used without added thought. With GitLab, every commit and every merge request is tested. There isn't even a separate step – it's all automated for you without additional effort.
As with photography, the most important thing is that you capture those moments before they escape you; with application security testing, it's important that you capture those vulnerabilities so that you can act upon them. With GitLab, the vulnerabilities are shown right there in the developers' workflow. They don't have to log into a different system nor interrupt their work. The security vulnerabilities are shown right alongside any other application flaws in the pipeline results of each merge request. The developer can choose to fix them now or continue the build, but either way, the vulnerabilities are captured and logged. And now with the security dashboard, the security team can evaluate further and create an issue for remediation if needed.
The vulnerabilities are shown right there in the developers' workflow. They don't have to log into a different system nor interrupt their work
This really does turn application security on its head! It puts the insight and tools for action into the hands of the developer and then shares results with security, rather than the other way around. It makes so much more sense because the developer must do the remediation, not the security pro. Imagine the efficiency gains if most of the effort was placed on eliminating the vulnerabilities up front, rather than on finding and tracking them later in the SDLC! Sound familiar? This has been imagined before and cost savings even estimated. It's the "shift left" mantra. While everyone embraces it, few actually achieve it. Why? Because they lack the tools to enable such a seismic shift where the only gate is the merge request.
Albert Einstein said that the definition of insanity was doing the same thing and expecting a different result. So how can we expect traditional application security methods to meet the needs of modern, cloud-first DevOps environments? We can't. With GitLab, our single application helps users efficiently develop and deploy secure code by leveraging the power of integration across the entire SDLC. No more stitching together complex DevOps tool chains. Microsoft did something similar years ago. Remember Word Perfect? It succumbed to Word because content could be copied/pasted and integrated across the Microsoft suite of documents, spreadsheets and slides. GitLab is on track to do the same thing for software development – including application security testing.
What do you think? Is this a new era of app security?
Photo by Clyde Thoma on Unsplash
