Shielding Your Supply Chain: Strengthening Security Measures with Francois Proulx

Host: Hi, everyone! This is Purusottam, and thanks for tuning in to ScaletoZero podcast. Today, we have a guest who is focused on, who has spent a lot of time in supply chain security, and application security. So I'm super excited. So the guest is Francois. Francois is a senior product security engineer for Boost Security, where he leads the supply chain research team.

He has over 10 years of experience in building AppSec programs for large corporations such as Intel, and also has worked for smaller startups as well. He has been in the heat of the action as the DevSecOps movement took shape. And he's one of the founders of NorthSec, and he was a challenge designer for the NorthSec CTL. It's wonderful to have you in the show.

Do you want to briefly share about your journey?

François: Yes, hi. Thanks for having me. Yeah, as you kind of mentioned in the introduction, I've been focused on application security for now over 10 years. Before I was a software engineer, so I started my career writing code like any other engineer. But when I left college, that's kind of a...

I didn't have a formal kind of security training in the university, just like software engineering, but it was the case that I have always been interested in security since early childhood. So whenever I, as soon as I started to get into programming, like computers in general, security has always been a focus of mine, just that got into college software engineering and eventually went into...

AppSec and security in general, like full-time. But it's been a nice journey, like joining a small startup about 10 years ago and being acquired by Intel, like managing application security at a large scale.

It's been like, and then now back to boost security, which is creating a product to help security teams like manage the sheer complexity of the AppSec programs, modern DevSecOps environment. So it's been a very good journey.

Host: Lovely and I'm looking forward to learn some of the things that you have built or learned as part of your career. So let's start right. But before we start, one of the things that I ask every guest is

What does a day in your life look like? Because I get different answers from everyone. I'm curious. What does a day in your life look like today?

François: Sure. Yeah, that's what I like about my job now at Boost is that I get to think, I get to dream, I get to build the product that I would love to have used in the past. So that's really what convinced me to join the team here and to actually, I'm one of the very first employees and came in with that expertise, that know-how of managing application security and small, medium, large enterprises, knowing the challenges, the expectations of those companies at the different stages of maturity, and just keeping up with the industry.

So like now at Boost, my day looks like a split between product aspects in the sense of like thinking what the product should be, like defining its features of it.

Talking with customers, I have different onboarding meetings with customers to understand their needs as it evolves. Like kind of industry news, kind of just keeping up with like best practice, the new things, like new threats. As well as doing code review, like just threat modeling, updating, spread between kind of all the piece, like more like business side as well as very technical where I lead my security research team that's kind of coming up with new threats, like being on the forefront of the supply chain research.

Host: That sounds exciting because you are doing both the product side and also from the engineering side also, right? So that you are helping your organization stay secure. So yeah, that's a good way. Let's start. So today we are going to talk about a few topics, right? Both supply chain and application security. Let's start with the application security.

So a few months ago, Forbes published an article that said that application security is not a developer's first problem.

So we'll tag this blog when we publish the video. And it highlights two things, right? One is developers are not trained for security because, and also they are not hired for security either because they are hired to solve engineering problems.

So what's your take on this?

François: Yeah, I would say first, when you see those kind of articles that kind of, I guess, might have a bit of a provocative or something that title that kind of challenges convince conventional wisdom of the modern DevSecOps shift left mentality.

I think, you know, first, often with that, like that's the case often with Forbes articles, they are a little bit of this guy's promotional pieces.

So this Article is written by the CEO of an AppSec vendor. So just need to, whenever you read those articles, you need to understand who's writing and their hidden agenda. But that being said, I agree with the ultimate message of the article. It's just that the title is kind of maybe a little bit provocative and just maybe.

At first when you see it, it might think, oh my God, is it like shift to right instead of shift left? No, it's not the case. It's just that the article is just saying, don't expect that you will just start to tell your developers from now on you're responsible for security after you've just read, had a simple OWASP TOP 10 training. Here you go. Go ahead. From now on, write secure code.

Of course, the reality depends on the size, like the scale of the corporation, like the company. If you have a very small team, you're just trying to do your best overall, like with the resources you may have. And at the larger, like on the other end of the spectrum, you need tooling, you need to address the scaling issue. So it's really...

