“Bridging the divide between developers and security is our mission”

“Bridging the divide between developers and security is our mission. Another way of putting it is we want to empower developers to build secure applications without slowing them down.”

What does “Shift left” security mean and why is it important?

Gadi Bashvitz: “Shift Left” in security means moving the efforts to detect application vulnerabilities earlier in the software development lifecycle (SDLC). Traditionally, developers created the software, and once it hits production, security teams who are likely unfamiliar with it, are responsible for securing it. What “Shift Left” is trying to do is transition a big chunk of the responsibility for security into the hands of developers who will be responsible for securing the application throughout the SDLC to catch any vulnerabilities before they hit production.

It’s important because of two main reasons: The first is that it’s a lot cheaper to remediate vulnerabilities early on in the process. A study by Ponemon Institute found that vulnerabilities detected early in the development process cost an average of $80 to remediate, but if discovered in the production stage, those same vulnerabilities cost roughly $7,600 to fix, an increase of almost 100x.

Second, when vulnerabilities are left unaddressed until later in the SDLC, they have a higher likelihood of making it into production. Once in production, the application is exposed to breaches – and I don’t have to tell you that the costs of that can become astronomical.

Moving the security testing earlier enables security teams to perform quicker tests more often to ensure that the security is validated along the way, ultimately leading to a more secure product with a less costly testing process.

Why haven’t developers embraced DevSecOps as a concept? Why do so few own security?

Gadi Bashvitz: Why would they? As it is today, it’s a pain for a few reasons.

Organizations today are deploying 100x the number of applications into production compared with only a decade ago. With the pressure to finish applications and get them into production faster than ever before, developers hardly need another set of responsibilities on their hands to slow them down. Many security tools, and especially dynamic scanners (DAST), although they claim such integration into the CI pipeline, aren’t really built for it. The scans simply take place too late in the process and take too long, delaying production.

The other issue is that even if they were to embrace the idea of integrating security throughout the process, traditional security scanners create a bigger headache than they are worth with an inbox full of false positives. Many of the security tools today cannot validate the impact a vulnerability will have on an application, and so they issue endless alerts for every vulnerability detected, most of which ultimately aren’t exploitable. These empty alerts have the developers, what we at Bright call, “chasing ghosts” and spending inordinate amounts of their time trying to fix things that don’t really matter. The developers know this and it creates a negative sentiment towards the whole endeavor, and ultimately turns many away from attempting it altogether.

That being said, there is a growing realization among software engineering teams that security flaws are bugs like any other bug. No developer prides themselves on releasing buggy code, and so we believe that while it may not be a favorite task of developers, they eventually will embrace the DevSecOps mindset to ensure their code isn’t riddled with bugs.

What is the biggest pain point between DevOps and Security teams when it comes to securing applications? Why does it feel like they are against each other rather than on the same team?

Gadi Bashvitz: It’s because of what I just mentioned above. DevOps is about automation and speed; let’s automate as many tasks as possible to pick up the pace of development. Security, and especially dynamic testing, has traditionally not been a process that was amenable to automation and required manual, time-consuming and expensive processes such as Pen Testing. From a DevOps point of view, adding security into the process just breaks the whole process and slows everything down.

What does Bright Security do to solve this issue?

Gadi Bashvitz: Bridging the divide between developers and security is our mission. Another way of putting it is we want to empower developers to build secure applications without slowing them down. To do this right, we had to address a bunch of things, but here are two of the key ones.

First, you need to make sure there are no false positives. Traditional DAST tools had a bad rap among developers because they alerted about many things that weren’t real risks, for example, saying an input field is a SQL injection risk when there isn’t an actual database behind that field is a false positive, and asking a developer to fix it is a waste of man hours. We double-check each finding to make sure that we can really exploit it (without doing any damage, of course). We’ve benchmarked this against other tools and feel very confident that we don’t create these false flags, but also don’t miss real vulnerabilities. This gives the security team confidence in its wide coverage, but doesn’t frustrate the Dev team with unnecessary work.

Second, it’s critical to be part of the automated CI/CD pipeline. For DAST, this is easier said than done, because DAST scans used to take hours (sometimes days!). This may have worked in a world where you release software once a quarter, but our customers release multiple times a day. So we set out to see how we can reduce dynamic scans to minutes, even seconds, and we succeeded doing that with a number of innovative approaches. For one thing, we developed a way to run dynamic tests at the unit testing phase. This early in the process the scans take mere minutes or even seconds, enabling developers to check quickly and often. Furthermore, our system then learns which tests have already been run, and since no changes were made to that particular piece of the app or API, there’s no need to test them again, saving our clients from needless tests later on. In general, our platform does a fine-grained analysis of the application’s attack surface and is very smart about which tests we should or should not run.

