[0:33] The Attack Chain and Application Security Scanning

Petko: We're going to talk about something that's targeted today. We hear about all these attacks but we never say the why or we make it more broad. We want to talk about web security, application security.

Rachael: Let's dig into it because this is a hot topic. We could spend days on this but let's go ahead and jump in into it with our guest this week. Patrick Vandenberg, he's director of product marketing at Invicti Security, welcome.

Patrick: Thank you for having me Rachael and Petko, I'm really excited to be here.

Petko: Every single day we'll hear about someone exposed some data or something came out of some application somewhere. But then we blame the company but we never say why and everything else. I think I heard a statistic somewhere like 70% of the security incidents are related just to web attacks.

Patrick: It's a good starting point because all of these attacks are an attack chain. There needs to be step one break in or access point. I think you're referring to the Verizon data invest data breach investigations report. I think is that 70% stat where 70% of the incidents had the web application as that incident or attack vector.

That's a huge amount and I think the IT landscape is so complex to try to defend the whole thing. Certainly phishing, malware, everybody's thinking about that and not clicking on that bad link. Being very conscious companies doing their security training, that's absolutely a prominent first step attack vector.

 

Massive Application Deployment

Patrick: But I think that might catch a lot of people off guard if they haven't seen that stat. Seven out of 10 incidents start from a web application being attacked. What's behind that is the sheer volume of applications that are being deployed.

We can go even into the pandemic where there was an accelerated pace of applications being deployed to support a lot more remote activity. From even just supply chains that might not have been thinking to the degree to which they are now using applications but suddenly needed to more workforces. And what are the things that can make that work?

Well, we've known for a long time that the typical behaviors are get me that functionality first, support the business. Everything else is going to have to play catch up. And what's the outcome? Well, we have a 70% outcome there that Verizon shows us.

There's so much activity on endpoint or EDRXDR and real threat activity in day-to-day response. Everybody hears about the breach activity. So, the immediate security operations responses get a lot of airtime attention and certainly necessary budget. I'm not taking away from any of that.

I've had multiple roles in those areas. I think this does reset the importance of application security that has a bit of a different mindset to things.

You can't just update a policy to fix a misconfiguration on an application. You need to coordinate with a development team here to get this done. And we'll explore this over the next 20, 30 minutes here. But it takes a lot of intention and investment to take care of this in the right way.

 

People vs Web App

Petko: I think most organizations, they think of themselves as, "Hey, I bought an app, I bought a SaaS service or something else, it's someone else's problems." But we're finding out that more are bringing developers in-house and creating custom apps that could be exposed.

The report I was thinking of is actually an IBM report that came out. It talked about some of these breaches. They're the ones that said seven out of 10. So, that's everything that IBM is seeing so it's not just Verizon but also IBM's view of demand of services. But it's interesting to me is they say it's connected to a web app.

So, just because you might have been attacked by ransomware, that might have started with a credential that was harvested from a web app.

Or they might have scanned your web app and figured out your infrastructure and then went after you. So, that same percent is not that it's fully 100% the web app but that's where they start. Patrick, I'd love to get your take.

As for the audience, you typically hear, "Hey, we need an endpoint, it's the human's fault or it's don't click on that link," yet we forget about the app that could be 70% of the problem.

What are the most common vulnerabilities for applications that you're aware of that's happened over the last couple years?

Patrick: So, in application security, we trust the common source, the Owasp top 10 to tell us which ones. In conjunction with the national vulnerability database as well, that has all the instances of each of these vulnerability types.

 

[6:20] The Vulnerabilities: Broken Access Control

Patrick: The last top 10, the latest project for this list, it's a 2021 version they tend to update it every three or four years or so. Broken access control is the number one as of a couple of years ago, number one vulnerability. Injection vulnerabilities,

I think it's dropped to number three this year, but oh, sorry, the most recent one in 2021. That's a blend of SQL injection and cross-site scripting. We'll get to this maybe a little later but in our report we saw some trending activity for those vulnerabilities. That's interesting.

A few more to cite that from there security misconfigurations, cryptographic issues or failures, all the way down to server-side request forgery. So, that's the trusted source that we go to for the vulnerabilities to keep an eye out. Remote code execution vulnerabilities definitely have had a bit of an upswing in the past few years as well.

