SecTor 2025 | Scaling the AppSec Program Without Scaling Security Headcount

Added: 2026-05-25

[00:00:02]Okay, you probably got our bio uh on before you came here. Uh and I hope you are on the right uh place. Uh just a full disclosure, uh everything we're going to talk here is live. It's it exists. It's real. uh we actually were able to deploy and uh uh and uh deliver a project for application security for the whole applications on the on this client uh every single application not only picss and little bits uh without felt the need to increase our security headcount like crazy. So everything you're going to hear today, it's real and it's life and it's working. Uh so Mario's point is understating it. Like anybody else, you know, these are the results of working with a client engagement for probably 5 years. And like many people, we started with more of an ad hoc security basis. Couple tests here, couple tests there. After time, they wanted to increase their security posture. they want to make their perimeter more robust. We face those challenges as well. But we don't have an infinite number of security experts and quite frankly our client doesn't have an infinite amount of money to pay for them even if we did. So they had pressures on us. We had pressures to scale and that's really what we did here. We faced those challenges together and moved things forward. um just to help me get a feel for what our audience looks like. Uh give me a show of hands, folks.

[00:01:44]Who here's a a security practitioner right in the field? Anyone? Anyone?

[00:01:48]>> All right. See, that's awesome. Thank you all. Makes sense that you're at a conference. Um same sort of vibe. Uh how many of you all have a really solid understanding of software development?

[00:01:59]SDLC. Oh, this is a great Okay. Okay.

[00:02:02]This is good. This is good. So, what if I were to say, you know, if I were to reference like get actions or pulling down an SBOM, reading an SBOM, that all resonate with this crowd? Oh, great, man. This is awesome. Uh, flip side, uh, how many of y'all here are software engineers, developers, platform engineers, any of that?

[00:02:20]>> Okay. Okay. Okay. Great. Great.

[00:02:22]>> For the for those of y'all, >> if I were to say, you know, hey, you've got a serverside template injection vulnerability, you guys feel like you'd be able to go right out there, knock that out yourself, couple minutes, no big deal. don't have to Google it. All right. So, yeah, I see that. So, you you you've probably faced this in your lives, right? For whatever reason, there is a gap, a division between security practitioner expertise, especially in the application space and engineering expertise, right? For whatever reason, we don't talk to each other enough. There's not enough cross-pollination of skills. And so that's really a lot the core of a lot of the challenges we face was sort of knowledge transfer inculcating that knowledge in behavior patterns and helping to remove some of the friction that comes from those two teams dealing with each other.

[00:03:15]>> Yeah. So if we think on how it was before we begin and that was uh five years ago and how it is right now after we implemented all of these changes you will see that there is a lot and again without increasing the headcount but let's talk a little bit here on the problems. Uh this is a typical SDLC software development life cycle if you're too deep into security. Uh everything starts with a business requirement. We're talking about business people. We're talking about people that are not technical. They come from the business. They know their requirements. And then we bring this security team with a thread modelers and uh you need a senior security person that understand network, understand data, understand classification, understand legal and they need a time with the developers but not the junior developers, with the senior people there, with the team uh team leaders with uh the managers.

[00:04:11]Where is it going to be hosted? Is it in the cloud? Is it? And then you build that beautiful academic model called the thread modeling and from the thread modeling you you bring the requirements.

[00:04:21]Now you get the requirements you have the security the non-functional requirements and then you get into the development itself. Now developers are junior people. It's rarely for you to get a really senior person developing hands-on developing open the visual C visual basic Java Rust or whatnot. Those are juniors. As soon as they become a senior, they become team leaders. They move on. That's that's life. Now, here we're talking about a developer that has a timely constraints on I need to develop things fast. I need to get my backlog, throw it out. I don't have time to wait for a scanner to finish. I don't have time to wait for the next false positive analysis and to receive lots of false positives. Uh then we get into the next stage which is the testers, functional testers. Here we're talking about the people that created automations to test the software. They don't understand security. They understand the functionalities. They understand the test cases. If you open this page should be red. You should have this field. You can fill it up. That's what they do. We need ways to get all of this knowledge and automate this. And then finally we have the operations people who want to make the software to be up and running. That's what they do.

