Name: The Case for a Shift-Left Approach: Saving Time and Money by Understanding Incidents and Technical Debt
Uploaded: 2026-09-29T15:16:11.336Z
Duration: 57 min 16 s
Description: The Case for a Shift-Left Approach: Saving Time and Money by Understanding Incidents and Technical Debt

Transcript for "The Case for a Shift-Left Approach: Saving Time and Money by Understanding Incidents and Technical Debt": Hi, everybody, and and welcome today in, joining us in our presentation. I'm gonna start sharing my screen so we can all follow-up my presentation, and I will also introduce myself. Good. Everybody can see your presentation. So, hi, everyone. Welcome. Everyday engineering teams face a growing dilemma. How do we release software faster while keeping critical vulnerabilities of production? Over the next hour, we will look at real world data on how on software risk, the double edged sort of a generated code, and most importantly, how shift in security left transform risk into measurable business value. Thank you for being here, and let's get started. A bit about me. So, before we dive into our agenda, I wanna mention who I am. My name is Rodrigo de la Garza. I am an enterprise customer success architect at JetBrains. Over the past nineteen years, I have worked across every layer of the software stack from hands on developer and engineer, tech leads, and designer or architect of enterprise assistance. JetFrenz, I help enterprise customer align our products with their governance, scalability, and engineering requirements. I improve developer experience and modernize our development practice. So in short, my main focus is bridging the gap between architecture strategy and day to day developer operations. But let's move on into the agenda of the day. And here's what we're covering. I wanna start first with the current state of service security. So the common causes and reasons behind it. I wanna jump later into a personal quote code quality. I wanna talk about the value of prevention in service security. I wanna talk about my recommendations for an implementation strategy. And last but not least, I will be joined by a special guest and, doctor Vito de Razzo, CEO of cybersecurity company, NovoTech. And, let's get started with the current state of security. As technical leaders, we know that cybersecurity is not just a technology problem. It is a constant business challenge. Modern cyber risk has evolved from a simple technology issue into a critical business challenge. Compliance frameworks are no longer sufficient. Like new business challenge, demand that tech leadership work on prevention, and the recovery approaches against work case scenarios. It's rather than leave it potential issues until late stages. So picture this as an engineer. It's 3AM in the morning, and the phone rings with a notification about something going wrong. A server won't boot, or a database is corrupted, or your entire ecommerce store store is down. You're bleeding money minute by minute. So the on call engineers open the laptop, scrambling to diagnose the issue and restore the system. Sometimes it takes minutes. Often, it takes hours. By morning, leadership is demanding answers, like, we were offline, why did recovery take so long, where was the restoration plan, and how do we stop this happening again? In researching security gaps, one message came through clearly, reactive models are broken. And I'm here today because I believe in research proof, we can ship great code faster than ever without putting the business at risk. And I want to start with a list of security cases, and I did my best to find interesting and relevant ones. But I want to say that the world and history of cyber incidents is big, is long, and in many cases, is private, and it's making it difficult to talk openly or disclose what really happened. But let me talk about some of the cases that I found. The first one is the free software tool, Log four j. So the problem is, in 2021, this tool, that is internally by software and systems to log information, had a missing code validation that allow attackers to take total control of servers by simply typing a string into an input field that was then logged into the system. The cost, because this tool was and is still used inside the code of software and applications everywhere, 10% of all digital assets globally, that's hundreds of millions of devices, were instantly vulnerable. Sparking ransomware attacks in several different places and driving a 34% increase in total vulnerability flotation around the world. The second case I present is that is does not refer to a specific library or company, but it's a general security case and commonly known as cross site scripting. So according to the CWE website, which is a community developed list of common software and hardware weaknesses, cross site scripting takes the number one place on the list of vulnerabilities. And what is cross site scripting? It is a flow in websites. So applications or software that lets attackers take over the sessions. So, basically, the problem is attackers use cross site scripting to leverage website weaknesses. So allow them to hijack sessions, steal credentials, or impersonate customers. The cost. So according to IBM cost of data breach report two thousand twenty fifth report, the average cost of this kind of data breach is around 4,800,000, plus regulatory fines, legal exposure, and long lasting damage to brand credibility and customer loyalty. All this that no balance sheet can fully capture. The third case, and it's similar to the previous one, in that it does not refer to an individual library or company, but it's a general security issue named SQL injection. And it takes the second spot in the so that we see the release of vulnerability. So what is SQL injection? It is when attackers use an input field to save a simple text instruction. It's like typing a text was text into a text box on websites. Tricking the database into performing one direction, sometimes with extreme consequences. So, basically, the problem is, attackers use unvalidated or unsanitized input fields to inject SQL statement to a system. The cost is according to the same report. When SQL injection is used to exploit vulnerabilities, this has a cost per reach of 4,240,000. A real world example of this attack will be in 2008. There was a way of SQL injection attacks, which compromised millions of websites using an attack stream. And this is interesting because a solution exists for this issue. It is well documented and understood, and professional IDEs and developer tools help us even validate this, making this one of the most preventable high impact vulnerabilities in the list. The last case I want to present is the unauthorized system command execution, better known as OS command injection, and it takes the ninth place in the CWA list of vulnerabilities. What is OS command injection and how is similar or different to SQL injection? In OS command injection, attackers use an input field to pass a text instruction to the system, like typing a text into a text box. This text is interpreted by the operating system as a command that normally will not be accessible or will be restricted, tricking the application into executing this command in the system. So the problem, attackers use an invalid input field to inject a text that is in reality an open end system execution comment. The cost is according to the cost of data breach report to twenty twenty fifth, OS command injection fall under the vulnerability exploitation threat category and averaging a 4,240,000 per bridge. And here, I want to mention something that is important to consider. And when I say operating system, I'm not just talking about personal computers, laptops, or servers. So I'm referring to any device that has some kind of operating system and is connected to the Internet, or is connected to any other device, or, for example, has an external port like a USB. And examples can be internal routers, for example, at home or your work, any mobile phone, printers, or any Internet of Things device at home. And we saw the catastrophic impact of this vulnerability in the Equifax data breach from '2 from 2017, where attackers exploited an unpatched common execution flow in a web portal to run unauthorized comments, accessing 51 databases and still the personal data of over 40 145,000,000 people. And okay. Enough for the scary data in cases. So if anyone is not planning on sleeping on the next few days, I recommend checking the MIT AI risk initiatives, the AI incidents database, CVE reports, or CW list, where you will find a list of cybersecurity incidents affecting the digital world. These all are great source of understanding what is happening behind the screen. And let's continue. So engineering pipelines are facing an unsteady increase of volume code. This is caused mostly by the rapid adoption of AI by developers and coding teams. So according to CloudBiz 2026 state of code and bonus report, 52% of organizations have seen an increase of development output of code, and this has created a massive bottleneck in development operation pipelines. Testing and verifications are struggling to keep pace. The same report revealed that 70 of engineering leaders find maintaining test infrastructure to be a heavier burden than writing code, prompting an increase in automated testing. The report also highlights, like, a broader trend. Like, 81% of organizations are seeing more production issues than to the new abundance of Cheggett code. What we see is a snowball effect. Code generation increases, teams add more automation and more tests and ultimately leaving engineers with more maintaining tasks to manage. To understand how we fix security, we first have to look at why traditional prevention is falling from other companies. Most people assume major breaches happen because of flaw system designs. But Verizon's 2024 data breach investigation report revealed that sixty eight percent of all breaches, that is nearly seven out of 10, are caused by simply human mistakes. It is often a single tile developer leaving an endpoint unprotected or accepting a flow line of code at the end of the day. At the same time, our attackers are hunting for these exact mistakes. In the same report, it's mentioned that a hundred and eighty year over year searches in breaches caused specifically by attackers finding and exploiting vulnerabilities. And the speed of these attacks has changed completely. Today, attackers are deploying autonomous AI bots. These bots can scan over, corporate systems, find minor code flaws, and change them together at machine speed. An annual compliance audit or quarterly security scan simply cannot keep up with an attack. That happens in two hours, for example. So what can organizations can actually do? So we have to stop relying on slow, let's say, just audit. Instead, we must catch mistakes automatically right when the code is written. That means giving developers automated real time checks inside the Revitae tools and building continuous testing in our devices pipeline so vulnerabilities never reach productions in the first place. But, let's go back to the case as I mentioned before. Let's start with, Log four j, which represent one of the most severe supply chain failures in the last years. Like I said, a mistake in the code allowed unauthenticated users to achieve remote code execution by simply typing a malicious string into an input field that was logged into the system. So the reason behind this, many applications depends on external libraries without understanding or having visibility on their features or internal behavior. The takeaway of this case is, underscore that standard network differences like firewalls can be easily bypassed and organizations must have a deep visibility into their third party and open source libraries. Other case the other case I mentioned is across the scripting. So attackers use this exploitation method to steal login credentials, impersonate users, and access sensitive information with major business consequences. According to IBM cost of data breach 2024 report, that same year as '24, the average cost of a data breach reached an all time high of $4,800,000. The reason behind this is, here we can see the development pipelines normally prioritize feature delivery over security. The takeaway, we can prevent cross site scripting by automatically encoding all user generated content in the browser and enforcing real time security checks in our release pipelines. The next case I wanna show is, SQL injection. So, really brief on this attack. Attackers use an invalid external input fields, such as the one finding website forms, causing this input to be text or interpreted by the software of the system as an SQL instruction instead of ordinary user data. The reason behind it is simplicity. When writing code, it is simply just to stitch inputs together. The takeaway, so as I mentioned before, because the issue is well documented, the fix exists, and the solution is well understood, it is making it one of the most preventable high impact vulnerabilities around. The web hacking incident database on a report estimated more than half a million websites were affected by an incident in 2008. The better documented case being a payment system, where more than a 100,000,000 credit cards were exposed, forcing the company eventually to pay over a $145,000,000 in compensation from fraudulent payments. And the last case I wanna talk is OS command injection. Basically, some attack is not just limited to a server or a laptop or a desktop computer. Attackers are hijacking control at a system level. And that means anything connected to a network can be affected from Internet routers, printers, and smart appliances in our homes, and even industrial control equipment. Semi SQL injection based on the cost of data breach reports on twenty fifth, this vulnerability exploitation threat has a cost of 4,400,000. Reason behind it is a normal application, reuse code for simplicity, and even sometimes legacy system level calls on the tight deadlines. Breaches like Equifax mentioned before, are are caused by sophisticated server dies. They happen because known software flaws sits on patch in production. To prevent this, organizations must must move away from slow manual audits and implement automated dependency scanners and continuous pipeline checks that help us catch vulnerable components before even going live. Let's check by an agenda and step into the next session. I wanna talk now about approach to code quality. A preventive strategy is a transition from a reactive code fixing model to one that is preventive, mostly automated, and continuous. And that happens during the early stages of the software development life cycle. So according to IBM cost of data breach twenty twenty fifth report, implementing developer secure operations or DevOps is the number one factor in mitigating breach cost, reducing the average cost of a data breach by over $22,027,000. And just AI can mitigate an average of 223,000, American dollars. When we think about deployment secure operations pipeline or DevOps, let's not just think about process or a tool. Think better as a building and automated quality engine that protects every line of code as it is written. The reality of modern software development is according to Veracode State of Cybersecurity Report, 80% of applications are launched with at least one active security flaw. And over half of this application, that's 56%, contains high or critical security vulnerabilities. By improving the code development life cycle, for example, a professional with a professional ID with real time feedback and DevOps, it is possible to catch these flaws at the developer desk before they're even committed into production. And I'm talking about professional IDs that have code awareness features, code analysis, and code analysis acting as a deterministic guardrail. For example, scanning for SQL injections, vulnerabilities, deprecated or isolated code, or libraries or hard coded keys. And we cannot talk about code quality without addressing third party dependencies. While developers write secure code with professional IDs, applications are normally built using operational libraries. Like according to the Barcode, the status of a security report, 70% of applications contain vulnerabilities from important libraries. And based on the cost of data breach report, when a supply chain is compromised, it is averaging a cost of 4,910,000. And I wanna grab there's a graph that I wanna show I wanna show everybody. So looking at the security dev, that's the top part of the graph. Almost 90% of the, all security dev exist in on in our first party code. That's the blue line. But look at what happened when we focus now on the critical security dev. That's the important part. Almost 70% of vulnerabilities are coming from third party libraries and dependencies. So we are not just managing the code we write. We have to govern the software supply chain we import. And let's see so why preventing all these things are important? And that's gonna that's gonna take us to the next topic. Like, let's do a why prevention is where the value is. And let's go back to the core question, like why shift left? The equation is simple. The longer a security flow sits in our software, the more expensive and painful it becomes to fix. So look at the numbers. According to IBM cost of data reported in twenty fifth, a single data breach cost an average of 4,440,000 globally. If a massive breach compromises over 15,000,000 records in high value sectors like health care or finance, the simulated average cost skyrocketed to 375,000,000 due to lawsuits, long term brain damage, and regulatory fines. Now we might say, okay, we have security tools. We will just fix flaws when our scans find them. But the operational delay is getting worse. Peracore state of cybersecurity '20 report two thousand twenty fifth shows that the average time to fix server's flaws has jumped 47% since since 2020. That is climbing from one hundred seventy one days to two hundred fifty two days. That is over eight months of operational drag for a single flow. The contract here is fixing a vulnerability at commit time takes a developer minutes or hours at the desk. Fixing it in production could takes months of planning, auditing, patches, and delay releases. And let's talk about how tools like IDEs can help us here. Catching flaws at code level doesn't just improve security, it accelerate the speed of delivering good code. So based on Veracode, the status of our security report two thousand twenty fifth, first party code errors leaving system with half a life of eight months, and third party flaws up to twelve months. In fact, 28% of all flows remain open after two years. By shifting detection left and with the help of tools such as professional IDs, we can catch this box when the context is still fresh in developer mind. So according to IBM cost of data breach two thousand twenty fifth report, when a security team identifies a breach, this could save an average of 900,000 US dollars per case simply by catching the issue before an external party does. And let's talk about the big topic of everyone's mind and in the world, like AI. AI has completely transformed how fast we write software. According to the study, cybersecurity risk of AI generated code by the Center for Security and Emerging Technology based on Georgetown University, ninety two percent of US developers now use AI assistant in their daily work. But here's the catch. AI models don't think about security. They think about speed. The same study shows that 40% of code generated by early by commercial AI assistants contain severe security flaws. In fact, when researchers tested five popular AI models, 48% of their code snippet have real compilable bugs. This is because AI works on probabilities rather than strict logic, where the same prompt can produce different vulnerable versions of code. So does this mean we should stop using AI? I don't think so. The secret is using AI where it works best. Like, one example is an automated prevention. According to IBM cost of data breach 2020 field report, companies using AI for security and automation save an average of 1,900,000 per bridge and catch security threats eighty days faster than that stuff don't In civil terms, while developers use AI to write code faster, engineering leader can use automated security tools to check that code instantly. And this is how we get the full benefit of I velocity without taking on a massive security risk. And here's the paradox. The new abundance of AI generated code is an impression in our DevOps and QA teams, slowing engineering down right when we're trying to move fast. And according to 20 to the 02/26 state of code abundance report, 54% of organizations are seeing the DevOp infrastructure cost increase. 70% of leaders report on maintaining test suites is a major operational drag. And this, combined with the fact that 48% of organizations face a severe security skills shortage, this is driving the average cost up to 5,202,200. Another question is, what strategy or what kind of strategy we can implement around this? And then it's gonna take us to the next one. So let's talk about implementation strategy and how to actually execute this in your organization. So a question like, how can we improve our security, our strategy? And the strategy requires moving from a reactive five effort model to a proactive preventive model. The economics of the shift are highly compelling. The vertical itself security two thousand twenty fifth Reports may reports mentioned that moving to an integrated DevOps model and shifting security training directly to developers saves an average of 1,300,000 per bridge. Proactive internal detection of vulnerabilities, such as with professional IDs, reduces the bridge resolution window by eighty days compared to reacting model, like when like like when an attacker is actually exposes the exploit. By shifting quality checks left, we systematically reduce our long term security there. And, let's talk about how we actually make this in practice. So how do we shift security left without slowing down our developers or adding a mountain of manual work? An answer could be giving developers, professional security tools. Think of it like a real time spell check for code. Right? An engineering types that is something flags security flows on the desk. And we can embed it automatic guardrails direct into the CICD pipelines. Every time the code is submitted, automated scanner tested. According to IBM cost of data breach two thousand twenty fifth report, embedding automated AI and machine learning insights into DevOps pipelines cuts cuts an average of data breach by 223,000 US dollars. On top of that, connecting these automated pipeline checks into a centralized platform, let's say a single dashboard that tracks security events across the enterprise, saves an additional of 212,000 per bridge. Together, these two automated controls take over over 435,000 US dollars in risk of the table per incident. By putting smart tools in our IDEs and CDICD pipelines, we turn security from a slow human checkpoint into a fast automated safety net. And so what about end to end governance? So based on IBM cost of data breach two thousand twenty fifth report under article, what is a SaaS sprung, 63% of organizations have zero governance policies for AI tools. 48% of enterprise applications are completely unmanaged. And it's also mentioned that only 36% of executives manage their engineering and AI investments as an integrated portfolio. So an effective implementation strategy requires end to end governance. And governance isn't about slowing things down. It is about implementing an a centralized observability space service. So every tool, package, called artifacts or software, AI model inclusive in your stack has a clear accountability. By deploying observability tools, we can break down silos establishing a single view of our software assets and automate the discovery and governance of shadow applications. Like, where do we go from here? And as we think about what we're covering today, it comes down to a shift in how we approach security and engineering. So perimeter defense alone is no longer enough. Like, sophisticated threats require technology leaders to build resilience directly into the software development life cycle. And incorporate a software maturity framework that comes down to three things, clear visibility across your entire pipeline, equipping your teams with professional integrated tools, and give them the framework to prioritize the bugs that actually matter. And I wanna conclude the first half of the presentation with, four key points of implementation strategy. The first point is shifting from a reactive to preventive. That means moving from a reactive, fine and fine model to a proactive preventive model, such as integrated development secure operation or DevSecOps model, which which can have significant savings. And I I wanna give everybody two questions that you can take to ask yourself or to take in back to your organization or discuss to your tech leads. And the questions are, so what percentage of your security budget or engineering time is spent catching flaws before deployment, for example, versus fixing incidents in production? Another question you can ask yourself is, if if a critical flaw is discovered in production today, do you know how much time, let's say on average, it takes your team to identify and contain it? And do you know the daily financial impact of that delay? The second point I mentioned was enterprise coding tools. So this means equipping our developers and engineers with professional secure enterprise IDEs, code analysis tools, and automated coding tools integrated into our development pipelines. And now ask yourself, do your coding tools, your current coding tools, warn developers about security mistakes instantly while writing code? Or are developers finding critical bugs right before going live? And as your teams adopt AI coding assistance, do you have quality checks in place to verify the generated code before it gets merged into production? The third point, is end to end governance. Deploying unified quality tools that gives an overview of all our deployment applications. So with the goal of establishing a single view of our software assets and automating discovery and governance of Java applications. The questions you can tell yourself are, do you have a complete, maybe even real time inventory of all active software assets, services, and AI tools across your organization. And this include, like, unmanaged or server applications. And when an unmanaged application or open source dependency breaks or suffers a breach, who is accountable and or who is the main contact for that application? And the last point is measuring impact. So this means monitoring the strategy and ensuring that it's succeeding. It is possible to track and measure performance like an industry benchmark and better understand the infrastructure and tech stack performance. Now ask yourself or your team. So what is your organization average flow half life? Like for example, how many weeks or months does it takes to your engineering team to resolve 50% of the discovery flaws? And lastly, my favorite question of all, and it's based on my own experience working with many different teams, is shrinking your backlog or box an engineering goal? I mean, are you giving your engineering teams the dedicated time to work on old box and security risk? Or are you only tracking release speed and new features? I encourage you to take these questions back to your organization and use them to start a conversation with your new teams and tech leads about your current processes, tech stacks, and infrastructure. We have come to the end of this presentation, and I thank everybody for your attention. We are gonna switch gears now, and I will introduce a guest who will join us for the second part of this webinar. And I wanna welcome, doctor Victor Delraza, CEO of NovoTech Solutions. And I will let Victor now to introduce himself, and I will stop the presentation a little bit. Victor, are you around? Hi. I'm there. Hi, Rodrigo. Thanks for inviting me. Hi. Hi, Hi, Rodrigo. Victor. So my name is stop. the presentation a little bit. Sure. So my name is Victor. I I am, like, managing director of NovoTech Solutions, a cybersecurity consulting company in Germany. My background is quite mixed. So I I did a PhD in in Germany on computer science, and I was working very long in different, areas, but all had to do with technology. And since the last ten years, I've been doing cybersecurity consulting for large consultant companies and large enterprise customers. And since, last year, a founder of Novatech Solutions. Yes. Thanks for the invitation. Thank you, Victor. And, in our conversation with before the webinar, you shared with me some insights that helped me a lot to shape this presentation and not to mention point in the direction of really great sources of information. And, I remember you mentioned how big the I asked I asked how big the world of cybersecurity was, and especially now with AI in the mix. And I want to bring today, like, that kind of similar conversation we have to the audience, but focusing more in the part of, catching security risk in early stages of development, what is normally called, the Internet shifting left. And I wanna start with one with the first question, Victor. So from your point of view as a CEO in cybersecurity, how has the nature of sovereign risk evolved over the last few years? Like, is defensive security a reality, and is it struggling to keep pace with the modern threat landscape? Yeah. And so I think defensive security is something that a lot of organizations already do. It's not that that's most of the organizations have a security department, and they are more or less well staffed, and they do most of the stuff okay or right. I think the problem now is that the speed at what things have to happen has changed. So if your process are not mature enough and and if your automation capacity is not high enough, you start having challenges behind it. So I I actually wrote a post shortly about this. So McKinsey, like, published, Mhmm. like, an interesting article on how this speed from the attacker's perspective is becoming a problem in organizations. So when you think about shifting left, the more you shift left, you can you are more able to, like, you are able to react faster. That's true. But. on the other hand, how you choose to shift left makes a difference. And in that sense, being assisted by technology and nowadays by AI plays also an interesting role on this topic here. I understand. Thanks. And I think people can reach out the LinkedIn to share, you can you can share again your post of, the the article from McKinsey that you mentioned. I have a follow-up question. Look. What what do you think what did you say again that organizations are not ready for that speed? Yes. So, like, when it terms in terms of reacting, so think. about vulnerable code. Like, if there's, like, a new CVE and there's a lot of and then you realize there's there's a vulnerability in your code, how fast are you able to, first of all, figure it out? Mhmm. Mhmm. Second of all, understand if this vulnerability is hard in hard like, it's it's a risk for exposure and then fix it. So and this kind of triage is done nowadays mostly by humans. So they. receive the CVE. They check what could be the potential software, impacted, and then they decide if this software or or assets that are impacted are risky enough to be patched or not. And if you do this for one or two vulnerabilities, it's it's it's manageable. But now we are facing an increase. in the amount of vulnerabilities per, like in time. So this type of approach becomes very difficult to manage. Got it. Got it. And, yeah, I agree. And and a follow-up question in the same topic of speed, and and you mentioned and it's really you mentioned and it's also relevant now. So we are seeing a boom in software creation velocity and largely because of the usage of generative AI encoding and coding assistance. And from what you have seen in the field or, like, in your industry, how is this massive creation of automated code impacting the balance, between development, speed and software quality? so there is a lot more code being generated, and that's that's the reality now with AI. So the more code you have, the chances that the that it's vulnerable increases theoretically, nearly. The problem is, of course, that when you have AI generating code, the quality that can cover can come out of it could be from quite good to very bad. Mhmm. And so and so if you don't want to to have these problems of, like, exploding or exponentially growing, vulnerabilities in code, you have to understand that you have to deal in code quality in a different way when you're using AI than when you're using normal code, and you have to be able to test very fast your code for problem security coding and vulnerabilities as well. Yeah. So so the the sweet spot between quality and speed, it has to be found. And. I mean, you need to have tools or, like, methods to ensure that you can scale in speed as much as you can without scaling in potential negative size of the. Got it. And so when thinking about this speed and and generative AI, I'm I'm thinking about the nondeterministic part of AI. And so this non determinism introduced a unique challenge from engineering teams. Right? So basically, the same prompt generate different code variations. Thinking about security in this aspect, like, how security and development leaders can adapt maybe their testing methodologies to manage this kind of risk, this kind of risk? Yeah. So I think there are two parts of it. The first one is you have to understand how to reduce this this valuation as much as you can. You cannot reduce it totally, but you can make sure that things go in the direction that you want. And so, for example, doing good key skills engineering for for AI based. coding helps a lot to make the right sense. And then once you have this, like, acted not once you, but you have to do it in parallel, you also have to have have, like, enforceable coding policies for the agents. So things that say, okay. This is not allowed, and it's not because please don't do it in the skill. You have mechanisms to avoid this happening deterministically. And. one very important thing is if you create test cases, these test cases shouldn't be visible to the coding agent. So if you have an agent creating test cases, the agent creating the test cases should be a different agent create. That is coding the the, you like, who is writing the code. So this separation of, like think about how you would do it in the in the previous time. So you have, like, like, the test department was not the same as the, like, developing department. So, like, splitting these roles helps you also to to avoid certain, cheating mechanisms from the AI agents. Let's call it like this. Yeah. So it's, like enforcing no and something. And and you mentioned something interesting, like, codicing code coding policies. Sorry. And this make me think a bit about regulations and maybe standards. And so there is in some industry, there is tightening of regular regulatory laws and compliance standards. And we are seeing a shift away from, like, point in time security audits. Like, my question is, how do how do you think organizations can transition compliance from a manual let's say manual paperwork, manual work exercise into more a continuous automated process with the development pipelines? Yes. So I think in that sense, companies have to start answering the questions on themselves. If if this compliance thing is only having the paper proving that you have certain compliance level at a certain point of time, or it has to be changed into a more, like, permanent statementality. And, again, the risk of this constant change and increasing, threats push me to tell you you should go to the continuous approach. Now how to how to reach this continuous approach? You have to change things at the organizational level and the process level. So there has to be ways to to allow showing compliance in a less complicated way than a full blown audit, Mhmm. and you have to implement technical measures that allows you to ensure and enforce compliance on, like, online, on run time and also in the developing life cycle. So, for example, if you create, infrastructure using infrastructure as code, it will show you have certain policies that that ensure this level of compliance. And if these policies are not followed, then the deployment doesn't continue. And. a person is assigned who is responsible to to solve it, and this assignment is also tracked in terms of SLAs. And therefore, you have, like, a more automatic way of ensuring continuous compliance. Yes. Okay. I understand. And part of this, compliance, part of these processes can also be influenced or managed by AI, I believe, in your experience. Like, I think the influence of AI changes how how how compliance will look like. You, of course, can use. AI to identify places where you can improve compliance, and you can use AI also to to help you automate things. That's definitely the case. Yeah. But I think just mentioned that it's it's another reality. No. We have to somehow now in every new kind of process, new pipeline, there should be probably involved in certain points. So we we have to, in the future, learn a little bit to play with it and incorporate it, I believe. Yes. It had to be considered in your compliance model. Definitely. Yes. Got it. And something interesting came to my mind, and this is also based on my experience. So, like, first, I I remember in my early experience as a consultant, I remember when I had to talk with or I I talk with a have a conversation with a president of a company. And that person will use a lot of technical words in the normal chat with me. But when I was replying using those same technical jargon for Gola, I don't think I was passing my my message to that person. And and with that, I wanna give you to another question. It's in a different topic. So I a common frustration from some leaders is translating technical concepts like the one we're mentioning here, software security, etcetera, into a language that nontechnical, let's say, board of directors can understand. So when presenting to a board or to nontechnical leadership, how did you recommend framing risks, for example, so they, so they are aligned with these objectives rather than sounding like an IT alarmist? Yeah. So, like, unfortunately, the the method that that usually come the best or comes, like, has much more convincing arguments is the alarmist one. So, like, managers or leaders or or owners, they they become much more aware of of security if they already been a victim of an attack, and that happens constantly. But there are also ways to deal about it. So if you go at board level, they have you have to understand that they are looking either into costs or benefits. Yeah? Mhmm. So, like, security is very abstract on that sense. And, usually, it won't save you a lot of costs on the operations as it can save you cost if something happens. So, what you need to to to show them is how you can you can improve your security processes and therefore make, for example, the development life cycle faster. This kind of argument helps. Like, also saying, okay. Let's invest on better security process and tooling so that the developers are not so annoyed about the security process and are willing to deliver better code without having to correct it all the time. So, ideally, you have, like, a way to model the concrete benefits either as cost savings or, like, productivity improvements that come out from a security initiative, and that usually brings better results than explaining that. security is important. explaining. Yes. Mhmm. Got it. So, I I just saw a question is what, about shifting left. So when when shifting security left into the DevOp pipeline is normally accepted as good practice, but security is still sometimes view as an operational bottleneck. No. A lot of developers, engineers see that. So when you speak to other executives, how do you translate the term proactive security into their business outcomes, like cost efficiency, product velocity? Yeah. And so, I think that the understanding that it is cheaper to discover security, before it's there. So I think leaders understand that it's better if you shift left. Mhmm. I think the problem is the strategy on shift left and how the operating model looks like. So what I saw in companies, especially very big ones, so the way they shift left is that they they assign security security assessors or security checkers, very early in the project. So instead of coming with a security checklist before launch, they come with a security checklist at the beginning of the break. That says helps somehow because at least creates awareness what needs to be done, but it doesn't help the developers to to deal with it, and it's also causing more work for them in some perspective. So, you need to find ways in which you use the resources that you have, in a smart way, Mhmm. and make sure that you provide developers with tools and method and methods to make secure so to make their products better rather than with list of things they have to cover without a clear guidance of how to do it. No. It's a so tooling. Not the correct tools is is big part of this is. the tool is that that developers and. also this this cultural thinking that Mhmm. that that security is not the one stopping and say, no. That's not the way to do it because it's dangerous. No. That's the best. But it's it's the one to tell you how can you make it secure and still work and helping. So this this this cultural developers versus security engineers to to break it a bit and to understand they can work together to find good solutions. Got it. Got it. So so it does a bit about the DevOps part, no, of of the development we're talking. Yes. And so about this, Delo, a a major hurdle in DevOps is winning, let's say, the minds and hearts of software developers. Right? So if a if a security tool feels like a roadblock or, like, developer will find a way to work around them. So based on your experience and and successes, how can leaderships build a collaborative, maybe developer focused security culture where engineers feel they have power and they have the control rather than being audit? Yes. I think the first the first part is letting like, understanding that they need to talk to each other. So the. best way, like, a security professional can deliver value to the development team is if we understand what they need. So what you mentioned, like, at the in your talk, for example, this this this security assisted, software development, environments. This is something that's, let's say, the security guy recommended to have, and the developer know this. Okay. This this is good. This helps me. This saves me time. if it's properly set up and if it's properly designed. Another idea that you can have is, for example, predefined architecture. of blueprints that already have security checks embedded. So instead of failing, you have to take care of these security checks, and you have to make sure that they are done properly. So but you can give him something already pre done that he can start working on without having to think about all these things first. And there are a lot of, like, blueprints that you can use that would apply to a very large part of your use cases, and that can save a lot of time. And that's that makes also the developer a lot fast a lot faster. Mhmm. Mhmm. I I just wanna a quick follow-up question on the security checks part. Is the security checks, it's a role or it's a process or it's like a or it's a tool or what what else or could be anything, security checks that you mentioned. It's based more, the question. it's it's like the security checks precedes like an activity you do, but how you deal with it is either like, it's a combination of tool and processes and a bit of code. Got it. the tooling do the make the findings, and how you deal with the findings, and how you choose when to to apply the tools, how to apply them is important. So, like, the tools alone won't help because if you, like, make a security scan and find 150 security issues, Mhmm. don't have anybody who can't deal with them because they're everybody's busy doing something else, then it's not helping you. If you don't have a way to track that these things are done, to evaluate what's the impact, to assign responsible Mhmm. to give enough incentive for for a a fast solution, then the tools themselves are not going to work. On the other hand, a lot of good intentions won't won't help if you don't have enough tooling to to your work in an efficient way. Yeah. Yeah. I I follow-up. Thanks for that. And I just have one more question, Victor. Let's say when when we're talking directly to engineering leaders or, directors of executives that are listening today, if they recognize they have unmanaged over assets or blind spots in their tools and also AI pipelines, what what would you say is something a a critical step they can do to begin building a resilience, proactive software ecosystem? So I think the one the first step is always visibility. So, do you know not only what you have, but what you need to protect? So. is there shadow IT involved? Are there people that's shipping products on your company's name that you don't know about? This kind of things is important. Then you have to to understand if you know which are your crown jewels, so which are the assets that you need to protect the most because that's where you start. Right? Then you have. to think about what what alternatives you have to to deal with your shadow IT. And if you are in in the position to define or identify responsible for every system that you consider critical for your organization, and if you are able to risk to measure the risk of what happens of each of these systems failing. And I think that's the first step to start understanding where do you need to put your resources in terms of security because if you try to fix everything at once, it becomes very difficult. Mhmm. Mhmm. No. Yeah. I understand. Okay. So I'll I'll refresh a lot of the four key points that I was mentioning. Thank you. And, Victor, I I just wanna share again the presentation because, that's it. People can reach out. I wanna share with the presentation, and I wanna say, thanks a lot, Victor. Please, anyone you wanna reach Victor. He's his LinkedIn. It is his, his connection. And, Victor, thanks a lot for joining us today. Thanks, Seel, for your time. And we are really close to, our time here. I wanna do a a a closure on the presentation. So let's let's tie together the most important points we saw today. So we learned that when presenting to nontechnical decision makers, we can skip the abstract alarmism. Instead, we can frame security around concrete numbers. So the cost of implementing garrials versus the probability and devastating price tag for breach, for example. We also learned not to make a mistake of simply moving security auditors early in the time frame, which we saw that, this creates an operational bottleneck early in the process. Instead, we can make security a developer first tool. So equip engineers with professional tools, assist an automatic checks in their IDEs to help them do their job faster rather than feel not make them feel like it's an audit. We also saw how to tackle AI velocity with a strict determinism testing. While AI codings are fast and nonterministic, your taste test your test cases must remain solid and completely invisible to AI agents. And also, finally, let's start with visibility on Monday morning. So you cannot protect what you cannot see. So ask your teams, like, do we know our crown jewels? Do we have a handle of an hour out shadow IT or unmanaged apps? Is there a clear name owner for every system? The bottom line takeaway is is prevention should not be a roadblock, but the safety net that allow us to innovate safely. And with that, I wanna thank every thank everybody who is joining us right now in the webinar. Thank you a lot for your attention. Thanks a lot to Victor, for your questions. I'm gonna leave a little bit again your your slide, Victor, so everybody can reach out to you if they have any questions. And please add us a LinkedIn, and we can have any follow-up conversations out of there. And, thank you a lot, people, and have a nice rest of the week.