Something that in fact like our tool like product we're trying to kind of address both ends of the spectrum like small teams that are Starting from zero to one like they have no dedicated full-time Security person and they just want to do something about security And then when you get to another like in the middle like you might have one person, but that person is swamped with managing triaging vulnerabilities or even finding them by running various tools, doing code reviews, just like a matter of one or very few people with a big problem.

And then on the other end, like a large enterprise, just like dealing with sheer scale, like multiple departments and the politics of it all. So I think the article is right to say that it is not a developer first problem in the sense that it is not strictly the responsibility of the developers. It should be the overall company's responsibility. And yes, of course, people that write code have ultimately, are ultimately potentially introducing the problems.

And when they review code, if they don't have the right training, they should have some support either with the tool.

I think that's what the article is trying to address by talking about automation. The tool you may use to help those developers that might have very little training is critical. Like the better the tools, hopefully the better it can help to maximize or to really achieve this shift left idea.

Host: So I have a follow-up question on that. You mentioned about the spectrum, right?

Like, let's say a startup which has maybe either no security engineers or just one security engineer versus an enterprise where they have security engineers but they have so many departments, it gets overwhelming to manage.

How will you use automation or tools in both of these ends of the spectrum? How do you look at that?

François: Yeah, I think on the small scale of the spectrum, like a small team that's just trying to start, to do some security. You know, maybe we're talking, I know when I was doing consulting, a lot of the small startups that were reaching out to me, they were in the fintech sector, like finance, technology, like banking, you know.

Disrupting kind of finance technologies. Because they're in a regulatory context, like their customers expect a lot from them, which is very different from other types of startups where they're just shipping as fast as possible because they don't even know if they will survive and security is not a big concern.

So on that side, like they are forced to have security by their customers, like live or die situation, to have some security to even get the discussion. So for them, they're just happy to have a tool which they will just click something, it will run some like scanners, get some results, but like really the low hanging fruits, the things that they can fix quickly, easily, and reliably by not introducing more problems like, so, kind of OS top 10 things with very high confidence and give really good contextual information so that you're really achieving this shift left mentality by training the people as they are faced with the problem.

So really kind of incremental training knowledge, very contextual versus the other side, you might have an entire team, an entire department security that's focused on achieving much larger goals like maybe like SOC 2 compliance and just collaboration between different departments which politics of it all so for in that on that side the tooling is much more about the scale as I was mentioning so you want to Facilitate to ensure that those scanners are running on as like all the source code that it should scan, which might be challenging.

You might need to have the approval of different people who might have the permission to even set up the scanners, right? So this is the kind of challenge you may have. And like when we design our product, we talk with the customers, we understand those issues and we try to make sure that it's as frictionless as possible, even in those larger… size and enterprise.

But yeah, I think also the article is mentioning kind of automation in the context, like more modern context of AI, like LLM and chat GPT world. I think from that perspective, we're at, you know, in terms of hype cycle, we're still early on in the LLM hype. But I think that it's a very, very promising technology. Like even if we remove, we try to push away all the hype.

My concrete experience using it, I can see that it will definitely change things. It will definitely improve the tooling with regards to application security, but it needs to be done smartly. Like it should not just be using LLM for the sake of using LLM because it gets you to have VCs give you money, it should really try to extract the know-how, all the things that a security analyst has learned over time and bring it into the LLM so that it increases the velocity of a security analyst.

It's not a matter of replacing it just a matter of helping with that scaling issue, right? Like people are swamped with like thousands of vulnerabilities. If the LLM is not only triaging, prioritizing, but like when the analyst is looking at something, it's really providing this digest, the summarized view of what are you looking at?

Because I remember, you know, before those tools or even like good modern tools. I would spend most of my time just clicking through code, the large code base, just figuring out, like chasing the code base to validate if the SQL injection is really like something I should address right now, or yeah, no, it's maybe not the false positive, but there are so many variables in play that it's not a short-term priority. So I think it's very promising tech.

Host: Absolutely, I agree with that. One of the things that I want to ask as a follow up is, like we spoke about both ends of the spectrum, right, with tools and all, for an organization which is just starting their security program, let's say they are a startup, Infintech or HealthTech where security is important, right? How should they think about security?

Are there any areas of AppSec which they should start with? Like is it the vulnerability management or is it like the dependencies understanding the dependencies or is it more on secret detection which area they should start?