[00:05:47]They change a key here and there. They change a username from time to time when it expires. But they are operational people. We're talking about different people and the security team needs to interact with all of these different teams that has completely different objectives, completely different future, completely different mindsets and objectives. And somehow we need to come up with a solution to all of this. So we cannot come with a one Pandora box that's going to solve everything. It's just impossible. The audience is different. Because of that we developed specialized systems using a lot of AI but also using regular deterministic if then else statements for automations there but uh we need all of those and when we're talking about adding to the SDLC here uh we need a first a visibility of everything you want to protect and in our case is everything all the digital assets we want those to be protected.

[00:06:51]Everything that you created in a code is it custom or not, I need it to be protected. I want it to be protected. Uh we also need a specialized system to find the requirements to do the thread modeling automagically and I'm talking about magic here, okay?

[00:07:09]It's going to get all of the PDF, vis, word documents, all of the requirements that you have there, translate into security requirements and inject back.

[00:07:18]We're gonna deep down into each one of those. We also have a system to talk to the developers and empower the developers with all of the SAS and dust and sea outputs. I teach the developers on the fly. We're going to talk about this as well. Uh how to do security. We actually did a shift left, real shift left, not the fake one. We also need a system to test at scale because everything I'm talking here is at scale.

[00:07:51]Okay. And at scale I mean a lot of developers, a lot of applications, a lot of APIs. I need to test everything.

[00:08:00]Apply the same testes everywhere. That's where we get the penot. All of these names here are our internal names. Those are not trademarks. Accenture does not create products. We don't sell products.

[00:08:10]We sell solutions. That's what we do.

[00:08:12]also bad at naming things >> and we are terrible at naming things.

[00:08:17]Believe me, we spend three weeks just trying to name something and then we discover that we can't use that name. Uh at the end we have to protect production. Make sure that whatever goes to production was tested was fixed. I don't have a zero critical policy. We do have a zero critical policy. No critical vulnerability at all in production. uh highs you can have it for a week or two not critical ones and that's a policy.

[00:08:43]Uh did I miss anything?

[00:08:45]>> No, that's the overview.

[00:08:48]So starting right got a bunch of security practitioners in the room. You've all interacted with stakeholders in various tiers of the business. Anytime you want to start a journey, be that moving up a maturity curve, be that moving into a new area of protecting the estate, you know, the first question you always ask is where do you want to start?

[00:09:11]I don't I I I don't know about y'all's experiences, but for mine, the question was always, well, where should we start?

[00:09:16]Uh, so what we did, again, we call it AppNav, and that is a terrible name. uh I'll take the blame for it. But what it is is it is an intentional methodology where we have collected all of the application and asset data. So we're not talking just a CMDB. We're not talking just servers or cloud instances. We're also talking what languages are being used to develop these assets. So we can look at tool compatibility. We're looking at what the deployment frequency looks like so we know how to make sure our security scheduling is lining up with our development schedules. We look at DNS registry, so we not only know what applications are live, but where they're found. Are they internet accessible? We look at do we have regulatory requirements? Are they PII data? Are they highly confidential data?

[00:10:00]Do they have special handling? Do they have residency requirements? Now, in our live encounter, when we did that, we asked our client how they would like to see this information, how they would like to use it to inform their decision-making process. and their response was, "Slap it on PowerBI and let's call it a day." And so we did. But the tool doesn't matter, right? If you have experience in Tableau, if you have experience in clickview, if you really diehard love PowerPoint, bless your heart, but it doesn't matter what the tool is. What matters is the approach.

[00:10:33]Getting that data, getting it centered, getting it correlated, getting it linked up, and most importantly, getting it into the hands of people who can use it to make decisions. Because at that point what you have is you have information and you have intelligence not just factual data. That effort uh is non-trivial. Uh anyone who's ever worked with a CMDB or that kind of effort can get can can attest to that. But it pays dividends. It's the foundation that you use to direct further security efforts.

[00:11:04]Maybe you find out that one development team has a very high occurance rate for a particular vulnerability category that can inform training that can inform additional standards. You can take that quantitative information back to enterprise architects and say hey can you guys develop a reusable evergreen asset that can be deployed out as part of a standard process and that is what we've done. We've had all of those discussions coming out of something as terribly named as AppNav. Um, >> AppNav is more than CMDB. Think like that. Don't trust Don't ever trust your CMDB because CMDB is it has a the objective for CMDB is to pay licenses.