That's worth noting that we saw in our data.

Petko: Are there any specific breaches that come to mind when you start thinking of some of those web security vulnerabilities? Any specific incidents that are top of mind?

Patrick: Yes, it would definitely go to the log for shell vulnerability breach that we saw a few years ago. That's the source vulnerability and that's remote code execution volume. That was massive and what we saw from that is behavior change actually in the industry.

So, we saw a ripple effect both from the attacking side to find more similar vulnerability types. And I think what was the spring for Shell is another example coming from that. But then we also saw an increase in scanning patterns as a result. 

 

Application Security Scanning Compliance

Patrick: It's a cat and mouse game, definitely see that dynamic. We also saw some mandates catch up to, for requirements from an ISO to require DAST scanning. So, it's not just optional. It's not just an annual compliance audit recommending increased cadence on the testing.

Just the fast pace of updates, dynamic apps that we're seeing that you can't just scan once deploy and forget these applications anymore. We're seeing some concerns and we're seeing some improvements as we might expect from these results.

Petko: Rachael, any one of those that sparks your interest or I'd love, I don't know where to start. I feel like all of them were major that I had to deal with personally, I remember.

Rachael: Can we go to the beginning of these things? Where does it go off the rails? Because Log4J was a big deal, people were freaked out. How does it get to that scale and to be so massive before we're like, "Oh hey, check this out." Is it possible to go back to the beginning of something like that and figure how it became so big and why we didn't maybe catch it sooner?

Petko: I'm just using Log4J as an example and Patrick, you and I talked about this previously. Always being in security, you always think of defense in depth. You think of this layered approach of security. I've got my proxies, I have my firewalls, I have all this stuff.

That one little app in the back, all this stuff should take care of you before it gets to the app. But in the Log4J or Log4Shell, as long as some piece of data went into the app as a log, as a piece of string, it would get executed. 

 

Digging Through a Mosh Pit of Codes

Petko: As it goes through the web app, through the backend, through the database, through the logging what would happen is Apache's log for as part of Apache's Log4J, it would actually end up executing that piece of string.

Something that was supposed to do basic logging became now an execution of that app at the bright privileges. It was beaconing home in some cases.

No one ever thought to have that type of depth that would go from just a piece of text that someone put in it somewhere, as long as it gets logged, it got executed. I'm sure the network security team said, "Oh, we have all this defense in depth," the CISO said, "Hey, we have all this defense in depth," but in that case it didn't matter. Patrick, did I say that correctly?

Patrick: Yes, you did. To Rachael's point, there's so many branches and evolution of code that it's one galactic mosh pit of libraries and functions and code. I'm just making silly statements here but it gives a visual. What I'm trying to bring to light there is how do you get a team or an individual that's so focused on delivering some functionality.

To be aware of every possible situation in the full history of every piece of code that they might be involved in their project. 

That's the challenge, that's the complication. It requires a tremendous amount of diligence combined with tools and collaboration on teams' parts to be able to contain that even along with, as you say, Petko defense in depth measures that are in place.

We can touch on a few of those, so it's absolutely a nonstop effort. And I think it's another example of there's many cases just in security. 

 

[12:30] Application Security Scanning Measures

Patrick: Unfortunately, the maturation path frequently has a bad situation or a situation that looks awful with all of the issues, threats, vulnerabilities you might have in a system. Then the combination of those methods I mentioned before start to improve that over time.

Unfortunately, you don't get exposed. But I think this is a situation where the industry recognized, as well as SolarWinds, as well as Stuxnet that okay, look, there's a whole other facet that we didn't realize. We need to apply some combination of tooling and best practices to be better and improve our situation.

I think for application security that that's the constant gain in AppSec.

Petko: So, for application security, what are the common practices or measures you might see an organization take that is worried about their applications?

Patrick: I think most common that would come to mind and maybe it depends where you're coming from right now, but certainly DAST or dynamic application security testing. That's the one, it's the oldest. It's what pen testers would use to interact with the applications just as an attacker would.

So, we absolutely need that kind of testing methodology. 

I would tongue in cheek say it's where you start and finish actually because it's your first step to getting your testing done, it's the easiest way. And then when you go through the coding and secure design and it gets deployed. It's the last testing that you want to continuously still have on that application.

