 So hello everyone good afternoon. I hope all of you are having a great time at the Red Hat Dev Nations Day and also getting a lot of knowledge and insights. All of you enjoyed the Gulab Jamun at the lunch. In the moment happy to know I know Gulab Jamun was not served today. Cool. So you are all awake and reshaged I believe. So I am Ramya Raghvira. I am a specialist solution architect with the Red Hat Partner Ecosystem. I specialize in DevSecOps, developer productivity and application modernization on Red Hat OpenShift and today in this talk me and my colleague Ramki will take you through how you can actually secure your app using DevSecOps. Security is the number one priority of all our enterprises and we all need to know how can we secure our enterprise software. But then why is it of really utmost importance to our organizations? So throughout the day you would have heard how open source software has literally eaten the world. Two out of the organizations currently are using open source software to augment internal development of new applications. 600 is the estimated number of open source software, open source components which are there in any given software. And around 90% of search code bases have open source components which not have been had any maintenance or further development in the last two years. 31% of search code base have open source components which don't have any custom or any license for that matter. So with the introduction of the open source software we are seeing new vulnerabilities and new threats which are coming into picture every day. This is even increasing the surface area for the threats. For example, we all know how easily a malware can be injected using chat GPT. Hence with the arrival of the open source it has become the need of our that we have security as a fundamental and ongoing aspect of our SDLC. We have the secure supply chain for our organizations software supply chain and make sure that we build secure applications. But why do we really need to build secure applications? These numbers are itself the answer. In the last three years there has been a 742% annual increase in the software supply chain attacks. And one out of these five data breaches are due to a compromise software supply chain. Average cost of a data breach has increased to 4.45 million and the ransom paid is actually a mere fraction to the overall downtime and recovery cost of the data breach. The companies have to go through prolonged lawsuits and also provide recovery settlements to their users because their user and financial data has been compromised and exploited. DevSecOps mindset is a solution to all these problems. 78% of executives have taken initiatives to increase collaboration between DevOps and security teams to ensure that security is moved left. 92% of IT leaders say enterprise open source solutions are important as their businesses are accelerating faster and moving to the open hybrid cloud. Now switching gears from software to automobile. When we buy a car we expect each and every part coming along with it to be genuine. Higher the price of the car more is the expectation on the genuineness of the parts. Raise your hand if any one of you would be okay to buy a car where the seller says I'm responsible for only 75% of the parts and 25% you have to take care of yourself. Anyone? Definitely. Search a car will not have any takers. So we need the genuineness because it proves that the car is durable and safe to drive not just in the short period but even in the long run. But if we really come back to our software industry can we really have the same expectation that we know that each and every part component of the software is genuine. For that in the first place are we all really aware what are the components which are there in our software. Many of us are not aware what are the different application dependencies or libraries which come as a part of our software and this results in security breaches which has led to huge losses to company and even affecting their brand value and reputation. All of us would have heard about the infamous solar wind attacks around where basically so many companies were affected and even the customer data was compromised. So we need to know about each and every part of our software and even make sure it is secure. But is it really feasible to achieve this? The answer is yes. So, okay, sorry, my bad, it went back. So how do we really achieve or make sure that our supply chain is secure? The answer is we need to make sure that each and every phase of the SDLC is secured. From the code phase, we need to make sure that malicious code is identified and prevented. When a new piece of code is being inserted, we need to take care that there are no vulnerabilities which are introduced or if any bad code is inserted. Then when we move to the build phase, that is where our application pipelines come into picture. We need to safeguard the build systems early with DevSecOps in our CI CD pipelines. Other thing comes to the monitoring. Continuously, we need to monitor for security at runtime. Observability is the key. So when we spoke about it, let me tell you how we at Red Hat can help you with this. So all throughout the day, you would have been hearing how we at Red Hat work on hardening the open source software to make sure it is enterprise ready for our customers. Red Hat has around 30 plus years of proven experience of providing enterprise open source software to their customers. We provide secure services and platforms which enable you to automate, test and build secure applications using DevSecOps. We provide strong distribution mechanisms with signed packages. All of you would have known or maybe whoever has heard or worked on RHEL would have known about RPMs. The Red Hat package managers, which is a secure distribution mechanism which we offer as a part of our super secure OS. Sorry. So we at the Red Hat Summit had in May had announced a set of services which comprised the trusted software supply chain. I believe you would have all heard about this from Amita in the keynote. So this talk, we are going to go in more detail about the Red Hat trusted software supply chain. So Red Hat's trusted software supply chain is a set of services delivered with integrated security guardrails at every phase of the software development life cycle. With the Red Hat trusted software supply chain, we make sure that both the developer and the platform perspectives are covered. And we make sure and we know that the software development experience for every organization is unique. Hence, we take the application context and provide a experience which not only enriches the developer experience but also make sure that your software supply chain and the platform is secured. Now moving to the four phases or basically the four critical phases of the software development code, build, deploy and monitor. In code, we provide a set of tools which provides which helps in identifying the vulnerabilities, runtime vulnerability tactics or even scanning your code statically. Then when we move to the build phase, it actually provides you the production ready application pipelines which have provenance attestation and SLSA level three. So talking about SLSA, SLSA is a framework which helps to make sure that your artifact is improved throughout the SDLC life cycle and higher the level of SLSA it ensures or it gives the trust to the customer that what we are saying that is what we are delivering. SLSA level three ensures or affirms that the software artifacts which we are delivering are authentic and trustworthy. Going to the deploy phase. In deploy phase basically we provide you open immutable leisure where you can store your software artifacts and it's made sure that they are not tampered with. Moving to the monitor phase where we have our product called ACS, the Advanced Cluster Security which provides continuous runtime security monitoring and continuous assessment observability and catching the runtime threats and it even takes care of the non-compliance. Okay so the idea is to secure your open source code and dependencies early. We need to catch the vulnerabilities in the very starting of the software development life cycle. So there's the emphasis to move the culture such that security is moved left and is not seen as a after process or afterthought once the software is built and we should give emphasis to the solution and not just a technology implementation because the maximum value can be born out of a solution when the change is acknowledged or accepted by the people and become part of process and it is not just a technology implementation. So shift lift is a cultural and technical shift where we make sure that security is introduced in the way from the very starting that is in the coding phase and take and taken care in every part of SDLC till the code goes to production and with shift lift it is ensured that the collaboration increases between the security operations and the development team. So DevSecOps is basically a part of shift lift where it is made sure that security is there in every phase of SDLC starting from the planning to the coding, building, development, testing and release and we have real-time feedback and insights. Shift lift is about shifting all the way to lift to where the source code resides. The production code is used by the end users but shift lift is about moving from the end users to the router, production, staging, networking, QA, development and the development code and seeing what is actually the reason or the root cause for the risk which we found and as you would have all known as developers every given code has some transitive dependencies. For example if you are Node.js developer you would have written a package.json defining your dependencies. In case of Java you would have used a pom.xml and even if you are just writing a containerized application you would have a docker file. So the people who write these dependencies or use these dependencies are actually responsible for bringing these dependencies to the application but just imagine what would happen if a malware is injected to one search dependency. Luckily we have the open source software to our rescue. So this is our opinionated approach. All this set of tools together build the Red Hat trusted software supply chain. We are working on an on-prem solution which comprises of all these tools and we at Red Hat have contributed to all these open source projects and are working on integrating them together to make sure that we provide a secure stable and strong platform for you guys for the trusted software supply chain. Starting with the SEM we can use github, gitty, bitbucket, gitlab to get your code or pull your code. Then we have teched on the in-house or basically Kubernetes native CI CD pipeline. With teched on it basically provides a containerized build such that it is isolated and provides you security and also it doesn't need any agent it can be used without any agent and every run is isolated to a container and is not attached to any central server. Then we have the teched on chains. Teched on chains actually provide the attestation and the provenance for the execution of these pipelines. The teched on chains actually provides a manifest files affirming that the execution of the pipeline has happened. Then we have another popular open source tool that is Cosign which is used to sign and verify the S-bombs. So S-bombs is the software bill of materials. So you would have all seen like when we buy a food product you will have a list of food labels or ingredients what are there in the food product. Similarly with the S-bombs it gives you a list of all the dependencies which are there as a part for software. So just like we see that the ingredients and decide we should consume the food product or not, S-bombs plays the same rule. In case of the food products some of us might be allergic to nuts and when we are as developers some of us might be allergic to struts and then we have Red Hat Quay which is our global secure registry where you can store your images. Then we have Clare which can be used to scan your images for any publicly available CVEs that is the common vulnerabilities and exposures. We have another popular open source tool OPA which can be used to write rules and policies for Kubernetes. When it comes to deployment we use the GitOps approach and Argo CD is our tool for GitOps. Now going a level deeper to understand each and every face. So let's start with the code face and see how the Red Hat Trusted Software Supply Chain helps you to prevent and identify the malicious code. So with Red Hat Trusted Software Supply Chain we have Red Hat Trusted Content which helps you to secure your code face. This is a product which we have which is currently in the tech preview phase. With Red Hat Trusted Content we provide you automated software composition analysis which helps you to recognize the open source dependencies and intercept the vulnerabilities before providing you the recommendations to how to mitigate the vulnerabilities and the risk. Also we have dependency analytics which comes or which can be installed as a plug-in or extension to all your popular IDs like VS code or IntelliJ which helps you to identify vulnerabilities and also provides your recommendations on how can you remediate them. As part of Red Hat Trusted Content we provide you transitive dependency analysis and CVE discovery which is done very much at the point of entry. Now moving to the build phase how we can safeguard our build systems. So when it comes to the build phase we have the production ready Tecton Application Pipelines. The Tecton Application Pipelines provide ready to use customizable pipeline definitions for hermetic builds. The Tecton Pipelines have network isolated builds which provides package container managers with and auto-generated software bill of materials. When it is pushed to the code base it provides you an automated pipeline as code. Tecton also provides you a UI and a task library using which you can easily write your own pipelines and with OpenShift Pipelines you also have a drag and drop feature using which you can easily create a basically we have a pipeline builder using which you can easily create your own pipeline. So we also have Tecton Chains which actually provides you the attestations which are verified by the enterprise contracts. The enterprise contracts are the rules which define the policies to check the conformity that a given pipeline is following or is othering to the SLSA framework. When we promote a pipeline from build to say a production stage we have to verify that the attestation and provenance checks are there eithering to the SLSA framework and this is done through the enterprise contracts which has a set of around 43 rules which act as gates to make sure that there is no suspicious activity which is passed. The Tecton Pipelines also provide continuous image vulnerability scanning. So the idea is to build with security focused CICD workflows such that we can meet the industry compliance while increasing the productivity and the efficiency. Fine. So now talking about the deploy phase. In the deploy phase we have a very powerful tool which is again in the tech preview phase that is the trusted artifact signer which empowers the software developers and the users alike to sign and verify their software artifacts. For example S-bombs the images, the source code, the playbooks and it helps to enhance the software supply chain security. So the 6-store ecosystem inside looks like this. It has flucio, cosine and record. So when a developer actually request for a certificate it actually it actually has a client which request for a certificate to flucio. Flucio prompts the developer to go to an open OID identity provider which provides an identity token and with the identity token it provides a certificate using which the artifact is signed and once the artifact is signed it is pushed to enterprise registry like we are basically pushed to enterprise container registry and once it is pushed the certificate is provided with the key pair but for the security reasons the private key is destroyed and we don't even need the private key because public key can be easily used to decrypt and verify the signature. So once the artifact is signed and stored in the registry then at that point that event is registered in the record transparency log. Record is the log where it actually records all search events by having a timestamp against every signature event and all the clients actually push search events to a publicly auditable logs. So as artifact owners they are responsible to check record to see that there are no unidentifiable signing events which are there in the log. So when we need to actually verify the signature the timestamp object is matched against the transparency log record transparency log and if there is a match it means the certificate is validated and the signature is valid. Six store is actually a free open to use software which can be easily installed on any Kubernetes cluster or platform basically by using scaffold helm shards which is available in the six store GitHub. Now we have spoken about how we can actually secure our code build and deploy phase. So once we have secured our code build and deploy phase now we need to continuously monitor security at runtime and make sure that there are no threats and compliance issues. So when it comes to the monitoring phase we have an advanced cluster security which is the tool which is provided for the security phase. Advanced cluster security is a service which visualizes security and compliance across distributed teams of hundreds of audit controls from a common dashboard. ACS allows you to monitor multiple clusters together. It helps you to easily monitor and respond to misconfigurations, non-compliance and runtime threats. The idea in the monitor phase is to observe the software artifact and detect and respond to the suspicious activity. It provides runtime vulnerability scanning and management. In case if an incident occurs we can expedite the incident response to reduce the down times. Advanced cluster security also views compliance against the industry standards like HIPAA, PCI DSS and CIS. So ACS actually provides monitors and identifies runtime incidents and it helps to reduce noise and alert fatigue to make sure that we have a shorter time to respond. Now I'll be giving control to my Kali Gram Ki. This is how the thing looks like. Like we mentioned earlier we have various popular open-source projects in every phase of this. The code phase, build phase, deploy and monitor phase. So we'll just take a look at how it is. So the way we are doing this, this is our opinionated way of how secure supply chains can be done with very minimal effort is we create a template like as usual. We create a template and we put this template across this is an example of a e-commerce store. So suppose you need to work within a certain component within your whole software components. So it is going to show what are the like say for example you can see all the APIs, how it's interacting with each other and say you onboard a developer onto the project who's supposed to work on certain API components. So within this they can change which resource they want to work into and we have an sample app HR2. I can share this template so you can load it onto your OpenShift component. So suppose you want to work on this project. Like we mentioned earlier the technical documentation, the code base, everything comes out and from there on you can start looking at so the basic thing is the developers require three things, the code repository, the access to the build pipeline. So here what you can do is since from the developer hub template itself you're getting the code repository loaded on to the system, you're just downloading it and then there you can go ahead and make your changes. Here we're only changing, we're only changing the code base, we're not changing anything from the security or the pipeline perspective. So what you're doing is as soon as you push what is going to happen in the back end is, so you see a git clone happening. So what's happening is the developer is only focusing on the code base, he's not focusing on the build pipeline. So all of these things can be put as an artifact. So the main audience of this talk is the DevOps people in the cloud or also the security operations people in the cloud where you can put your company's enterprise contract in the pipeline and what happens is in the same way you can create a whole supply chain attacks. So how many of your organizations had a supply chain attack recently? Over the last three years like what Ramiya was mentioning there's a 732% increase in a supply chain attack and these attacks are happening most probably in the build phase itself. Like say your open source project is pulling let me stop over here for a second. Your open source project is pulling dependencies from upstream projects. One of the most common error is typosquatting errors. How many know the water typosquatting error is? So think of this. If I want to give an analogy in the real world how many of you have drank packaged water by this brand called Bislery? How many varieties of Bislery are there? Bilsery, Bislery, BCCR. So you see right it looks like packaged water it looks like Bislery but it's not Bislery. So there is there are small changes. So these things happen to many open source projects where malware can be put in your dependencies of your project and it will be a similar sounding name right and you're going to pull that package like for example it will be Django but the spelling could be D-A-J-O-N-G-O or some other popular thing. So what happens with that is all the your code base so like I was mentioning earlier software is always a liability so your package, your software, what your writing might be like say 1 lakh lines of code but the dependencies you're pulling into the project of which you are not the author of so many open source project is it could be at least four or five lakhs of projects depending on how complex your enterprise software project is. So what happens with that thing is it's a responsibility of the developer or the operations team to keep these dependencies also updated onto the projects. So most of the security vulnerabilities happen where popular open source projects or popular projects are consumed within their production code bases and these dependencies are not updated right and as developers you would also like to move very fast. Another bad practice which has become like a norm in many organizations is just because there's a open source package they want to put it into their software project. Sometimes you need to validate why is the package in my component do something in that package. So usually the rule of thumb which I suggest is if it is not improving your code base maximum 10% you don't need to introduce that package within your software use it and code that bit right because you'll have more control on your code base reduce the number of dependencies your software projects have as much as possible. But in the case where you need to keep these projects up only select the projects where there's an active community around that just because there's a rockstar developer in one project it doesn't necessarily have to be put into your code bases right. So evaluate what and all you're putting in your code bases because errors like these are very common and they're going to become more and more common because like say if you're generating code and not writing the code by yourself it is going to pull older packages right like if I go to a chat repeat generator token for something in Golang or Rust or Ruby it is going to generate but it is going to generate from the knowledge what it had from two years back or something like that and by introducing that thing the present packages might have a lot of vulnerabilities which have been fixed in the previous thing. So the other common mistake is how many of you have heard the term forking a project? So you go to GitHub fork a project and then you use that project within your code base. So what happens when the fourth project the mainstream of a project the master of the original project keeps moving in a different timeline. And most of the popular open source projects try to have some kind of a security cadence where it is fixed especially projects which consume JavaScript lots of security vulnerabilities. All that gives you a lot of flexibility and features can be rolled out very fast. The number of security vulnerabilities in JavaScript projects are phenomenal. So these are few of the things which you need to keep from a healthy perspective but not all organizations can afford dedicated security and security ops teams. It is critical but the thing is it's everybody's responsibility it's the responsibility of the developers to see what kind of code bases they are putting is the responsibility of the operations in the data teams to say where depend which dependencies you need to take which for artefactories you need to include within your pipeline. And the third thing is also the security teams perspective that the projects which have already been deployed continuously monitor for vulnerabilities on those code bases. Like for example the SolarWinds sorry the log4j attack like most of you might know the vulnerability was always there in the systems it only got exposed much later because the exploit came much later right. So all the code bases what you ship right now will have some kind of a vulnerability. You'll never have a place where you know there is all the code bases are always going to be security proof and all that is just a myth or if somebody is trying to sell you that he is basically the person is basically selling you a snake. The thing is you can only mitigate the security list so you're always working under constraints the constraints could be you need to deliver against a certain perspective or certain deadline or a certain compliance structure needs to come in. So what happens with that is your underlying code bases even popular services like GitHub and all have started analyzing your code bases and started throwing out vulnerabilities because this is something security can't be an afterthought it is there in every phase. So the code build and deploy phase also is there. So even if after you deploy what's going to happen is the next vulnerability is going to come then again you need to go through the whole processes right. So these are a few of the things which takes which this application takes care of. So in this case what's happening is this project already has a defined security criteria for a particular organization.