Hi everyone, and thank you for joining this session today. My name is Baskar Savan. I work as a team lead and full stack software engineer. I'm also an I Triple E senior member with the Southeastern Michigan section. I have spent around 15 years building and improving the develop pipelines, automating the workflows, and strengthening the delivery systems. Over the last few years, my focus has been on supply chain security and AI driven automation, helping teams adopt SBOs Provenance and SLSA so they can deliver the software that is both fast and secure. Today we are talking about the supply chain defense by default, SBOs, SLSA, and provenance in CICD. This talk is focused on the practical security, not the theoretical framework, not the security checklist that sit in the document. No one really read, and definitely not the heroic. That depends on the individuals remembering to do something manually. Instead, we will look to how to build supply chain security directly into the pipeline so that the secure path becomes a default path, and the developers are not slowed down by the security controls. Security becomes a natural outcome of the way system works. The landscape of the software security has shifted dramatically 10 years ago. Attackers focus mainly on the application level issues, SQ injection, cross script scripting con misconfiguration, but today they are going upstream and attacking the software supply chain. They're targeting open source dependencies. Package managers, CICD building systems, artifact repositories. And the automation that ships code into the production. Modern day pipelines move fast, which is good, but fast pipeline that lacks transparency or verification can become the blind spot, and attackers loves blind spots in many organizations. CICD becomes the most trusted system, but ironically, least verified. Recent incident shows us why the supply security chain is urgent. Solar Wind scale wasn't an application. It was the build system itself being compromised. Log four J wasn't a failure of application code. It was a failure of visibility into the dependencies. And the XZ backdoor showed us that even a long term open source maintainers can become attack vectors. These are not isolated cases. They are part of the pattern. All of them teach the same lesson. If you can't see what your software supply chain, you can't secure it. Security teams were blind spot blindsided, not because the vulnerabilities were impossible to address, but because they lacked visibility, traceability, and the proof of where the software came from. So what does defense by default means? It means building security into the pipeline so deeply that developers don't have to think about it. Security is not a separate process, not a afterthought, not a manual approval. It's simply how the pipeline operates. Every bill automatically generates the evidence which needed every artifact carried. The metadata that proves is trustworthy. Even a deployment is verified by the platform itself, not by the person. When the security is by default, it becomes the consistent, predictable, and scalable, and the developers can stay focused on building not policy. ASBOs software build off materials are one of the most effective tool in the supply chain defense. They are basically ingredient list for your application that tells you exactly what's inside your core base. But here is the important part, and ASBOs only works if it's generated automatically. On every build and stored with the artifact when vulnerability hits log four J, you shouldn't have to scramble. You should be able to instantly answer are we affected? Where are we affected? Which versions are impacted? Organizations that had the s om generally generator automatically handles the four J law, four J in our organization without SBOs pen dates. Even some weeks just figuring out where to start. This is why the SBO M aren't just paperwork, they're operationally lifesaving. Provenance answered the critical question. Can we prove how the software was built? It's a full chain of custody of an artifact. Who builds it when it was built? What source code is used, what pipeline executed it, and what environment it ran on. Attestation are simply the sign proof of this information. This stops attacks. Someone insert inserting a malicious image into the registry. A developer pushing a local bill by accident, or the compromised ci runner injecting something harmful. If provenance is missing or incorrect, the artifact should not be deployable. And that's not something human should decide. It should be automated and enforced by the system. The SLSA framework gives us a path forward. You don't need to start at the highest level. You start where you are and match your over time. You begin by ensuring the bli bills are logged. Then you ensure bills run from the version control scripts. Then you add provenance, sign signing, and eventually you reach the ame reproducible bill. SLSA is not about perfection. It's about making each link in a supply chain stronger. Even small improvements make a big difference. Once we begin strengthening the pipeline, several important controls comes into play first, keyless assigning CI pipeline, gender temporarily identities. Instead of re relying, replying, relying on a stored private keys. Imperial Runners built environments are de destroyed after each run to reduce the long term compromise. Immutable artifacts once published artifacts cannot be si silently, swt, or replaced deployment and verification. The platform checks signatures and prominence before allowing the deployment. This means the system, not the humans validates trust, and that's the only scalable way to secure the modern delivery pipeline. Run in isolation with no network access and no ability to face the unknown dependencies during the build. They rely on a pre-approved PIN components. Reproduceable Bills ensures that the same input always produce the same output. This lets us detect the tampering instantly. Together. This approach transform your pipeline from open work shop into the control environment where every input and output can be verified. Dependency hygiene might sound simple, but is one of the most impactful thing you can do. It means pinning versions, reviewing all new libraries, avoiding floating dependency versions, and preventing automated updates from bypassing security review. This keeps the unverified code from sneaking in silently. One of the most common way attackers get into the supply chain code dependency hygiene creates the stability and predictability. Let me share the practical example. That shows how powerful these practices can be. Before implementing the supply chain defense, one team was deploying the microservices to the Kubernetes. Their pipeline was fast, but not verified. Deployers could push local images into the registry. ASBOs were inconsistent, and Providence wasn't enforced. When the log four J Crisis hits, it took almost a full week just to locate the affected services. Now let's look at the after. Once they adopted the supply chain defense, by default, every bill was signed automatically. Every artifact produced the SBOs Bernet enforced signature verification and dependency. Metadata was centralized. Later during the simul simulated vulnerabilities event, they identify all the impacted services in a minute. What's beautiful about this is that security improved, but velocity didn't drop. Pipeline becomes safer without becoming slower. That's the ideal balance. Deployment is a movement where the risk become real. Everything before deployment is a hypothetical. Risk deployment is the point of no return. This is why the deployment, time enforcement is. If the artifact lacks the valid signature or provenance deployment should simply fail, not with an email, not with a warning. Just hard stop. This prevents the accidental deployments, malicious insert, and unapproved builds. Think of it as a last checkpoint, the final quality gate before the production. One. One of the biggest misconception is that the supply chain defense requires a massive all at once transformation. It isn't. You start small, begin by generating SPO automatically. Then add signing and provenance in ci. Verification in staging, and once the process is stable, enforce it in the production. This phased approach, the delivery smooth and builds organizational. Let me add one more important piece that often gets overlooked. The cultural shift. Supply chain security is not just about tooling problem, it's a mindset shift. Teams need to move from, we trust our pipeline to our pipeline. Pers it can be trusted. They need to move from. We hope our dependencies are safe to, we know exactly what we are shipping and they need to move. Move on from security slows us down to security. Done right, speed up. By preventing the emergencies, the real transformation happens when developers develop engineers and the security team all see supply chain defense as a shared advantage, not an optical. When the shift happens, adoption becomes smooth and natural. Here are the few key takeaways from our discussion. First, the software supply chain has be, become one of the most active cybersecurity battle work. Battlegrounds attackers are targeting dependencies, build systems, and automation, not just the production apps. So if we don't secure the pipeline, we can't secure words comes out of it. Second, the strongest defense is the shifting security into the CICD process system. Ev when every artifact is signed, stress able and verified automatically, we reduce this risk without slowing down the delivery pipeline. Trust become the application trust. Third, the tools and the practices were dis, were discussed. As bombs, ance attestation, SLS, AMIC bills and the deploy time verification are not theoretical. They are practical adopt steps, adoptable steps that any organization can start implementing in phases. And finally, remember this security should not depend on a late night heroics or manual checks. It should be the default outcome of how we build the software when we design the pipeline that enforce the security automatically. We protect our systems and empower our teams to innovate with the confidence. Before I close, I want you to leave with this. Security shouldn't depend on the people remembering the steps. It should be the build into the pipeline. So every release is trusted by default. If we can make supply chain security automatic, we make our team faster, safer, and more resilient without slowing innovation. Thank you all for your time and attention today. If you have any question, you can reach me on my LinkedIn id. Thank you. Thank you.