Gadi Bashvitz, Bright: “companies must ensure security is part of the design of the product”
Our guest today believes that security testing should be done as early as possible in the development lifecycle.
As the world gets more connected, it is no surprise that threat actors are constantly on the lookout for vulnerabilities to exploit. With vast amounts of software and applications being released every minute, experts believe that a new development approach must be taken – one where security is weaved into the product from day one.
To talk about the importance of the security-first approach, we invited Gadi Bashvitz, the Co-founder and CEO of Bright Security – a company ensuring that no vulnerability goes unnoticed in the software development process.
How did the idea of Bright originate? What has your journey been like so far?
With roughly 70% of the vulnerabilities affecting companies today originating in the application layer (Apps or APIs), it became clear that proper application security (or AppSec) is one of the most crucial areas of need in cybersecurity. Looking at the market and the solutions, we realized that the legacy security solutions in the space were fast becoming antiquated and were not able to keep up with the pace of modern DevOps practices. We wanted to create a solution that addressed the key issues the market was facing as this issue will only grow more pressing as the rate of software development continues to increase.
The most important trend, as we saw it, was (and still is) “shift left”, or the idea of moving security testing early on in the software development lifecycle (SDLC). Earlier testing will lead to a more efficient security process and prevent vulnerabilities from ever making it to production, but while the concept is great, the execution hasn’t been.
Dynamic Application Security Testing (DAST), which is the process of testing the security of the running application from the outside-in, was an area that we identified as in need of some innovation. The legacy DAST solutions were not built for developers, but for AppSec experts, and were not suitable for a world in which software releases happen multiple times a day. The flaws in these older solutions led many developers to avoid using them altogether as they were more of a hindrance than a help. We set out to create a DAST solution that not only worked for the needs of developers but one that they would want to use.
The journey so far has been incredible. It’s very exciting to see both large banks and leading global Cybersecurity companies, on the one hand, and small dev teams, on the other, rely on our platform to secure their apps. We’ve learned a ton along the way, such as the importance of business logic vulnerabilities, the need for securing APIs – not just human-facing apps, and how to make it so developers actually WANT to use the product.
Can you introduce us to your application testing platform? What are its key features?
Bright is a Dynamic Application Security Testing (DAST) platform built for software developers. The solution approaches applications from the outside, mimicking how a hacker would approach the application, and automatically tests for vulnerabilities that bad actors could use to exploit.
Unlike legacy tools which were designed exclusively for expert security users after the application is already in production, Bright’s tool was built to be “developer-first”. It was designed to empower developers to create more secure applications and APIs starting in the development phase and across all stages leading up to and including production so that vulnerabilities are caught and remediated earlier.
To truly be a dev-centric platform, we needed to develop some key features that align with how developers prefer to work:
- Setup takes minutes and there’s no need for security expertise – we take care of all that
- No false positives: Our special technology automatically verifies that any vulnerability it detects is actually exploitable so that devs don’t waste time remediating vulnerabilities that aren’t a threat
- Remediation instructions that make sense: If a scan detects an issue, the developers received easy-to-follow remediation guidelines with the information developers need to fix it
- Control everything with code: Although Bright has a great UI, developers love using our CLI and API that lets them control everything
- Scans take minutes instead of hours or days: Bright’s unique approach allows you to scan only the relevant parts of an app so that you don’t have to slow down the build process – including for unit testing!
- Seamless integration with the developer toolchain: Bright works with existing CI/CD pipelines – trigger scans on every commit, pull request or build with unit testing. It can also automatically add tickets to Jira, GitHub, Azure Boards, GitLab, and other systems.
And while we hope developers will love working with Bright, we also want to make sure security teams can rely on it. No tool out there has more comprehensive testing coverage than Bright, and that includes business logic vulnerabilities and API scanning.
What would you consider the main challenges development teams run into nowadays?
The biggest challenge for development teams is keeping up with the pace of today’s world. Developers today are releasing 100x more code into production compared to only ten years ago, and so the challenge becomes developing and releasing software at a much faster pace, while still ensuring that it is both bug-free and secure. To do that, you want as much automation throughout the SDLC as you can put in (aka DevOps). The issue developers face is that securing software before it’s released – without a platform such as Bright – is a tedious, manual, and time-consuming process. Today, almost 90% of organizations are knowingly releasing vulnerable applications and APIs into production because they can’t detect and remediate vulnerabilities quickly enough. These vulnerabilities take an average of nine months to be fixed, leaving organizations exposed for considerable periods of time and we’re working to change that reality.
How do you think the recent global events affected the way people approach cybersecurity?
On the macro level, the increase in attacks is just accelerating the growing understanding of the importance of addressing cybersecurity flaws. Companies are repeatedly seeing the financial and reputation fallout from cyberattacks and hacks and are placing a premium on cybersecurity, which is becoming a key factor in purchasing. Nobody wants to buy a product that isn’t secured, and so companies must adjust to ensure security is part of the design of the product and incorporated throughout the process.
Part of that is accomplished by moving all forms of security testing earlier in the process (i.e., shift left). And that’s a place where we are seeing a massive change in attitude – especially among developers. Developers are quickly coming to the realization that security vulnerabilities are bugs (but often with more severe consequences). And as no developer prides themselves on releasing buggy code, they also want to make sure they release secure apps.
What are the most common vulnerabilities nowadays, that if overlooked, can lead to serious problems for a business?
At the application level, which is where we live, we’re seeing that the most common vulnerabilities are indeed the ones that are on the OWASP Top Ten and similar lists, which enable attacks such as SQL injection, cross-site scripting, CSRF, and XXE. There’s a fairly good awareness level of these vulnerabilities, which we call “technical vulnerabilities.”
That said, there is a whole different class of vulnerabilities – business logic vulnerabilities (BLVs) – that are still 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.
In your opinion, what kind of tests and checkups should every company conduct regularly?
In a perfect world, companies should use all of the tools in the toolbox: SCA, SAST, DAST, IAST, GRC, RASP, etc. But as important as what tests they run is when they run them. It is much more cost-effective to run the tests as early as possible in the cycle. DAST was traditionally employed when the application was already fully developed and running (in pre-production or production), but fixing vulnerabilities at that point is both expensive and risky.
There have traditionally been many challenges in running DAST during the development phase. For one thing, traditional dynamic tests take many hours, even days, and running a test that late in the process often creates unaffordable delays in production.
We’ve developed smart ways to analyze, understand and break down the application’s attack surface so that we can run short tests that only cover what’s relevant at that point.
Another issue with legacy DAST was that it created many false positives – indications of potential flaws in the system that aren’t actually exploitable. Developers hate these false positives because they end up “chasing ghosts” having to remediate dozens of “vulnerabilities” that actually don’t really matter. It slows down the whole process and has actually turned many developers away from DAST tools. We’ve eliminated that issue by intelligently verifying that each issue we discover is actually exploitable.
Once you’ve solved these issues (and a few others we won’t get into), you can now automatically run DAST tests with every build via the CI/CD pipeline throughout the development lifecycle.
What are the best practices companies should follow when developing, and, when launching applications?
When it comes to application and API security, the key practice is to automatically run tests with every build as part of the CI/CD pipeline. This is sometimes called DevSecOps. At Bright, we fully embrace DevSecOps practices and developed deep integration into CI tools such as Github Actions, GitLab, CircleCI, Jenkins, TeamCity, and others to ensure that you can integrate with any platform to test as early as possible.
We’ve even taken it a step further that allows developers to run a DAST scan at the unit testing phase – one of the earliest points in development. This was especially challenging because dynamic security tests, by definition, scan a running application, but unit tests are for snippets of code. We developed a way to run those snippets as if they are a fully-formed application and then scan them.
We’re actually seeing how this is changing our customers’ behavior. Moving the process earlier has enabled customers to test earlier and more often and has increased the average from running four scans a month that take seven hours each to run hundreds of tests that take three minutes each.
Talking about personal cybersecurity, what measures do you think everyone should implement to protect themselves from emerging threats?
A few of the practices I religiously follow are using multi-factor authentication whenever possible and using a different password for everything (which requires a password manager). Hackers are always looking for easy targets, like the person whose password is “password,” and I think that for personal security practicing the basics will go a long way towards keeping you safe.
What does the future hold for Bright?
The future is bright (pun intended). We’re quadrupling down on some of the things I mentioned here, such as broader and better coverage of business logic vulnerabilities, and making dynamic security testing easier and more automated.
We’re especially focused on making our DAST scanner developer-friendly. That has many aspects to it, such as providing remediation guidelines in a way that’s easily understood by developers, not AppSec experts; and intelligently configuring the tests we scan for based on the target and past tests. We also want to make sure the solution scales with the needs of our customers, some of whom are among the world’s largest organizations.
We are very focused on serving our dozens of enterprise customers and more than 6,000 development teams using our product. We are constantly learning from our community and working with them to perfect a truly developer-centric DAST solution that is easy to deploy and helps organizations build secure applications and APIs.
To read the original story, please visit CyberNews