So, that's a very important methodology. But as I mentioned a few times and we all agree, the expectation on deploying functionality point in these applications of support business, it just continues to accelerate. The scale of it continues to grow.

 

Securing Application Attack Surfaces

Patrick: The only way that application security teams can accomplish a mission of having secure application attack surfaces or removing an attack surface is having a full partner in the development organization. So, to do that, you got to get earlier and earlier.

While DAST is embedded right into the CICD pipelines now, which is fantastic, if you can get ahead of a lot of the low-hanging fruit with static analysis security testing so that the developers can root out possible or expected vulnerabilities much better situations.

Those are the common two, I won't delve too much into software composition analysis for the distros and exposing those vulnerabilities cause that's a whole other facet. If you can get DAST going and you can get SAST going and you want to take another step of maturity, then it really is about secure architecture design.

Introducing a phase where you are applying secure coding practices or measures. How am I dealing with sensitive data? Am I applying encryption where I need to? What authentication mechanisms are there so that you're starting out with a mindset and perhaps teaching your developers before they even get started? What has to happen and what needs to be avoided?

That's about as early as you can get. That's the essence in my mind of secure by design if you can get to that phase. Then there's another methodology that I'd mentioned as well is interactive application security testing.

All right, DAST is good, we want to test and run time so we can see actually how the application's behaving, how attackers would interact and try to exploit. But as we're doing that testing, we're always in a better, more mature state. The more we can help developers understand and remediate faster.

 

Static Application Security Scanning and Testing

Patrick: Interactive application security testing, for those of your audience that might not be familiar with it, is about instrumenting the code so that as you find vulnerabilities in a runtime test, in a compiled application, we can point to where in the code that vulnerability exists.

It simplifies the process for a developer. So, they don't want to have to do any research. They don't want to have to chase false positives and lose trust in the system. And they don't want to lose how much time for every instance of a vulnerability trying to find it in which piece of code.

So, that's where IAST can also be an advantage.

Petko: Patrick, can we break this down a little between SAST and DAST. What's the difference? I heard SAST in terms of SAST apps, so not static. But it'll be helpful for them to understand the difference between the two because I think it's key.

How do you define the difference?

Patrick: I could start with a loose analogy here and then explain both of them. And then maybe my lack of articulation of an acronym won't be a problem anymore. So, let's look at cars, car manufacturing for a second.

When an engine gets built at some point whether it's before the assembly line or before this engine as a module gets moved to the assembly line, somebody runs the engine to make sure that the engine component can work.

And think of that, okay, the inner guts of the car is exposed. Think of that as SAST testing, you can see line of code activity. So, the bare components of that future application you are working with.

 

Dynamic Application Security Scanning and Testing

Patrick: Now if we're buying a car, we actually want that car to be test driven so that we know it works. So, we've got to have that engine put in a car and connect and working with the transmission brake, steering all the other sensors of the car so that we know it's operating properly, safely, that's DAST testing.

So, we've got a test driver taking it for a car and seeing how it actually works. Seeing the suspension is taken through rough terrain properly, the brakes are working, the seatbelt's actually going to engage if it's a hard, all that kind of stuff. That's pen testing or that's DAST, dynamic application security testing.

Petko: What's interactive application security testing then if I take that to a step further, is that a formal test?

Patrick: You're catching me there because I don't have an analogy built out for IAST. It might be and we put sensors. Let me play with this for a second. It's a great question so maybe it'll help the audience. But don't hold me accountable if it doesn't work. Imagine we put monitors and sensors on the engine so that we could see the piston speed rates performance that are happening.

Then we could see the signals that are going from the transmission to the engine of the wheels or gears, all of the connected parts. It shows us the inner working so that let's say we press on the accelerator and the engine doesn't engage, there's a sensor somewhere that tells us this part didn't get the signal.

 

Interactive Application Security Scanning and Testing

Patrick: It's giving us a look at the inner workings of the car so that when we want to go troubleshoot, we know exactly where to look and fix the problem, that's what IAST provides for developers. You've got your test driver and now we've got either another person running a test module, reading these sensors that's coming back after that test drive with more information so that the engineers know exactly where to go to fix and troubleshoot the problem.