[00:11:50]It was created so you can pay the right licenses properly and so you have your change management database and you control the licenses. uh the number of APIs created by the developers, the number of branches they have, the number of applications they build, the number of uh tests that they create, deploy or not, it's not on CMDB and it will never be on CMDB. Forget about yourselves in now trying to discover this automatically. It will not be fully in sync. What we created is a methodology to find all of those. That is the idea.

[00:12:26]And then we get the arcbot. That's a good one.

[00:12:29]>> So, Arcbot is remember the thread modeling. So, it's amazing. You spend two weeks with a senior developer, a senior security consultant creating an amazing academic document that will never be used, >> right?

[00:12:46]>> And if it is used, it will be used to build requirements, which is the only actionable thing for the developer that we'll give to the developers and they will forget about it. They will never review it unless if the security asked them, hey, we need to review the thread modeling again, anything changed and they're nah and there's no review. So instead what we build is Arcbot. Arcbot is a AIdriven tool. Now we're talking about AI real AI. It is consuming every single document the doc the developers produced or used. So I have the backlog. Yes, it is there. I have the pipeline. It is imported. I have the video files. It's important the word documents, the emails that they exchange each other. They're saying that the color should be red or not red. All of these is imported there.

[00:13:37]And then we have a a group of security requirements that we add into those applications. So yes, this is a web application. So it requires login. Nice.

[00:13:47]Let me add my requirements here. Should be HTTPS according to this policy from the company. uh your application must have this encryption using these standards requirements. I throw those on the backlog. Now look at the beautiful thing. Now I have backlog entries with security requirements. It's up to the developer to go there and thumbs up or thumbs down on this requirement. I will implement or I will not implement. But I have the developer name saying that they did not implement.

[00:14:20]if something happens in the future now I know why it was not implemented and it's not a junior developer that is going to give a thumbs down to a requirement it's usually one of the senior person and they know this tag came from security they know this is an injection so they think twice before they remove those uh in one year we got about 700 applications we got 70,000 thousand security reviews created from AppNav, sorry, from App Arcbot and uh we injected an infinite amount of uh of uh new security requirements, non-functional requirements there. U 90% of those got a thumbs up got implemented. Because of that, we got a 12 times reduction in security in the vulnerabilities created that were possible to be exploited later on. I'm talking about requirements here way early. So this is the shift left we're talking about and I'm empowering the developer and and their groups.

[00:15:33]>> Yeah. The the nice thing about it is when your developer wants to ship code and they want to get it done, where do they go? They go to look at the requirements. to go to look at their backlog. If you're a product manager or you're man a scrum manager, you're managing that backlog for your team. All of it is right there completely removing the friction from having to review an academic document asynchronously with email delays. Part of your standup hit these items, right? And it's a wonderful traceability matrix because I mentioned with our app nav, we tie in security vulnerability data, right? So if we see a team saying yeah we're not going to do this injection sanitization process and we find injection vulnerabilities downstream. We have a traceability matrix that helps a lot. Next stage now we have developers developing things and uh remember they have a time constraint.

[00:16:26]They need to deploy things fast. They can't wait for your SAS scanner to finish and then for a security person to go there do a false positive analysis see what I can what I should not they can't wait for that they need to be empowered I need a tool a security tool that I can give to the developers and they can do their work with security so that's when you meet the appsac bot it's a bot it's a chat interface we build it in our va in a pva in uh copilot now the name but it's a chat interface we collect the information on how we do how our thememes do perform a false positive analysis so we check for this we check for that we check for that if all of these are true it is a true positive you need to fix it if one of those is false it is a false positive you can remove it it's a chat interface from the chat interface the developer can ask for a rescan they fix something they can go to the chat and hey rescan for me. It's going to rescan. It's going to call the uh the scanner uh on the back end. We use uh vendor scanners out there. Everything I'm talking here is not replacing any of those. I'm still using your SAS vendor. It is vendor agnostic but uh we still using those and we need to use those. Uh it's going to rescan for you. It's going to check if the vulnerability was fixed or not. It's gonna propose the fixes and now proposing fixes is an interesting thing.

[00:17:58]Uh I cannot trust the uh external AI to do development and to fix things. I cannot just trust this. So instead I have a three types of fixes that we built. The first one is deterministic.