François: Oh, well, it's a big question. Start with, I think, with like many things. I think, and you had a great guest in the past, Brook Shermanfield, which I work with at Intel. And I think his answer would be with threat model. Like everything starts with threat model. And I would agree that understanding what you're working on, like...

What's the context of what you're building? What are the impacts? Like, where is this thing going to be deployed? And that's when we get into the supply chain, which I think we'll discuss after. This is very important. And for a small organization, I think they want to start with something very lightweight, just using the diagrams they may have to design the software and just having this attacker's mentality on it is very good to start.

But otherwise for a very small organization, once they just think about their code with the red team perspective, there are a bunch of open source scanners they can use and they will get those low hanging fruits. I think you were mentioning secret scanning.

I think, yeah, for sure, it's those extremely easy to fix and extremely easy to create problems, like just copying a secret and pushing it in the source control. There are good tools to address that. It's a solved problem, if you will, but unfortunately it's still happening. And so I think enabling features in GitHub, for instance, if you're using GitHub, just scan for secrets, other scanners. It's like, you know, start with that and then use open source tools to just have a baseline. Like you've scanned it once, you hopefully have eliminated the blowing fruits, but then just a journey to continue and keep it current, right?

Host: Make sense. And I like the word that you use, right? It's a journey. It's not that you just scan it once and you're done. You have to fix the ones that you have found out as part of the baseline and then continuously continually do the scanning and keep fixing them rather than it's a one time activity, rather than thinking that it's a one time activity. Yeah, makes sense. So I want to go to supply chain security side now.

So, nowadays every software you look at has some dependencies right, some dependencies to open source or something like that and that makes us vulnerable to supply chain security. So,

What are some of the top security risks today around supply chain security?

François: Yeah, exactly. I think, I mean, it's something that, nowadays we put a word on it, we call it supply chain. But it's been, I think for any smart security analyst, it's been something that's been keeping them at night for decades, right? It's just that now we have a simple, short way to talk about this.

And there's enough focus, there's enough attention to this problem, thankfully, or for the good or bad reasons of like, not to mention the solar winds and all that. But I think to answer your question, the top supply chain problems, I think, yeah, as you mentioned, open source dependencies.

You can hardly find anything today that's not depending on open source, it depends on libraries from NPM, PyPy, or any other open source package registry. So I think it comes first, thankfully, like if I go back more like 10 years ago, we didn't necessarily have those like package JSON or... Maven, if I go back to Maven, maybe that's kind of when it started, like this type of, have one manifest where you have all the dependencies and not just copy paste like jars and have them in your source tree and you don't even know where you copy pasted that jar from. But for sure, ban anything that just dropped in the repo that's like the very first thing to do.

You need to have something clear if we're not even talking about the SBOMs at this point like very minimal like have a Manifest like package JSON or be it some other technology like requirements TXT Where you know what you're depending on then after if we get into s bum that's more about like just a more official way to keep track of that and Not just like when you look at it from if you have a darker image You want to scan the actual?

a final artifact that's actually running in production because it adds many more dependencies, not just what's in your repo, but then adds and maybe at that point, in fact, there are things that are only in your CI, like dev dependencies, like development scoped dependencies that are not in the final production artifact, but they are in your CI. So like they're kind of two things to tackle, but yeah.

I think understanding your dependencies is key to start your journey in terms of the supply chain. And then after, yeah, again, it comes back to threat modeling, like understanding your artifact, like what you're building, where it's running. And then like, are you then becoming… a new input into an entirely different organization, right?

Like you are a vendor, you're providing a piece of software that other companies are running, either as a service or like on-premise. Then you need to really think of you as the input of someone else's supply chain. If that is the case, and you're not just like writing a software that's for your own use and you don't you know, sell a service or software. Yeah, I think it really comes down to start starting to understand that. And, um,

Yes, like for instance, like, you know, SolarWinds again is a very good example of that. It's like they were, they are still like a US DoD supplier. So they write a piece of software which runs in network, like as a network monitoring tool in very high risk environments. So they produce something. And if they're compromised, they… then they are responsible for a compromise of another organization. So I think that's where you need to start with.

Host: So there are two aspects, right, as you highlighted. One is security of your own code. And also when you are using a vendor, security of theirs as well. One of the things that you highlighted, which I really like, is the dev dependencies. Generally, we do not think about dev dependencies because we think that, yeah, it's not going to production. But it is going to the CI system, right? I think the threat modeling mindset helps look at this also.