Petko: Actually, that analogy works. My mind went a different route, I was thinking, "Okay, dynamic is me testing the car, making sure it works. Interactive is when I've got some kids behind me jumping around while I'm trying to drive the car.

I find out there's new things I didn't know about it." So, it's not predictable as much but I guess dynamic does do that. It's an interesting space because in the static code analysis. A lot of organizations have their developer scan their code as their coding or they scan it in repositories. They find out a lot of times it's just pattern matching on unknown vulnerabilities.

It becomes noise after a while because it doesn't tell you if it's executed, it just tells you it's there. It could be dormant.

Dynamic is the actual code that's running and executing and you can see if there's a vulnerability. So, it's more realistic to pen testers or more realistic to the environment if we are worried about attackers. I've had experiences where with the static side, I'll have a thousand vulnerabilities.

I'm like where do I have my team start? It doesn't matter because they're not going to start if I give a thousand.

 

[22:17] The Initial Break-in Point

Patrick: It's such a simple but common big question where you start with. Actually, the immediate response there is severity classification of the vulnerabilities, whether it's critical and high. A lot of these organizations, they'll only be focusing on the critical within the highs.

The mediums are almost never touched and the lows never looked at because there's just too many.

Petko: How many of those organizations take the CVEs that click on a high and then adjust them based on the environment? Most don't either, right? So, after I feel like everything becomes critical, everything gets renumbered down it's one or the other.

Patrick: Being able to customize your prioritization of what to address based on what you might know is coming from a business-critical application or something, a basic marketing site. But we've also learned and back to our opening where we talk about initial break-in exploited attack vectors, there have been instances where some vulnerability enables an attacker to start communicating with backend servers through some simple site that wasn't business critical.

That's all they're looking for is that initial break-in point and then use other methodologies to expand the reach within.

Petko: So, Patrick, let's see if they get in, sometimes the app just crashes, takes down the business. Other times they might find a way, "Okay crash the app, let me see what else I can make the app do. Maybe I can get some data out of it.

Maybe I can have give me credentials." And that data credentials or even taking on the business to now service could be a form of this issue gets repurposed for another attack.

 

Having the Right Security Measures

Patrick: This is where other aspects of security, network design server deployment comes into play. You can have measures that can restrict, even if there's a vulnerability in an app, if you have your right measures, then that app that shouldn't have access to a database or secure server won't. In some case it does and that's where a lot of these incidents become breaches.

They're able to exploit a vulnerability in a web application, acquire the credentials that you mentioned or tap into a database and next step is deploying malware to invoke a ransomware attack or extracting the data itself. So, that break-in component is so critical even though it might just be one aspect of the full attack chain.

Petko: Patrick, are we looking at security wrong? And what I mean by that is it feels like we always focus on the impact and then we say, "Oh look at this one incident, this one user, this one piece got this piece." But they're not looking at the full attack chain when they think what happened before that? I enumerate all your employees on LinkedIn.

Before that, I scan all your infrastructure and IPs, your tax surface and I found the weak ones. Then I used your employee's names to go after you. 

I guess what I'm getting at is that sometimes I think we focus on the ransomware that happened or that one employee that clicked an email. But they're not focusing all the stuff that the pen test, dynamics game that happened before that which isn't just a web app, it's all over a lot of things.

 

The Reality of Application Security Scanning

Patrick: That is, how can I say this? That's a massive loaded question. And I'm not trying to be flippant there, it really is. My initial thought is, the IT landscape is so complex and evolving faster than it ever has been. I am not saying anything new or enlightening there but it is.

There's more functionality being pushed, there's more hybrid environments to deal with than ever before. My view of security has always been every facet of the IT landscape you have you need a commensurate IT security component to cover that if you really want a fully secure situation. But that's not feasible, it's not realistic. We just know that from reality. That's why we have air gap systems because you just cannot contain and control.

So, where can you mature your practices? Where can you implement a combination of training, tooling and maturation of those factors so that you're constantly improving? Yes, I think your question leads to potentially, okay, how can you get to as close as possible, 100% secure state but we can't get there so what's the better path to take?

And I think just looking at application securities and microcosm and the maturation I quickly alluded to by going through the different methodologies that can be employed, start with DAST. You definitely want SAST, static analysis security testing as well.