What portion of the SDLC is Bright monitoring? What is it monitoring for?

Gadi Bashvitz: You say “monitoring” which implies a real-time thing, but we have a scanner, which needs to be triggered to run a scan. It can be triggered manually (via UI or CLI), or automatically – periodically, or via unit testing or CI/CD.

Where in the SDLC we operate is where we differentiate our approach compared to your grandmother’s legacy DAST solution. Traditionally, dynamic testing was done in pre or post production on the fully running app. Already in production, the scans took much longer to complete and vulnerabilities were far more expensive to remediate. As mentioned above, we first moved it earlier in the process from production to integration testing (via CI/CD). We then shifted it even further left to the unit testing phase with a very unique approach that integrates through an SDK, and with a growing list of native integrations to web and testing frameworks.

I want to take a moment to explain why this was a breakthrough. Dynamic security testing is by definition something that tests a running application. The whole idea is to view the app as an attacker would – from the outside in. This is in contrast to SCA or SAST, which are static tests that look at the code. But unit testing, as your readers well know, is about testing small pieces of code, not a whole app. What we did was “wrap” the snippet that’s being tested in a way that it can simulate running an application. We can then perform a true dynamic scan.

There are obviously a lot of security solutions already available, so how is Bright’s approach to security different to other solutions on the market?

Gadi Bashvitz: I know the alphabet soup of security solutions can be very confusing: SCA, SAST, DAST, IAST, GRC, RASP, etc. In a perfect world companies would use all of them to get maximum coverage, but in reality they can’t always do that. We believe that dynamic testing (DAST) is a must, because it is the best way to test the app or API in a way that views it exactly as an attacker would.

But as I already mentioned, traditional DAST had many drawbacks that we’ve eliminated: no false positives, fine-grained view of the attack surface, short scans, developer-friendly remediation instructions, automation throughout the SDLC.

There’s one more area where I think we stand out, and that is addressing business logic vulnerabilities (BLVs). This is a class of vulnerabilities that are often overlooked and can be very severely exploited by bad actors. BLVs are particularly tricky because exploiting (and detecting) them requires an understanding of the application’s flow and business purpose, and finding them has traditionally relied on costly and error-prone manual testing.

Awareness of BLVs is so low currently that unlike CVEs for technical vulnerabilities there is no naming or classification system. Our researchers at Bright are identifying them and classifying them with proper names. Our automated solution thoroughly analyzes the application’s flow, understands the context, and tests the system through a multitude of interaction combinations, eliminating the need for manual processes.

What is the future of Application Security?

Gadi Bashvitz: Some of the trends that are already in motion are going to strengthen even more.

• Shift Left: We opened this interview with that. Moving more and more types of security testing earlier in the SDLC.
• Developer-First: Shifting left requires that developers are increasingly responsible for security. For vendors and companies it means they need to provide tools that are developer-friendly and we’ll see the AppSec market start to shift from security-oriented solutions to ones that also focus on the needs of the developers.
• DevSecOps: To make all of this work, it has to be automated. So DevOps practices and security testing must come together.

Lastly, on the threat side, business logic vulnerabilities are going to become an increasing threat on companies and individuals. They are difficult to detect, especially in an automated way, but as an industry, we have to wrap our arms around this issue. These vulnerabilities have the potential to cause massive damage.

What is the demand for your platform? What kind of response are you getting from developers?

Gadi Bashvitz: Demand has been strong from two directions. Top-down, we are being approached by CISOs and AppSec leaders from the largest financial institutions, governments, telecoms, ecommerce, and tech companies. We now have dozens of these enterprise customers.

Bottom-up, we’re seeing developers of all sorts simply signing up for our free SaaS offering and starting to scan their applications and APIs. In fact, more than 6000 dev teams from around the world have already done that.

What’s really exciting and encouraging for us is that even when it’s a more traditional top-down, enterprise deal, these large organizations are still looking for a developer-first approach. Their intention is that developers will be the main users, while the CISO’s office or AppSec team will only provide guardrails and compliance guidance.

The post “Bridging the divide between developers and security is our mission” appeared first on JAXenter.