So I just want to touch on that for a little bit. Like when I look at supply chain from a threat modeling perspective, how do I assess the security of my supply chain? Other than let's say, dev dependencies, what other area should I look at?

François: I think for the listeners that may not be familiar with the Salsa SLSA model, it would be a great moment to mention that. My team has wrote a series of articles on the topic related to supply chain with the perspective of the Salsa SLSA, which is the supply chain.

So it's a supply chain levels for software artifact the idea being that it's a generic threat model To share a common language in the industry when we talk about supply chain threats so and I think the promise the goal of salsa is to become a tool for compliance so that when you sell your product to someone else and they want to understand the level of risk they're taking into their own environment and their own threat model, they can hopefully trust your attestation that whatever you're giving them as a software artifact has had a certain level of due diligence in terms of the supply chain.

So you have a piece of like a binary, they say compiled jar or whatever, where was this built? Can you trust that the source code that went into building this jar was validated against the code vulnerabilities? Is it signed? Where was it built? Who touched it and all that? So that's what Salsa is trying to address. It's like, provide the level of confidence, like level one to four where level four is everything is signed, it's hermetic build, it was run in an environment that cannot be modified during the build time.

And it kind of touches what you just, your question was about the development dependencies. Yes, they're not running in production, but they are running when you run your tests or linting or building. And if they're not trustworthy, they're compromised, then your CI is compromised, or at least potentially compromised. And then you cannot trust anything down the chain. So that's the whole supply chain.

So if earlier in the chain you have an opportunity for compromising, then everything that follows after is not to be trusted. And how do you do that? Then keeping the chain linked is hopefully using some signature, because if you don't have any signature, you're not sure that the previous step in the chain is really what it's claiming to be.

Host: Secure enough or not? Yeah, yeah. OK. Makes a lot of sense. Now the follow-up question to that would be,

let's say if I am thinking about if I'm starting to build the supply chain security program in my organization, how do I go to, let's say, my upper management and convince them that it has value?

Because security often is not seen as a first priority, right?

So how do I go to my upper management and show them the value so that they buy into the program, they invest, they let's say hire engineers or they buy tools or whatever is needed to make sure that we are secure from a supply chain perspective.

François: Well, more and more it's going to become mandated, like in terms of procurement. The US government is making a big deal out of that because of some solar winds was really the impetus to push the industry and the US government to take that seriously.

So it will be if it's not already mandatory and to .. to come with that SBOM, to come with some degree of compliance proof that you've done the due diligence. So where do you start? I think, and where do you start and how do you convince management?

Well, yeah, I think the management will be convinced in the near future if they're in an industry where this comes into play and it's going to be viral. Like, you know, once you have… a downstream dependency of a big product which is used by the US government, then that little open source project that another big vendor is using, it will be either they will stop using that dependency because that dependency is not meeting the bar, or they will maybe invest in improving the security posture of that dependency.

And that's something that the… Linux Foundation has been very good at, like they created this open SSF foundation security kind of aspect of Linux Foundation to look at the supply chain security of open source components. And they have a number of great initiatives, one of which called the Alpha Omega project dependent on dependencies by important products and ensuring that they're properly staffed.

Like it's not just open source maintainers that are doing that as a side project, that they're paid for that, like they're incentivized and they're provided the right help to care about it. And then… The Omega project is really for the long tail of all those other projects which are too small to be directly, like the direct dependency, but often when you start to look at your dependency tree, you have transitive dependencies, you know, dependencies of dependencies.

When you go down that rabbit hole and you don't sleep at night, because if any one of those downstream is compromised, then potentially up the chain. Yeah. So it's a very big complex problem, which is going to take many, many years to address.

But it all starts with understanding your dependencies, I think. And the SALSA model is a great thing to also understand your own level of risk and which threats you need to consider.

Host: Yeah, like speaking of transitive dependencies, I was at AWS Reinforce, and there was a vendor who was showing the graph, right? Like how, what dependency you have, what dependency that dependency has, and like he was going deeper, and it was like at least 10 to 11 levels deep, and then he was like, I can't keep track of it anymore. And also within those,

There are different versions as well, right? Let's say you are using a particular package. One of the dependencies is using one version of the package. Another dependency is using another version of the package.