But if you can get into secure by design considering secure architecture, your software first so that the buildup of that application starts in a much better state than you have less issues to deal with down the road and your team starts to learn and become smarter. 

 

[28:31] Application Security Scanning: The Chicken and Egg Situation

Petko: I was going to say that's what I was getting at is why don't we, are we overlooking application security was my thinking.

We focused on the endpoint and all this stuff out here and saying, "Hey let's forget about that app, just get out the code as quickly as possible." I keep thinking back to the Capital One breach and other things we've seen where it was a multiple different elements there. No matter how big you are, you're spending money on security there's always something you have to worry about.

If you're a CISO do you secure your apps first or do you secure your people and endpoints that they're running on? If you had to pick one, which do you do first? My gut feel is you go to the one that's got the most noise in term.

Patrick: That's a really interesting question. If you have an episode dedicated to that one and some experts coming on, I definitely want to hear that episode. It’s really difficult, it's a non-start, you're not going to control all human behavior.

But do you have a chance to contain, if not perfect, the security state of all your web assets that are exposed externally for example? I think you have a better chance of having layers of coverage for that from the processes that you can build up in your software development pipeline combined with your web app firewall protections that you can have in front.

So, given the scope and given the push for functionality, it hasn't changed. I think my first experience in application security was over 15 years ago. The dynamics really haven't changed of "everybody," everybody wants the app and the functionality of first security come second. 

 

It Has Gotten Worse but We Improved with It

Patrick: We've had a decade and a half to improve our thinking, we're getting close to a generation here. Has it changed or gotten worse? I'd argue it's gotten worse because it's functional response first all the time. Have we improved along with it though?

Absolutely, absolutely. But initially it was, "Hey we've got this idea here that we can test an application for security flaws before it gets deployed. Let's do scan it once and deploy it."

That was first gen and that was a good thing. Then we started to realize, "Okay, well maybe we need to scan it a little more often. How about a compliance audit once a year?" Make sense, and oh by the way, we're relying on development.

And those early years was really interesting for developers to even care about it in the first place. SAST starts to come along in its early state, so you start to see some improvement, let's call this a second gen. Now we're at a situation where we have these fantastic integrations, these multiple phases and a much better awareness to try to tackle these problems early in the process.

Because I think there's enough awareness now to know that if development doesn't get in involved, there's impact to all of their key success, key results that they need on sprint by sprint, quarter by quarter basis impacts the businesses very directly.

So, dev has to partner with security and vice versa to get this done, we're in a much better state for that. But we're also at a state where we realize we need to move to continuous automated scanning. There's so much functionality that's being pushed out, so many applications that are being deployed for functionality first.

 

Increased Frequency of Application Security Scanning and an Improved Mentality

Patrick: More dynamic or higher frequency of fixes going out that we need the next generation of application security testing where you've got, you're moving more to continuous scanning, weekly basis of those same apps, especially with the dependency on third party code.

And why is that dependency high? Because we're going to the store, grabbing chunks of code that are already built and throwing them in and not even caring where that's coming from. The advanced organizations will have secure code libraries to leverage that they can trust. But they're on the leading edge and even they have a very regimented, well-invested program.

And they're still doing everything they can to catch up.

So, are we in a better state? In some ways you could say yes. Have we improved our mentality as a broad industry? No, because it's still functionality first. As long as that's the case, we need to continue to try to mature and expand and improve our processes.

As the pace picks up, that means we do need automation, we need scale and we need to move to this notion of continuous scanning. And we see some of those results actually from our report that there's some indications around those dynamics.

Petko: You guys just published a report. Was it an indicator report is what you called it or where can people find your report?

Patrick: It is actually going live or just went live the week of RSA. We're starting to roll that out and that that'll be up on our website invicti.com they can find that.

 

 

[34:14] Evolution and Adoption of Application Security Scanning

Petko: Awesome, I can't help but think going back to that CISO question, which do you invest in first? The endpoint or the application security side of it? Is there is a lot more regulation and compliance requirements around app security and dynamics scanning that should be done.

We've had folks on the podcast here before that were dealing with FedRAMP. FedRAMP requires dynamic application security testing is part of it that you're doing monthly or weekly or whatever interval you need to do it at.

