 Hi everyone welcome to one of the last sessions of the day. I Know you guys must be exhausted by now. You know, it's normal even two two days of Pretty I think for you like attending a lot of sessions, right? so I Will try to keep this interesting and conversational So the topic of my presentation like first a little bit of myself. My name is a sort of bad. I'm a Senior solutions engineer at upticks. You might have seen me in one of the booths So the topic of my presentation is security that enables Breaking down security silos in the DevOps ecosystem. So what do we mean by security that enables? so any CICD pipeline right or as I like to call it innovation pipeline it consists consists of Different components working together And in the end the developers aim is to release code at a really fast pace and You know like they can overlook security, right? But what the ultimate aim is to Make sure that security does not hamper innovation. That's why the name security that enables So it basically enables the developers to be successful It enables the security team to be successful as well as the operations team. There is there has always been friction between No security and developers. So we make we want to make sure that there is that goes away So here's the agenda of my presentation like first would be introduction second why are we seeing attacks on The CICD ecosystem, right? What do the attackers see when they look at your pipeline? Next would be security gaps in a traditional pipeline with so many You know, very with various tools working together. You have your build tools repositories your containers It's it's only like logical dark, you know, like security gaps Can't keep in whether they are vulnerabilities whether they are Oversights so we will look at how and why like security gaps get Become a part of the traditional CICD pipeline Then I would like to go through the Dropbox breach That's one of the latest ones that comes to mind. You have like the circle see I as a one-two When we say when we talk about attacks on a developer ecosystem, right? On the left hand side, you see one of the examples the last pass attack then you have the slack Breach and the Dropbox breach so I'll break down What exactly happened and what are the lessons learned and in the last I would be covering enabling dev and security teams to work together to create a successful Working software in the cloud which is secure Now I'll go through like why has there been a rise on the developer ecosystem CICD ecosystem The first one being lot lack of integrated and automated security testing tools You have when you see your CICD pipeline you see Your developers laptop you see code repositories. Then you have image repositories on your containers in production so many different Components are working together, right? So there is overall a lack of integrated and automated security for these tools and All these different components make for a large attack surface. So the attacker just needs to enter just in One particular stage, right? And then he can go like for example If an if an attacker enters and gets hold off access keys Which which were exposed by the developer like the developer wants to be make a code of really fast He has admin access to systems just to make his life easier, you know, hard codes the keys the passwords If an attacker gets hold of those credentials, then no like, you know, you have seen examples of Dropbox, you know, what exactly can happen? He can get access to those crown jewels in a CICD pipeline Your code is getting built, right? It's it's something which is kind of the Like a crown jewel for your organization, right? And then you have The reliance on automation Leads to complacency. It's just human nature. If anything is getting automated, you know, why care you have Automated driving cars right now. So reliance on automation leads to oversight Vulnerabilities that would have crept in No one even paid attention to them So we have to make sure that each and every stage of the CHD pipeline is actually being monitored audited And if something creeps in right at the first which is shift left, you know, like the developers laptop We need to make sure that it's getting fixed as soon as we discover that So Here you can I've just mentioned up the developer Breaches that happened recently. You have the last pass attack the slack One where the employee get help tokens was stolen and the circle CI one where the authenticated session keys was stolen So this is different from the Dropbox one. So in Dropbox, it was actually a circle CI imitation, but in In this case, it's actually that an attack that happened That targeted circle CI organization. So what are the security gaps in the CI CD pipeline? So Why do the security gaps keep creep in your CI CD ecosystem? So CI CD is a term which has become a household name but organizations Like are still not an expert in CI CD. So probably like four to five percent might claim Okay, we have got a hold of CI CD, but still there is unrealized potential for CI CD adoption System as such the whole pipeline hinges on various dependencies and configurations. So developers use a lot of third-party libraries and So having such a diverse Set of tools working together, right? There are dependencies configurations and because of that vulnerabilities might creep in The last being haste and need for fast-paced delivery cycles So in an agile environment that developers want to just write code commit it and release the application But then again as I mentioned, they overlook security It should not be like Like obviously the end goal is having a working software, but security is also important So because of the hastiness and the fast-paced nature of the agile development developers tend to overlook security which comes on which gets discovered what exactly was left unpatched when the workload is actually in production. So This is a traditional securing like CI CD pipeline So just to recap what I've covered till now like I covered why are we seeing Attacks on the developer ecosystem why security gaps creep in And this is like if you pay attention to this image, it's a lot of things are going on You have your development stage, you know code is being developed It's been committed to a code repo like you know GitHub and then you have your building and testing tools The images that are getting built are being applied to registries, right and then Those containers are running in production having some kind of orchestration such as Kubernetes OpenShift So I would like to call the development and CI CD pipeline piece as pre-production and control plane and data plane as post production So let's focus on Post production right when the workloads are actually running You will see that it consists of different services such as orchestration Runtime such as Docker engine and then you have the actual worker nodes running those containers From a security perspective, right this data is pretty siloed Like take for example container escape So containers when they are deployed they just widen the attack surface They share the same underlying IP space So even if an attacker escapes one container, he will have access to the other underlying containers To the host itself and he can go deeper into your infrastructure Now if you look at the pre-production stage We silo The development stage from the building and testing stage We never focus on developer laptops right developers do the groundwork for the software development They you know, they have admin access to different tools But we never focus on developers laptop security and they don't even like that so Again coming to a from a security perspective The data that's getting generated from the developers laptop or even repositories It's pretty siloed from what exactly is happening and the building and testing phase and the registry phase So let me cover what exactly happened At you know when the Dropbox Beach occurred So This attack Highlights the fact that there have been a rise Of attacks on the developer ecosystem We all know the reason why they do the Stuff they get the stuff done build code develop develop the application In case of Dropbox what happened was If I'm a developer I logged in I saw this email from circle ci which is The tool they were using internally in Dropbox I clicked on the malicious link. I had no idea that I was doing that It took me to a fake circle ci page Asked me my github credentials and a one-time passcode Once I entered the credentials and the otp The attacker took those credentials logged into github and as a result 130 internal repos were cloned And this was no spray fishing attack. It was actually spear fishing because The developers were targeted The attackers actually knew that circle ci was being used inside Dropbox so Which shows that attackers are becoming sophisticated day by day So on this screen like this is again what I said so basically, you know, what exactly happened was It was just a sophisticated attack that could not be prevented right Logging into an invitation page Giving out your credentials and then the breach Just happened So what are the lessons learned? One thing I would like to Point out which is not on the slide is user education and training is really important Especially developers who don't Care about security much who don't Are not involved with security. So user Education and training is of utmost importance They need to know if If they see something fishy, they should reach out to the department right what exactly like we got this email But in this case, they just clicked on the link. So user education and training is really important and then This attack along with last pass lack circle ci it reinforces the trend that attackers are actually targeting the developer tools the ci CD pipeline when they Look from outside ci CD pipeline is a goldmine, right? They know that okay somewhere some vulnerability will prop up so To avoid such scenarios, right there are with like some Some of the lessons learned from the draw box breach Just regularly rotate password and set up mfa right. It's it's a simple thing And Attackers knowing that circle ci was using was being used internally Attackers are becoming more sophisticated and more familiar with environments And it's really important to scan the source code repositories or even image repositories for any credentials In the haste of just releasing an application making Making code changes committing the code you're like Even like I was a developer in past life. I never cared of you know for not hard coding the credentials So it's really important to scan your code repos as well as image repos And how do how can we enable dev and security teams to go hand in hand and have give you a secure running application in the cloud? so first What's a good and what's a bad security culture in an organization and what are the characteristics? so in a good security culture It builds trust it builds trust within the teams I am a developer I trust the security team not to hamper my innovation. I can code. I can commit the code as I like Right, but still there's trust that okay, you know, it won't hamper my innovation It simplifies access and workflows. So if I Um, if I have zero trust for example, right my machine is You know, my machine is protected I I want to access any critical applications. So based on my zero trust code, they were like, okay, this this machine is good You know, let the developer access the applications. He's requesting access to It encourages people to speak up and then It enables users to be security minded as As we learned from the draw box breach users Developers or any other person and organizations should have that level of security awareness that He can judge what's wrong and what's not On the other hand, what's a bad security culture like it roads trust people different teams don't trust each other I'm a developer. I don't trust the security team. I will always think okay. It will hamper my speed You know, let me just write code and commit it It complicates access and workflows and last It encourages users to hide their mistakes Right if I may I know I did something wrong like I left my credentials, right? But I don't care. It's already committed. The application is already running I won't even let the security team know like if there are no tools in place You know, I won't even work with the security team to make sure that I'm releasing a secure software So what are the different security solutions that enable first zero trust frameworks? That's The latest buzzword. It's it's a deviation from the traditional mindset of trust, but verify Always validate a user's integrity when accessing internal resources it means Like zero trust is like on every stage you have to authenticate and then you get authorized And similarly having a zero trust score it will differentiate good from the bad and if I'm a good user I can easily get access to internal resources Second one as I mentioned on the previous screen we should scan for vulnerabilities um In that might have crept in uh in the pshc pipeline maybe because of you know, hastiness or user overlook Then look for private keys credentials other secrets which can be stored in images which are already in Registry such as jfrog artifact re ECR and also registry code. So if you're committing committing the code to uh repo like github we should have the ability to also scan those repositories because it reduces the attack surface So again zero trust builds acts builds trust If it's a good it tells us the difference between good and the bad it simplifies access and workflows It reduces ability for lateral movement because at every step you have to authenticate Right and it empowers modern developer work culture. It means like you have your b y od policy or work from home Remote today. I'm working from Seattle tomorrow. I can be in canada, right? So having the zero trust score for a machine Can tell you like even if this person is out of his geographic area This is still a good machine because we trust this machine And similarly the second approach that we discussed about build time scanning registry scanning First it reduces the attack surface because if something is already patched the The attackers have less chances to exploit that Then it simplifies workflows it enables team to release builds, right? I'm a developer. I'm happy these These stages are secure and then it hardens the static code and the container image repose So For the conclusion, right? I would like to point out that whatever we have discussed or whatever I have presented that Developers ecosystems are being targeted The attacks are becoming sophisticated day by day. The attackers are becoming more aware of internal environments Good security enables developers to work dynamically and ship faster more secure it means Security is no longer hampering innovation. It's actually driving innovation. So good security enables developers to develop a tool a product which is actually secure and I can't you know stress this enough that dev dev and security teams Should go hand-in-hand right and they should go hand-in-hand to fix those gaps in a CI CD pipeline, which might have kept in and there are like numerous reasons you have your diverse attacks your diverse tools user oversight, you know probably like access levels like you have Admin access to tools we can you know protect this by tying down the access So dev and security teams should work hand in hand And a good security program should never hamper innovation, right? Your CI CD pipeline as I like to call it is your innovation pipeline. That's where the stuff gets done So a good security program should never ever hamper that innovation So any questions? I'm open for questions No questions. I think I did well then Yeah, thank you