So it gets out of control in a way. So yeah, it's definitely a tough problem to solve. One of the things that you highlighted early on as part of your day-to-day job is like staying up to date, right?What's going on in the industry? What are the new threats and all of that? What were...How do you do that today?

François: Well, it's I think my favorite shout-out to Clint Gibbler from the TLDR sick newsletter is an amazing resource. Like every week that he comes out with a newsletter. I mean, very often.

Uh the things that are in there. I had not seen them sometimes like oh, yeah I was I was like a few days in advance, but it's really good. Like I think he People proactively push stuff before they were published.

So he has like the scoop And in fact one of the articles that I published was pushed in the tldr It got there actually the two articles so it got very good attention. Uh, like people uh contacting me like speaking at conferences.

So I think this newsletter is the gold standard for the AppSec supply chain and all that. Like if you're not already reading TLDR Sec Newsletter, you're just like, you're not up to date. That's, start with that, like, and then you will already have the gravy train of just like new good stuff every week. And then you're just overwhelmed because just going back through the archive of TLDR sect, like one year ago, you will find gems that should be known.

Host: Yeah, and that's a very good one. I do receive that as well weekly. Another one is the Marco Lanzini. He also writes about security. He also has a weekly newsletter, including the security topic. So that's also in my list of newsletters.

So last question that I have on the supply chain security is, so we spoke about how to address, how to go to the… upper management,

How do we train developers so that they, let's say when they are evaluating an open source library, what steps should they take before they introduce into their own product as a dependency?

Is there a set of steps that you follow when you do that?

François: Yeah, I think if I could say something very quick, like if I tried to give a simple answer, I think depths.dev, if you're not familiar with that, it's an initiative by Google. So you go like depths, D-E-P-S, dot D-E-V. It's a website that is called Open Source Insights. And you basically type the dependency it's a new library. And it will give you a bunch of statistics. And they keep track of all the versions throughout time.

And they do an analysis like using this open SSF product called Scorecard. So Scorecard is a really great tool that you may want to run against that potential new dependency you may want to add. And what it will look for is the low hanging fruits in terms of supply chain for a given dependency so that you know that you're not about to add something really horrible.

So like something where it is unmaintained, like nobody has committed anything to that code base for years.

So basically, you have no hope that if there is a vulnerability, it will be patched. Like there is someone to just answer some… researchers finding vulnerability. So, you know, short of, you know, we say, oh, there are CVEs in that.

Well, that's because there was someone on that open source project that, well, either it was just like this closed like without the intervention of the maintainer, but hopefully there is someone to fix it, right? And then to have a patch, not just a CVE is like it's vulnerable, but like you have no option to just patch it.

But that's pretty bad because if you're stuck with no patch but a public CVE, you have a zero there on your hand and you need to quickly change to another library, rewrite your code, so you don't want that, right? So the maturity of the project you're about to depend on, keeping up with the dependencies, and this tool, depth.dev, is about this graph, right? Transitive graph dependency, it shows that. So you will see how much you're about to take on.

How much complexity is gonna be added to your own graph. And a bunch of other key metrics, like does it have branch protection? Are people doing code review on every pull request before it gets merged? And other things. So I think that's a really great resource to start with. Yeah.

Host: Yeah, those are some good metrics actually. Yeah, those are some good metrics which can help you evaluate whether you should go ahead with a particular library versus an alternative, right?

To avoid as you said like zero day and you have to find an alternative, use that in your library. It will take a lot of your time and also when you are getting attacked or you are vulnerable, it's even more tricky, right?

So yeah, we'll definitely tag this when we publish the episode so that our audience can also go to that and start leveraging it. So that's a great way to end the security questions.

Summary:

Thanks Francois for the engaging conversation. Here are a few important points that stood out for me:

1. For Application Security, start with Threat Modeling including Context. Look at all our architecture diagrams and start evaluating from an attacker's mind.
2. When using Open Source dependencies, start with a Baseline Vulnerability Scan and do a continuous process to review and evaluate dependencies.
3. Understand dependencies, SBOM to verify validity of dependencies. One of the tools to do this is deps.dev.

Let's go to the security practice rating section.

Rating Security Practices

So the way it works is I'll share a security practice and I would ask you to rate it from one to five, five being the best and you can add some context, like why you are giving a particular rating.

So