I imagine there's other standards out there that if you have a product that you want to sell to a certain industry or if you have a product that you just want to make sure you're finding best practices that you're going to have to eventually do dynamic app security testing if you're not already.

Patrick: Yes, that's exactly what we're seeing. And I think generally speaking, the past few years or maybe even five years prior, we saw the surge of SAST adoption and software composition analysis bill materials, distribution package for the release which absolutely needed to happen.

And whether it was because of the pandemic dynamics, Log4Shell, president's executive order could be a confluence of those types of factors. We're definitely seeing an increased priority around dynamic testing.

The point there is and you see some analyst reports where the focus is around SAST and SCA as an example because it's more complex or it might be newer for some organizations who already have some aspect of dynamic application security testing.

 

Making Sure You’re Covered Through Application Security Scanning

Patrick: The mind sharing and the conversation shifts to that because there is more involved to get that embedded into the development process and it's the right thing to do. The attention needs to be there. But as humans, there's only so many things that fit in our buffer, our own brains at one time.

So, I think what's happened is there's a bit of a recognition that DAST is very critical. We're seeing some increasing adoption rates or scan rates to your point, Petko and FedRAMP and continuing testing. To that point in our report, we have seen a 50% increase in average scanning over the four years from our report.

If I have the stats, I think we're 19% year over year just in the past year.

The point there is we're seeing increased adoption of the scanning approach because of these needs from either from a compliance perspective or just a recognition after the surge of remote behaviors in supply chains and remote work that we're seeing that.

In fact, one of our industry perspectives coming out of the report, manufacturing stood out for us bit of an outlier where their average scanning rate per manufacturing customer is about three times the rest of the industries. It's definitely something we're going to pay attention to and explore for further reports.

But our understanding there is we're seeing a subset of customers that have adopted CICD and automated scanning. So, that surge is going up of scan rates which makes sense, it fits the conversation, they want to make sure they're covered.

 

Application Security Scanning Industries and Manufacturing

Petko: I typically think of DAST, if anyone wants to do business in healthcare and government and financial sector is like I have to do this in order to sell or in order to even work with them. Manufacturing is interesting, are there other areas that are growing this need?

How do we define manufacturing? My mind automatically starts thinking IOT devices and things like that that we've heard about. But are there other forms of manufacturing that are in that group, in that category or the industry?

Patrick: Did you say, I just want to make sure I heard you right it. Were you asking if, were there other industries or other forms of manufacturing it?

Petko: Both, let's go both, when in doubt go both.

Patrick: The answer is yes. So, first of all, manufacturing is an outlier for us as an industry. So, it's very interesting and we'll keep monitoring it. But what's exciting is we have the data, something's seen there and we'll continue to monitor it.

The majority of the industries that we looked at have quite steady year over year. Maybe I should just do a reset on the report because we haven't really done that. We've got into some interesting topics, but just a quick reset on the report.

We had 1.7 million scans included in this data set, 1,700 customers included in this data set. And probably the biggest takeaway that we saw from it is scanning rates of increased 50% from 2019 to 2022. That's average monthly scan rate per customer, that's what that one refers to.

 

 

Takeaway: Increased Application Security Scanning Activity Decreases Vulnerability Rate

Patrick: We've seen a decline in vulnerabilities, especially in the past year. In some cases going up now it's gone down 2021 to 2022. Massive takeaway there, as your scanning activity increases your vulnerability right rate decreases, first time we've seen that data.

The more you do this, the more you find vulnerabilities, the more repetitions your development teams and your overall application security practice gets to improve. And the more frequent you're scanning, the faster you're finding these vulnerabilities and your whole practice gets better, so your security posture improves.

So, we are seeing scan more, find more, fix more and improve your or reduce your risk as a result. That’s our biggest takeaway from this report. Getting back into the industry portion underneath that, as I mentioned, manufacturing's an anomaly. But the majority of the industries, consumer goods, education, energy and utilities, healthcare, what else? We have retail technology, they all have quite consistent, steady increases from 2019 to 2022 in their scan rates.

Awesome to see that we're seeing improvements. There is a couple anomalies where median entertainment and services industries are on steady declines.