[00:18:15]You have a random that is not safe. You need to use the secure random. I just need to change it. You import secure random. to use secure ramen replace all of this that's all deterministic if then else go there change this line for that line that's it easy I have a rag uh llmdriven fix why I use a rag so I ced fixes that I validate and every single one of the fixes for security they have an impact on the code performance-wise memory wise they have an impact if you get all of the suggestions from your scanner to implement all of those. Your code will never work again. I'm sorry. It will not you will not even compile it. We created those ones that actually work that we tested and that they have small impact.

[00:19:06]Sometimes I have a three or four different strategies that they have different impacts. You can use a white list to filter your characters or you can use a prepare statement for your SQL injection. And one is going to have an impact on your database. the other one is going to have an impact on your local memory. I know this and the developer can pick and choose which one they want to implement. And then the last resource is yeah go out to chatgpt or code or whatever and I try to fix from there.

[00:19:36]Now what I do with this I have access to their source code. I create a new branch security branch automatically.

[00:19:45]I change their code. I do this. The bot do not me right? Not Mario. The bot goes there and change the code. It is on a pipeline remember. So I can compile the code. I can test if it is compiling, if it is working, if everything is fine there. If everything comes up, I can open a ticket to the developer. Hey developer, see this branch, I fix all of these vulnerabilities for you. Can you please go there and check and if you approve, you merge into your main. You have the decision. I'm just helping you.

[00:20:17]That's what I'm doing. I'm empowering developers to do their work, but they're doing so much faster now. Uh we proposed 21,000 fixes in one year. All of those metrics are real and from one year. We fixed a lot of the high critical mediums and low because many of those lows and mediums are so stupid and you don't want the developers to waste time on that.

[00:20:44]You can do it automatically. Just let the system do it and the system does.

[00:20:49]Yes.

[00:20:50]>> Sorry. Can you just give us an overview of the customer, how big they are, how big their team is?

[00:20:55]>> Fortune50 global services company. Uh application portfolio is about 1,700 applications. Development staff is between 4,000 and 7,000 active contributors on a rolling 90-day basis.

[00:21:07]>> So, it's a big it's a big implementation. And uh by the way, we are protecting every single one of their applications, not not only one or another. And we're not even getting into the APIs. Uh uh so you can multiply I multiplied that by a thousand for the APIs.

[00:21:25]>> Just just a thousand. So now we're in the testing phase. This is the exciting part, right? Because you have theoretically your static tests are done. It passes the does this compile?

[00:21:34]But now we have to do the does it actually work in the real world?

[00:21:38]Hopefully hopefully a non-production environment. we don't test and prod hopefully. Um, so we've got a couple different things here. The the first is we did CI/CD integrate our dynamic code scanning and that's great, but it is a thing. What our client was faced with a problem was our client kept having third-party security audits from their corporate security team, the the central one, and they would hire thirdparty penetration testers because all of you wonderful security practitioners know a dynamic scan is not the same as a penetration test. There is an art to one and dynamic scanners by their very nature tend to be isolated in what they look at. They don't necessarily look at the trust boundaries between applications or looking at data flow between applications or identity flows. So, our client said, "How can I catch all of these problems? I keep finding the same root cause over and over and it makes me look bad and my sizo is really mad at me." We said, "Well, have you thought about buying more penetration tests?"

[00:22:37]And he goes, "Will, that is an absolutely terrible suggestion. I don't have infinite money." Like, okay, that's fair. So, what we did, we took those penetration tests and we did the security thing. You look at the root cause. Then what we did is we met with their enterprise architects, the people who define the standards for what good should be and then we used a combination team of enterprise architects, security practitioners and pentesters and we built narrowly scoped tests to test for good. In some cases it might be is your identity flow going to the right cloud hosted identity provider. So you run an application from an unauthenticated basis. you follow all the network calls. Does it terminate correctly? Awesome. Some of them were a little bit more mundane. You know, are we following the OASP secure header standards? Do we have the right encryption strength? Um, all of these tests >> identity. Um, the nice thing about these is all of these tests are very narrowly scoped, right? So, a DAST will execute lots of things. These tests one thing, two things, very narrowly scoped. So the impact in a non-production environment is very limited. Now the other part is with penetration tests, reconnaissance is a pain, right? The start of any kind of assessment like that, you're going to spend hours, hopefully just hours, not days, looking and trying to discover the assets. Well, we talked about AppNav.

