Hello everyone. I'm GR Malu. I'm a cybersecurity risk consultant at Chevron. Over 11 years I spent across in working with investment banking, oil and gas, energy and consulting. Majorly focusing on CICD pipelines, DevSecOps, third party risk management, and AI security. Across the industries I have seen, one thing in common is it's not just your code gets you into trouble. It's about the dependencies, the CICD pipelines and the third parties wrapped around it. Today I talk about software, supply chain attacks and attacks. Just don't hit your application directly, but instead target the tools, dependencies, and the pipelines. You re, you rely on. These attacks have go grown by 700%, which is a significant amount in recent years, and now one of the biggest risk to the modern organizations. My goal in this session is to share practical, real world strategies you can apply to your own DevSecOps pipeline so that they become proactive and resilient. Let's move on to the next slide where we talk about critical threat landscape and supply chain attacks, and why supply chain attacks are so dangerous. A modern application is no longer just your code. It's built from open source library, third party software development kits and cloud services, and CAC retooling. Attackers have learned that it's they, if they compromise a trusted software, a delivery channel, for example, a built pipeline, a popular open source package, or an update mechanism that they can impact hundreds or thousands of organizations at once. Most enterprise applications today depend on hundreds of open source sub components, and many of those are transitive dependencies, and the teams don't even realize that they are using them. The lack, that lack of visibility creates perfect hiding places for the attack vectors. We have also shifted from monoliths to microservices and from OnPrem to hybrid or multi-cloud, and from manual releases to high velocity CI I CT pipelines. The great shift. That's a great shift of innovation. But that also means like attackers now have dozens of places to slip in. For example, package ies, build systems, pipeline plugins, and vendor APIs. Oas reflect the shift clearly and in OVAs top 10 for web. You see the items like vulnerable and outdated components and software and data integrity failure. In the O-S-C-I-C-D top 10, risks like dependency chain abuse, poisoned pipeline execution, and inadequate identity access management. That's literally a description of the modern supply chain problem. We know from data that organizations who implemented formal third party risk management programs and strong DevSecOps practices have significantly fewer incidents. So the message is clear. This is no longer a, just a checkbox or an edge case. Supply chain now has become a critical to application security and let's move on to those slide three. Aware we'll learn about will modern divesting real world examples and what their impact are. Let's first talk about SolarWinds, which is a classic example of build system compromise. Nations tech attackers infiltrated the vendors built up environment and injected malicious code into the trusted software update. That single update went out around 18,000 customers, including government organizations and large enterprises. The attack then started the customer. It started at the upstream in the pipeline. Let's talk about Log four J. We saw how one widely used open source logging library could become a global emergency. Most organizations didn't even know where Log four J was running because it was buried deep inside. Other components. This is the risk of vulnerable and outdated components, which are exactly OSP has mentioned in mid Stockton. In 2024, the CrowdStrike Falcon Update Falcon content update caused a massive outage when faulty security update crashed millions of windows systems worldwide. This wasn't a malicious attack, but from resilient perspective, it behaved like a supply chain failure. One update pipeline, global Impact. And with platforms like Snowflake, we have seen how attackers can abuse stolen credentials, or we can access controls in third party cloud data service to access many different organizational data. The common pattern is simple. The adversary writes on something we are already trust and update an agent, a library, or a vendor platform. Let's move on to next slide here. Let in response to these incidents, I have worked on defense framework that combines lessons learned and research industry standards and real implications across sectors like energy and banking. At high level, the framework has several pillars, and if you see shit left in DevSecOps, it brings security into planning, coding, and build stages. That means all the stages of software development Lifecycle L, and secure the CACD pipelines, lockdown identities, secrets and infrastructure for your build and deploy systems. Advanced detection use behavioral analytics to spot unusual activity and runtime application self protection to detect and block attacks from inside the application. Vendor risk management, continuously evaluate, monitor, and third party tools and the platforms. Zero. Trust architecture, never trust, always verify for every component, even internal ones in production environments. When we have applied this framework, we have seen faster detection of vulnerability, dependencies, and of measurable detection in tampering incidents and better containment during the potential compromises. I'll walk you through each of these pillars in the next upcoming chapters. Let's move on to the next slide with the. In this chapter one, I'll focus on how supply chain attacks have evolved and what it looks like today in our software development ecosystem, we have more from mostly proprietary monolithic application to highly con componentized systems that depend on open source managed services and cloud native coding. That shift has increased. Speed in innovation, but it has also multiplied trust relationships. Let's see some modern threat vectors. Let's first talk about dependency confusion. You think you are pulling, if you think you are pulling the company internal logging from your private registry, but your ci misprioritized the public registry and an attacker uploads the package with the same name. The build passes the test, even pass, and you have just to ship the attacker control score. And let's talk about hypo squatting. Hypo squatting. Attackers publish packages with the file names, with the small changes, or just deferred by one character. So that means like late night, the dev, the tire developer mistypes a name installs the wrong one. And the malicious payload isn't, it's simple, but still works and. Let's talk about the CICD compromise. What's worse than a compromised repo? A clean repo with a compromised build runner. The source looks perfect. The malicious payload gets in injector only at build or packaged package packaging time. The key idea in is that modern supply chain attacks are not random. The, they systematically exploit the way we develop and ship software. Understanding these patterns is the first step to defending against them. Let's move on to the next slide. Let's talk about why traditional security fails in this slide. Traditional security models struggle with the these attacks for a few re reasons. First, like first, older models are based upon stronger perimeter. We assume inside the network is trusted and outside is untrusted. Distributed pipelines, cloud services, and remote teams, that assumption breaks down completely. Second, many security processes are still focused on static checks at the end of the lifecycle. A final penetration test, a yearly audit, or occasional. Manual reviews, supply chain attacks, especially those targeting on CACD often happens in the middle of pipeline during the bills, packaging, or updates where checks don't see them. The third, when we fully trust code because it is slight signed or delivered by a well-known vendor, we forgot that signing only proves origin, not safety. If the bill system or maintainer is compromised, the signed artifact can still be malicious. This is why we need to change our mindset from inside is safe to continuous verification and defense in depth across the enterprise pipeline. Let's move on the next slide. In this, let's talk about the cascade. This is one of the most aspects of supply chain attacks is. Supply chain effect attacks these days. Imagine a single popular open source component. That component is used in dungeons of libraries, which then get used into hundreds of applications when vulnerability or back door appears in that one of the component, the impact cascades through entire system ecosystem. We saw this with a log four j. A single component far down in the dependency tree created crisis for many organizations that didn't even know that they were using, that the same Cascade Direct applies to ci, cd platforms and security tools. If a widely used build agent or endpoint agent, which out bad update like in the CrowdStrike incident, the consequences are global. Very huge. This is why we must treat software supply chains as a complex interconnector systems and not just individual applications. Let's move on to next slide where this is a chapter two, we talk about resilience, DevSecOps. In this chapter, let's talk about how to build resilience in your devs practices so that you can handle this cascade risk. The goal is not to slow the teams, but to secure, but to bake security into daily workflows, from planning, to coding, to testing, releasing and operating. We'll look at practical ideas like shifting security left into design and coding. Integrate security checks into integrate integrated development environments and pre-committed hooks. Continuously scanning dependencies and generating software, bills of materials and software builds of materials is a structured list of all components inside your software. I in. These are found foundations that make later more advanced control effective. Let's move on to next slide. Let's talk now. Let's talk specifically about securing the CICD pipeline because this is a heart of your software factory As a reminder, c. It's a, as it is continuous integration and continuous delivery or deployment. It's the automated systems that spool score runs, test to build artifacts and ships from them to production. If an attacker controls your CICD pipeline, they essentially control what you. The key controls include a majorly identity access management, ensuring that build agents, service accounts, and human users will all have least privilege only the permissions they absolutely needed based upon their role and secret management. Using the secure walls instead of hard coding credentials and configuration or code. Secret Ma. Isolated runners treating build agents as ephemeral shortlived mechanism that are destroyed after each job, reducing the chance of persistent compromise. Network segmentation. Make sure CICD components cannot freely. Every internal system, especially production databases, it's also crucial to manage third party plugins and actions used by CICD tools, each plugin in efficient, effectively code that runs in your pipeline so that there should be a review and approval process for what you allow. These measures align directly with ova top 10, CACD risks such as inadequate identity access management, dependency chain abuse, and poisoned pipeline executions. Let's move on to next slide where we talk the chapter three. Where we talk about advanced threat detection, even with the strong preventive controls, we have to ensure that something. Someday we'll slip through. Here we move beyond basic signature based detection into techniques that understand behavior and context. For example, monitoring CCD, unusual behaviors like a pipeline suddenly pulling a large number of new dependencies from unfamiliar sources. Watching for abnormal network connections from build agents or application containers. This is where security information and event management, CM tools and user and entity be behavior analytics can play an important role correlating events and highlighting anomalies that deserve investigations. The idea is to quickly answer the question, is the behavior normal for this system? If not, we have, we want to detect and respond before it turns into full down incident. Let's move on to next section slide. In this slide we talk about runtime application, self-protection, a key component of advanced detection in the ecosystem. Runtime application, self-protection technology that runs inside your application monitors its behavior in real time. Unlike a traditional web application firewall that send sits in your application. And this runtime application, self protection can see how inputs are being processed internally and can block malicious actions even if it play even if the play load has already reached the application. For example, if you have compromised dependency, tries to execute a suspicious command or attempts unexpected file or network accesses. REAP can detect that pattern and stop the request or terminate the session. So that would really help when I combine, when combined with these techniques like us. SaaS static application security testing, and the dynamic application security testing test earlier in the lifecycle. RASP provides laced last line of defense in the production line. In practice, we have seen that organizations use using R-E-C-A-R-E-S-P, especially for their most critical external facing services. Have much better chances of preventing vulnerability from turning into a breach, even when a supply chain flaw surfaces after deployment. Let's move on to next slide with the chapter four vendor risk management, which is very important. The, this will focus on how to manage vendor or third party risk management, which is absolutely center to the key to the supply chain security. Most of the organizations rely heavily on software as service, SaaS platform as service pass and infrastructure. As service as IAS provides providers as well as we specialize security and analytics tools. Each of these vendors become an extensive for your attack surface. Strong third party risk management programs looks at security certifications like usually reviewing the SOC two type two reports IS four 27,001 deficiency reports or PCI DSS where it is based upon the relevancy of the industry. The vendor own CICD and supply chain practices, do they use S-P-O-M-S Code Signing and Strong? I do. They have strong I identity and access management practices and there how their incident response system looks like process looks like. How quickly do they notify customers when something goes wrong? And ongoing continuous monitoring, not just a questionnaire at onboarding. It's like how they are doing the continuous monitoring and how we are monitoring our third parties continuously. Incidents like this, like snowflake breaches, highlight that it's not enough for a platform to be powerful. It must also be operated securely by both the vendor and the customers and vendor risk is shared responsibility and our. Detentions must reflect that. Let's move on to next slide, the chapter five zero trust Architecture. Finally, in this chapter, we we talk about zero trust architecture, which is never trust, always verify. Instead of assuming that anything inside our network is safe zero trust, assume that threats can exist both sides inside and outside as well. Organization In a zero trust model for supply chain and DevSecOps, we require strong authentication and authorization everywhere, often using multifactor authentications. Role-based access controls, treat every component, repositories, build agents services as needing to prevent its identity and registry. Cut. Continuously, not just once. Use code signing hardware, security modules, and sometimes trusted platform modules to anchor trust in hardware where possible apply microsegmentation so even one part of the environment is compromised. Lateral movement is limited. Zero Trust is not a just a product, it's a design philosophy. Applied if this is applied correctly, it significantly reduced the impact of compromised dependency tool or supplier because nothing nothing and no one is implicitly trusted. Let's move on to the next slide. To make this all actionable, I like to think terms of paced roadmap, foundation enhancement and optimization foundation in this foundation phase. And coming next three to six months, you can enable automated dependency scanning systems and start generating. O software builds and of materials for key applications. Begin code assigning for critical artifacts. Establish basic vendor assessment and T-P-C-R-M process. Enforce multifactor authentication and list platforms and critical SaaS tools. Enhancement phase in coming next six to 12 months. Deploy RASP runtime application self protection. For your most critical external facing applications, implement behavioral monitoring for CICD pipelines and production workloads. Integrate automated security tests, testing like SaaS and DA scans and container scanning throughout your pipelines Rollout. Continuous vendor monitoring instead of one-time reviews optimi at the optimization phase. It's cons. It should be considered as ongoing. Tune detection rules to reduce noise and focus on high risk anomalies. Optimize governance, so security control support, not block development velocity. Implement advanced capabilities like software at the station and a province tracking, for example, inspired by frameworks like supply chain levels of for software artifacts. This idea is to build progressively rather than trying to do everything at once. Let's move on to next slide. Let's wrap up the content. I want to written to key mindset shift, moving from reactive security to proactive defense. Reactive security waits for an incident breach, an outa outage, or a critical vulnerability, and then scrambles to respond. Proactive supply chain defense assumes that vulnerabilities and attacks are inva and designs resilience into the entire lifecycle. That means treating your DevSecOps pipeline itself as a primary asset to secure investing in visibility so you know what components you run and how they behave. Building layers of defense from design and development to build deployment and runtime monitoring. Organizations that embrace this approach are able to maintain development speed while drastic, drastically reducing the risk. You don't have to choose between agility and security. You just have to design both intentionally. And I would like to thank you so much for your time and attention. I would like to continue the conversation about DevSecOps and CICD pipeline security and our supply chain risk. Risk. So feel free to catch me upon LinkedIn. I'm always happy to exchange the ideas and real world experiences. I hope this talk gives you a clear starting point to strengthen your own pipelines and supply chain supply chains. Thank you so much.