We don't have enough data to explain that decline, why there would be year over year over year decline in scanning activity. But I bet you if the next breach we see of a major logo or brand and media or entertainment things will change again just as we saw in manufacturing for example. 

Petko: When you say scan rates, when you say scan rates, I'm curious is that count per scan as a scanning number of code lines? How is it quantified as a scan in that metric?

 

[42:09] The Future of Application Security Scanning

Patrick: Our tool is a DAST tool, we have IAST capability as well. This data set is based on DAST. So, this is a customer across enterprise and SMB or mid-market. The average amount of scan instances they're running on a monthly basis, that's what that stat is based on.

Petko: If I scan a whole cloud infrastructure with billions of apps in it, does that count as one or as a billion?

Patrick: In that case that would be a billion, it would be the apps that you're actually scanning. Think of it in terms of the target.

Petko: The targets, got it. When you define the target, you usually do it by web URL or something, got it. Okay, that's good data, you mentioned such a great data points regarding its growing. It is interesting that the media industry is either they're outsourcing more or they're building more simplified apps or more focused apps.

Where do you think we're going with this? Given the growth rates, what do you predict the future of the application security, just holistic landscape is going to look like for us in the industry?

Patrick: I'm processing that question. I went back to my first experience in application security and how I would've answered that question and projecting where we're going with it. Everybody has this idea of new innovation going to fix things and we touched earlier on just whether it's human nature, nature of business, there's truisms perhaps that we are always going to be dealing with.

Just like you'll always have somebody who's, regardless of how earnest they are in protecting the company's interest, we'll have an email and a link that's spoofing their CEO and they're just not paying attention, they click the link.

 

Functionality First Dynamic in Application Security Scanning

Patrick: We're always going to have this dynamic of functionality first. It's at its heart, the capitalist society which is going to drive that functionality. We also have the cultural shift demanding like no discipline in demand anymore for immediate results, which spills into all the functionality that we get just on corporate, personal, social level with the technology we're interacting with.

On that basis alone, application security will continue to chase with increasing status and the maturity of the application security practices.

Ten years ago it was aspirational of where the security practices may get to. We're at a point where a lot of companies have DAST and SAST and other technologies deployed. There's much greater collaboration between the app security and development teams to a significant extent and we're moving to this continuous state.

There's some parallels between technology, automation and intelligence and where application security is going to have this happen at scale on a very robust and continuous pace.

I don't see that closing outright. What's going to hit us in three, five, seven years down the road, that's going to change the dynamic again. Maybe I'm being optimistic with that long timeline, it could be sooner. Things have gotten worse from a challenge and complexity perspective for appsec.

At the same time there's been so much progress on the maturation of the practices and the teams involved. There is a dependency there because these scanning engines have to continue to evolve to track with the technologies that they need to explore, to identify the vulnerabilities of the weaknesses within.

I don't see this slowing down so it might sound like quite a non-definitive response to say it's getting worse and it's getting better. I think there's some truth to both parts of that statement.

 

 

Bringing Two Different Perspectives in Application Security Scanning

Petko: I was reading your last report because I always find it interesting when you look at the reports how they change from one report to another. And your fall report had an interesting comment in there, “release or die” and it shows you the pressure that developers are under.

It shows you that we really got to automate more and do it quickly and effectively. I think, you mentioned earlier, you have to automate, automate, automate its developers, developers, developers so we've got to just move faster. And definitely, hopefully we get there with more automation and orchestration and everything else that we talk about in security.

Patrick: Yes, very much agree and one comment there to let everyone know, our spring report is our data, for lack of a better term, that's our data focus report. And our fall report is a survey-based report of our customer base. So, it brings two really different perspectives to the market on an annual basis. So, looking forward to seeing what we might find out already in this falls report.

Petko: Yes, that'd definitely be interesting. Rachael, I've been doing all the questions, I'm sorry. What are you thinking?

Rachael: All I think about is when you hear apps, I just think about taking my TikTok away. Honestly, that's all I think about. I don't know, I saw there was a state that raised it. They were going to ban it in the state. It's going to the state legislature, just don't take my TikTok.

Patrick: That's a whole other security episode, right?

Petko: Rachael, I'm more worried about your dog app.

Rachael: Oh, my Furbo, yes.

 

[49:13] The Application Security Scanning Design