[00:24:07]See, I'm calling it back. Calling it back. So with AppNav, we tie in all of the data. We tie in the DNS records. We tie in the output of dynamic scans. We tie the output of static scans. So suddenly we have asset enumeration for all of our automated penetration test targets. We don't have to do the recon.

[00:24:24]We don't have to discover it. It's already there by having these tests hardcoded into a programmatic basis. And this is old school automation. I'm not doing anything fancy with an agentic AI. This is old school automation on a specific subset of tests for specific controls.

[00:24:40]But it means that there's no variance.

[00:24:42]Means you run the same test every time.

[00:24:46]You know your coverage is very good because there are standard tools like DAT scanners that exercise the application. They bypass application design for lazy loading, right? They will load every asset. You build out full paths for every single asset. I don't care if it's a static JavaScript file. I don't care if it's a fave icon.

[00:25:08]I don't care if it's an API. We see it all and we test it all. And the tests are the same every single time. Now, I mentioned the size of our client base here, right? About 1,700 applications.

[00:25:21]We run this for them now. And we are targeting anywhere between four and four and a half million distinct URL parameters every two and a half months with a team of about half dozen people.

[00:25:32]And because the tests are prescriptive, right, we wrote them in a combination of enterprise architects with the specific controls at hand. we have a very high fidelity rate, a very high signal to noise ratio. Uh in practice, our non-exploitable findings tended to come out at a below 5% rate because we're not testing for every possible permutation.

[00:25:56]We're looking for one thing over and over and over again.

[00:26:01]One uh thing to understand is everything that we are showing here. It's a methodology we created to build a specialized system that I can use at scale. So here is not a system to do penetration and replace a person. No, I need a person to go and do the first test. after this first test is is executed and I understand oh this was able to find a vulnerability in somewhere let me operationalize this let me industrialize this and then let me test this in every single one of my millions of URLs and I can test all of those in every single one of my assets.

[00:26:43]So when we look at a third party findings uh and uh you probably know all of those third party companies that go there and I try to find and I open a bugs with your company saying that yay you have we found all of these issues on you so we get those report we industialize this and then we test this everywhere no exception no crown jewel concept I don't I don't care about crown jewels I I care about everything and then I fix it everywhere because now I have a full picture. Guess what? Those third parties, they will not find those vulnerabilities again anywhere because they usually come again every six months with a different URL with the exact same vulnerability. You fix the again junior developers. They will develop and they will fix their app whatever you reported not everything because they don't know everything. They don't have this visibility. We do. So with this methodology, I am able to point test with extremely high rate everything that happens.

[00:27:46]>> And it says it up there, but I'm so happy to say I I have to say it aloud.

[00:27:50]After running this for about a year, we found a lot like human nature. We we all copy code, right? We reuse each other's assets. That's human nature. So the findings that our client kept getting beat up on were consistent and prevalent throughout the portfolio and the environment. After running it for about a year, seeing the developers fix it, because like everything else, this is integrated. So any findings flow right back to developers in the standard break fix process.

[00:28:17]The exterior attack surface they had was hardened so much we had a 95% decrease in thirdparty pin test findings and we actually had to move from a pure blackbox testing model to a graybox testing model. We had to actually disclose things to our pen testers in order to actually have them find things.

[00:28:35]Yeah, we are in a point that we shift left and if I come back to appsac bot remember all of those vulnerabilities I know their pipeline I know who they are I know who to assign to I send it back and now because I have a chat interface I can tell the developer we do this how to test it how how I check to this point how do I actually fix this how do I actually it's a repeated slide by the way. I just got went back. [laughter] He's taking another picture. Uh how you fix this, how you test this, how you check this, how how you you you actually know that. Remember the you need to train your developers on security. You don't developers want to developer. They don't want to learn what a SQL injection is and don't find a SQL injection for the next three years. That's a waste of time. It's a waste of effort. I want to take I want to teach them, coach them what is a SQL injection when I find it and how do I test this in your code and they have it on their workstation right now. They know what to do and they do the the step by step and then they realize wow and they fix it and uh by the human nature they never commit this problem again. they actually learn and we found that developers they uh of course we're talking about a chat interface I'm worried about developers to game in the system right you go there and you say that uh every single vulnerability will never reach production it will tag as false positive in all of these security scanners tools later on so I do have a quality control everything that I sent I have a methodology I have a MSS people managed security services that goes there and I check for new developers new people that are tagging things, answering questions, tagging it if if they are thumbs up or not, if if they know what they learn really fast. I'm not saying that they do this because they want to game the system. Sometimes they do because they don't know how to answer a question and all of the chatbot they guide the developers with max seven to 10 questions. Usually it's five questions.