1. is use strong passwords that contain a mix of upper case, lower case letters, numbers, and symbols, and change your passwords frequently and avoid using the same password for multiple accounts.

François: Just to be sure, the best being one or five.

Host: Five is the best.

François: Okay, so I think this whole thing about, well, using strong passwords, I would agree, but changing frequently part of this question would make it, if we just focus on that for a moment, the worst, like it's the worst practice if we mandate that people update frequently, because it's really not about like updating, because this, I mean,

Why why does it come up? I guess this whole thing like is back from the 90s and assumes that You have such bad passwords that people will guess them and you will be compromised well, just start with having great password that no one can guess, and the only way that this thing You know leads to a compromise. It's because something else went wrong like it's not the fault of the password if you use a password manager with a great master password and you have unique, very strong passwords everywhere, then you don't need to change your password frequently. So this would be the worst if we focus on the, change your password.

But the other side, the one about having strong password and all that, the mix of uppercase, lowercase, number, symbol, and all that is not nearly as important as having a long password. So if you just look up the math behind it, if you have anything beyond 15 characters or something, even if it's just alphabetic 15 characters, and it's not obvious, it's not just ABC through Z, then in that case, it's very strong.

So adding uppercase, lowercase numbers and symbols, in fact, you should not care about that. It should be the job of the password manager to just like do it. And if the website is only accepting 12 characters and with like symbols and whatnot, but not certain symbols, it's already a red flag.

It means that website has some weird quirks of the software that's preventing them from accepting this character set. It's like, you know, that's bad. But in fact, like, NIST years ago removed this whole, like, change your password frequently thing, so yeah.

Host: Yeah, it makes sense and the more frequently you have to change you start writing it somewhere which defeats the whole purpose.

François: Yeah, people have tricks. People like, you know, a large corporation that's still doing this kind of 1990s idea of change it every month. Like people start to have ways to just append the extra characters and then you're just back to square one, like.

Host: True. Pass at one, two, three. Now I add four to it or five to it or something like that. Yeah, it doesn't keep you secure anymore, right? OK, so going to the next one. Always lock your computer when you leave your desk, even just for a short time.

François: I think it I mean it's definitely not the bad thing it is a good thing so I think in terms of like one to five if one is the best five is the best I would say it's kind of not the most important thing but it is important so let's say let's call it four or three point five but I think nowadays

In the context of working from home, like remote work, it's much less relevant, much less important than in a big workplace where you have a lot of people and potentially strangers walking past your desk.

In that context, of course, like locking your computer is important. But if you start to consider that… like a stranger walking up to your desk that's unlocked or even locked. Like if it's locked in a screensaver with a like password thing, it still means that most likely full dis-concription is the keys are in memory.

So like it comes down to threat model. Like if know your adversary, if your adversary is gonna take your laptop that has like a password screen, screen lock and start to scrape the memory like, you know.

It doesn't matter. Like you locked your screen, but the data is potentially still fully decrypted in memory. Uh, so yeah, word from home versus like in a big environment. It's not, it's not as important.

Host: Right. Yeah. And also if you're working from let's say cafes or outside where there is it's a shared space, you have to be extra careful. Makes sense.

François: Exactly. So like know the environment you're in and of course lock your screen when you're walking. Just make it a habit. Do it but don't think that you're just protecting everything like against any and every attacker.

Host: Yeah, makes sense. The last one is conducting periodic security audits to identify vulnerabilities, threats, and weaknesses in your systems and applications.

François: I think this on the spectrum of, you know, good to bad, this would be kind of in the middle. It's not, it is good to conduct periodic, but it should be continuous. So that my point is that the practice of doing it only point in time periodic is not great. It should be kind of all the time.

But all the time in a way that's manageable as an AppSec program, which means tooling and all that, of course. So I think this practice is more about like pen testing. So yes, to have like some external third party opinion on a periodic basis, yes, but it should not be the only thing. It should be one of the many things in your AppSec program. So yeah.

Host: Okay, makes a lot of sense. And that sort of concludes the episode. Thank you so much for joining us and sharing your knowledge on both application security and supply chain security.

François: Thank you!

Host: Yeah, absolutely. And for our viewers, thank you so much for watching. Hope you have learned something new. If you have any questions around security, share those at skill20.com, and we'll get those answered by an expert in the security space. See you in the next episode. Thank you.