Petko: Yes, I don't know if it's secure or not, I have no idea. But the fact of having a camera in my house that can actually not just be video, but actually can mechanically change things. Next thing it's going to flood your house with water because it's trying to feed a dog. Hopefully not.

Rachael: I don't give very many updates for that app, I'll tell you that. So, I don't know how much they're scanning that Furbo.

Secure by design, that's right that's where they went. No, you know where I struggle with these things and I think it's the struggle of every business. You talked about this before Patrick is there's the business calculus, we got to get it out.

And these developers, they're already stretched pretty thin and you know have a lot of teams that are getting decimated. And so, now you've got one guy doing the three jobs or whatever it is and it's that prioritization of time. Much like the CISO, where do you prioritize your security investment in time?

These developers, it's like, well if I'm measured in getting the app out and that performance of set app and either the number of users that we've signed up an amount of time or revenue or whatever that is, it's very difficult to say, "Let me slow the process down.

"Even by a day or two to do the security and it's almost, is there a reinvention of how apps are developed? I think that ship is probably sailed, too. But when you start talking about going to the beginning, fundamentally that part's never going to change, unless how we develop applications fundamentally change.

 

Seeing Through an Attacker’s Point of View

Patrick: Some of the best practices that can be adopted are probably being looked at for the mature organizations, for the business-critical apps, but they're not doing it for basic web interfaces for marketing or info sites. Who's really paying attention to the security risk on a lot of those web assets as an example.

They might be and I'm not calling out organization, it's just a reality of the situation. We prioritize where the value might be from perceived from an attacker's point of view. You prioritize accordingly like we would with the vulnerabilities.

When there's so much going on, you're not getting to your ideal state of security. By the time you've made the decision, there's already a backlog of fixes and other apps or functionality being demanded as you pointed out.

Rachael: I love talking about these things that seemingly have really no resolve. It will get better, it will get worse. We just hope incrementally we start chipping away at a little more every five years, whatever that is.

Patrick: That's where I was just being brutally honest and responding to Petko's question, “Where are we going with this?” It's probably going to be a combination of continuing to get worse and get better at the same time. It depends on which lens you want to use to look at the situation.

I credit to the industry overall because the vulnerability rates have gone down even through revolution which we are seeing which is fantastic, at least across our customer base. Even though that IT landscape is changing, evolving and getting more complex than it's ever been.

Maybe that we can just settle with yes. It's getting better and we've got some good tools to work with to continue that.

 

 

Getting Worse and Getting Better

Petko: It's all our priorities and each of us have different priorities.

Rachael: That is true. Whoever made, it's genius, the algorithm. I just have to give it, I never thought I would spend so much time on something. It's horrible, the number of animal videos. I just like mini goats, mini cows who knew, who knew these things existed. 

Capybaras, that's been in heavy rotation the last few weeks. I didn't even know about Capybaras but now I know everything, I feel "smarter" I should say. And I could talk about that all day. I do would be mindful of time Patrick, thank you so much.

This has been such a wonderful discussion. I love that we really broke it down because we have a lot of our audience who's not as deep in this conversation. It’s important to start educating and understanding the landscape and what's out there, what's available and what's still maybe we need to advance on.

Thank you for taking the time to break that down, Patrick, it's been very helpful.

Patrick: Thank you for having me on, it's been a lot of fun. We've had some laughs with it too which is great. Hopefully we brought some insights to your audience. Thank you so much for letting me be a part of it.

Rachael: Definitely, and I'd love to include a link to your indicator report. I know folks would love to read that report. For all of our listeners out there, thank you so much for joining us again this week. And thanks to Petko for all the questions.

Until next time you guys, just be safe, be secure.

 

About Our Guest

 

A seasoned cybersecurity leader, Patrick Vandenberg is the Director of Product Marketing at Invicti Security. He works closely with security and DevSecOps stakeholders to understand today’s cybersecurity pain points so we can continue to help our customers solve their application security challenges.

As an alumnus of several cybersecurity companies, including Hunters, Snyk, and IBM Security, Patrick brings over 20 years of experience in cybersecurity across product marketing and product management roles. Patrick holds a degree in Systems & Computer Engineering from Carleton University and, in his free time, continues a longtime passion for coaching and playing hockey.