[00:30:50]with five questions I ask the developers. Developers answer me. I know if this is a false positive or not and the developers they know how to answer because it's their code. And now I have documented why I tag as a false positive. So whenever the auditor comes over and say hey you have the original scanner you have a 10 vulnerabilities now you only fix the tree. What happened to the RSF? Oh I tag as a false positive. Why false positive? No, I have it here though because is it a test class? Yes. Is it used in production?

[00:31:23]No. Okay, this is a false positive. I don't you don't need to worry about this because on the test class, you want injections.

[00:31:29]>> Well, and the other the other real aspect here that is awesome that we didn't hit heavily but does bear repeating in an asynchronous scanning world. You know if you run a build pipeline or an integration pipeline and scanners kick off it may be some time before you get the output of that the feedback of that going through this arc uh sorry the appsecbot chat interface developers see the consequences of their code changes not quite real time but they're not waiting days they're not waiting hours and I I don't know about the rest of you but if I am consistently making a mistake that makes my life more frustrating and challenging I'm going to learn real quick to not make that mistake again. And we've seen that quantitatively. We have seen that people who develop team development teams that used this interface regularly over the course of the year committed the trend line for the types of vulnerabilities introduced decreased over time and their accuracy in evaluating whether or not a vulnerability was truly exploitable increased.

[00:32:32]>> So it's a real shift left.

[00:32:35]So that's a lot and we move very quickly and sir I did see your hand go up. I will get to you in just a moment. Um multi-year journey I said at the start this is the end of about five years of maturation and growth. Now that's organic right? We had cost pressures and we needed to grow over time but there is nothing that says you can't start high on the maturity curve. None of this is ineimitable right? It is standard vendor tool sets. It is open-source tools. It's a simple matter of just time and effort.

[00:33:12]Uh but it's doable and it shows extremely [snorts] high value. Um the big takeaway is we are delivering these services with a small team. We did not have to scale up our team as we increased our application portfolio coverage from 50 applications to 200 to 700 to 1,200 to 1,700 and uh you know the other important callway I think is find trusted partners right said this is a journey it is a journey it's a marathon it's not a sprint you need to find somebody that you can work with both professionally and personally because there's already enough friction out there between development and engineering teams and security teams and we really don't need to be adding any fuel to that fire. Um, so I got this timer here in front of me says I got about 10 minutes left for Q&A. So there's a microphone right there in the middle if anyone wants to speak up if they don't feel like projecting from the crowd. But uh, Mario, I think at this point we can just open it up and take questions. Uh, sir, I saw you earlier, man. I got to I got to give you credit for the recording.

[00:34:15]>> Oh, if you'll use the microphone, we can record your questions. So if you don't mind lining up there. Yeah.

[00:34:21]>> Sorry to make you stand.

[00:34:23]>> You make you walk 10 10 steps.

[00:34:26]>> Okay.

[00:34:26]>> It's all good. Uh so the question is on the pentest bot uh part of it.

[00:34:31]>> What are you actually using to do that?

[00:34:34]Like you I'm presuming you're you're taking the pentest findings and you're you're manually programming in like a way of retesting same finding. Does it go across many applications? Is it the one application?

[00:34:46]>> No, that's a that's a great question.

[00:34:47]Thank you. So what we did is we have an automated workstream that uses basically a number of open source tools that our red teamers use. So if we're dealing with our test cases around SQL injection, we use SQL map. If we're testing Java web token vulnerabilities, if we're testing whether or not default tokens are accepted, we use stuff that's open open source. Uh I think our one we found was JWT tool on a permissive license with no copy left. So it's it's the same things that you find inside Cali. The only difference is we're not running them inside Cali. We're running them inside containers inside of a cloud hyperscaler that has a workflow that automatically provides all the targeting information.

[00:35:23]>> So you're just doing the same test on the same target every time. Is are you applying it to all targets?

[00:35:28]>> All targets. Okay. So you're just seeing whether or not Okay, that makes >> remember that the developers like copy paste. So whenever they all like it. I love copy paste. Uh C and V are the the ones fading out my keyboard. Uh so they whatever they created and developed for one application they will do the same for the next and next and next. So whatever vulnerability I have one and again developers are junior and they migrate from one team to the other and they have a high turnover. That's typical uh we're talking about thousands of developers. They they change positions uh and they do propagate the same vulnerabilities everywhere. We just created a a way to find all of those and yes and uh it it is it doesn't look much but believe me this is a a a huge uh gain from your security uh practice because the worst thing is you have a vulnerability you know the vulnerability you map the vulnerability and then you fix the vulnerability here but you have it open in 10 other spots and then when you get a breach because of that vulnerability already fixed it's so annoy Uh we we're now fixing everywhere.

[00:36:42]>> Thanks.

[00:36:43]>> Yep. Thank you.

[00:36:45]>> Morning.

[00:36:46]>> Good morning.

[00:36:46]>> Thank you. Love the the stuff that you're doing and the shift left. How do you shift even further left particularly with the issues we're currently dealing with MCP servers and npm package manager issues that are even way before where this is at? Can you speak to that a little bit?

[00:37:03]>> So npm a little bit. Um you know we have We have plans not yet implemented on doing things specifically around supply chain management, supply chain tax. Our early explorations in that look at using some of our cyber threat intelligence services that see what's going on in you know dark web marketplaces. Um but then there's also the traditional tools and then the correlary to that is there are some fairly simple controls that can be put in place like to to the recent one in shyude with npm for example if uh if we had instituted a mandatory say 72-hour cooling off period from when something is published to the major repository before it can be downloaded and installed the attack service and the risk goes way down there's some of that now we we start talking about the MCP servers our client isn't actually there yet. So, we haven't had to cross that bridge.

[00:37:57]>> So, a few things here. We're talking this talk specifically is a focus on the SDLC starting from I'm not getting into the uh into the infrastructure as a code and all of this yet. Uh we do have cloud scanners, we do have uh infrastructure scanners uh specifically to find vulnerabilities on those uh deployed systems. So usually we we split security into three different things. We have a security in the pipeline, security off the pipeline, security around the pipeline. So in the pipeline is all of this code inside the pipeline. I safety that's that's this talk uh security off the pipeline. That's what you're mentioning. So I have the these chain attacks. I have all of the supply chain attacks, the npm ones, the containers you're integrating, the libraries you're importing, all the artifacts. Uh this is security of the pipeline and the right knobs on the settings that you deploy and security around the pipeline. A developer cannot touch production.

[00:38:58]That's it. You have a final pipeline that is a production pipeline and whatever you are doing you go all the way to QA from QA to production it's going to be automatic. So you cannot bypass it and deploy things yourself.

[00:39:12]you can they still have access to production for other reasons operational people but not to deploy code so those three uh so I can talk about these other two if you if you want but not here we don't have five minutes on >> I'll you later on that >> but uh yes that's the the the big idea there thank you >> um you mentioned earlier on that um so about 80% of the requirements are being implemented I was kind of wondering if there's a specific category of requirements that are being rejected or not implemented.

[00:39:49]>> There is a research on top of this. I don't have it handy but I can I can provide it. Uh usually the requirements that has a big impact on performance uh they may not be implemented and uh sometimes I have other controls there.

[00:40:05]So I don't need to implement this because of that specific characteristic.

[00:40:09]uh I don't need to protect against that specific type of attack or area of attack because I have other layers there and I'm already good. The inverse what we have seen is ones that are commonly accepted and commonly implemented have typically been things like from our enterprise architect team where there is a published asset or a published standard that helps make some other thing easier single signon integration or particular pattern for react web app um and development teams were unaware of those standards and assets being available. So by putting them into the backlog, we've actually gotten some really big thumbs up from the development team saying, "Oh, you're actively making my job easier, not not doing the other thing you normally do."

[00:40:54]>> Good question.

[00:40:56]>> Yeah, I have a question about your app.

[00:40:59]So yeah, so the uh I think all of your client already has CMDB, but the main pain of the CMDB is what you doesn't know like >> correct.

[00:41:09]>> Yeah. So how do you like what tools do you use in the at NAV and how do you discover those?

[00:41:14]>> I promise I will not give names of tools because I cannot that was one of the promise they made me do there on the little room. He made me do it. Uh but uh think on a on all the different uh uh we can we can be a fair degree of transparent. So for example we look in code repositories that tells us what languages what assets. We look in the pipelines to see what other assets or artifacts they bring in. Look into the DNS record system to see what domain names they're registering. We have API discovery tools that we inventory the APIs out. We also have a couple of integrations.

[00:41:51]>> I'm sorry. Oh yeah, the ticketing systems. We also have integrations into the client's hyperscalers. So we get cloud asset enumeration. It's not that any of this data is like hidden. It's just that it's siloed and it hasn't been tied together >> and it's spread all over the the place.

[00:42:07]So finding where to get the right data and sometimes change the knobs, change the configurations in some specific tool so I can get the full data that I need to get the visibility. Uh this is part of the the work that we did. So so we actually had to go into every single one of our uh firewalls and ask them for to change a specific configuration so I can get this type of transparency. There were a lot of repeated discussions where, hey, we'd like to use this for security, but I don't want to give it to you, >> but we'd like to use it for security.

[00:42:39]>> A lot of that back and forth.

[00:42:41]>> Yes. Yes. But but uh uh with time, we got everything that we we believe is covering everything that we need. Uh the the next step in in my opinion is to get into the digital asset management like a full DAM. uh which means that all the libraries you have in your computer uh every digital asset you have I want to have visibility on those I want to kind of manage those so we have endpoints installed in every single one of the computers that I can uh grab the different Java versions that you have there the different net versions that you have there all the different libraries that you're importing into your code I can I can have access to those uh it's a little tricky but uh yeah we're getting there >> it's not it's not super exciting right it's not like bleeding edge research, but it is foundational in that how are you going to go on a journey? How are you going to have a map if you don't know where you are? Like how how can you plot where you're going to? Uh so it it it has paid dividends like it's it's wonderful.

[00:43:42]>> Does that help at all or do we miss the thrust of it?

[00:43:44]>> Yeah, you helped a lot.

[00:43:45]>> Awesome. Awesome. Awesome. Thank you.

[00:43:48]>> Um thanks for the talk. Very informative. My question is how do you expect developers to review security related PRs if they don't know like what the vulnerability is and what is the best way to fix it like if you don't train them on security issues and best practices.

[00:44:04]>> So this is part of the appsac bot actually. So instead of training the developers I train the bot to know how to do security properly. So we got our knowledge base on how do I perform false positive analysis. We document a lot of those put into a rag database. We use this to to talk to the develops.

[00:44:23]Developers like talking to the bot for many reasons. First, they are free to talk to the bot. I'm not logging any information because this client has a presence in Germany as well. Uh which means that I cannot log your uh interactions uh at all. I cannot log anything that can uh make you look bad in what you do. So, we do have some restrictions and they love it. They love the fact that they have they are free to talk to the bot. Second thing, the bot never starts a conversation. The developer starts a conversation with the bot. So the bot is a team's person there. You start hi and the bot answers you. The bot goes to our AD uh and the client ID and checks what are the developer permissions, what are the the uh the groups the developer is part of, what are all of the code repositories the developer has access to, all of the scan results, all of the vulnerabilities found in all of those things and give the developer back, hey, I saw that you have all of these scans lately on all of these applications to check in the code. By the way, we found 10 new verbates. Do you want to help to oh zero you want to help and then [laughter] we move there. So instead of a going and training the develop on everything on security they got a trained on the job on the fly and targeted to what actually matters for them >> and most of those conversations start from a specific vulnerability finding right so you get a a vulnerability finding and then you get walked through working on that vulnerability.

[00:45:57]>> Yep. So, it's not that we have to have them review security PRs downstream.

[00:46:03]They're usually looking at it very close to the point of detection where they have the rest of the codebase in context.

[00:46:09]>> Does that help at all or or have we completely missed the thrust of your question?

[00:46:12]>> Uh, I have a followup. I can ask offline.

[00:46:15]>> Okay. Sure.

[00:46:16]>> Well, I think I I think we have a couple minutes left, but if you guys want to leave, I mean, please >> are we being expelled from here?

[00:46:26]>> We have 15 minutes. Yeah. Well, folks, we are I'm at least here for the rest of sector. Um, we're happy to answer questions.

[00:46:33]>> Wait, >> you can go and ask directly. Yeah. Okay.

[00:46:38]Okay. Thank you set up. Thank you all so much for your time and attention.