Rooting out Security Risks Lurking in your CI/CD Pipelines

welcome everyone let me start by introducing myself i am wasan chunibili like many of you i am sure i'm a security fanatic and my experience spans across various domains of information security including cloud container security and penetration testing and security architecture i'm also passionate about cloud uh cloud native security devs corps and security automation i am also like the developer of cube striker which is an open source platform agnostic security tool specifically designed to secure the cloud native and tagging kubernetes cluster security issues the tool has been showcased in various conferences including black hat and defcon now enough about me let's jump into what you're actually here for which is to deep dive into the world of

strengthening the cicd pipelines but i want to take you back to basics for a minute starting with the fundamental question what are cicd pipelines and why should i spend the next 45 minutes learning about it well we all know that the deployment pipeline is at the heart of any software delivery because it helps create a fast flow of change by ensuring that all software changes use the same route to live continuous integration and continuous deployment or delivery commonly referred to using the acronym ci cd is a framework where software is built tested deployed and validated throughout this lifecycle both ci and cd are about automating further stages of the pipeline but they are sometimes used

separately to illustrate the extent of automation the acronym ci cd has a few different meanings so i am only going to touch on a few main elements of it today continuous integration ci allows you to continuously integrate code into a single shared and easy to access repository it is an automation process for developers and successful ci means new code changes to an application are regularly built tested and merged to a shared repository it is a solution to the problem of having too many branches of an application in development at once that might conflict with each other while continuous delivery or deployment cd allows you to take the code stored in the repository and continuously deliver

it to production it usually means a developer's changes to an application are automatically bug tested and uploaded to a repository like github or a continuous registry where they can be deployed to a live production environment by the operations team cd is the answer to the problem of poor visibility and communication between the development and the business teams the goal of continuous delivery is to have a code base that is always ready for deployment to a production environment as you can see both ci and cd are about automating for the stages of the pipeline but they are sometimes used separately to illustrate the extent of the automation following the automation of bills and unit and integration testing in ci

continuous delivery automates the release of that validated code to a repository to summarize these are the benefits of using ci cd smoother and faster release to production shorter review time better code quality faster bug fixes measurable progress efficient infrastructure tighter feedback loops last but not least better collaboration and communication many such benefits has led to the rapid adoption of cicd implementation by organizations across nearly all vehicles including those with strong security requirements such as financial services health care government and telecommunications we now know that cice ecosystem is great for fast and efficient application delivery but do they necessarily keep your application secure while this rapid adoption of cicd shows just how disruptive these technologies have been they have also led to new

security problems the more resources your pipeline have access to such as like the testing and production environments secrets proprietary code and databases the more important it is to keep your csd system secure but they can be modified or stolen by attackers if not properly protected it is as simple as that at the very least compromised ci cd servers can provide hackers with access to free computing resources that can be abused for crypto mining building distributed dos attacks or proxy malicious traffic but the security implications far exceed that particularly for on-premise self-hosted deployments these are only hypothetical scenarios but let me tell you what happens in real world when ci cd pipelines aren't secured properly researchers discovered the ongoing

active camping where malicious build files were embedded with executables and shell code to deploy backdoors this allowed the hackers to take control of the victim's machine and steal sensitive information can anyone recall what the application that led to this it was microsoft build engine which is an open source build tool for net and visual studio developer microsoft that allows users to compile source code package test deploy applications during this attack the malware used a legitimate application to load the attack code into the memory the idea behind using ms built to flawlessly compromise the machine was to remain under the radar and go undetected in this process leave behind no traces of infection on the system and maintain a level of

stealth according to the researchers many of the samples analyzed including different kinds of malware attackers were able to gain full access to the remote adversary once the malware is installed and is also capable of capturing keystrokes to execute arbitrary commands and recording microphones and webcam want another example in early december 2020 several organizations discovered and reported breaches to their networks within a few days of each other it didn't take long for security and threat analysts to connect the dots as the initial position into each of these companies was identical a trojanized update to a popular infrastructure monitoring and management platform solarwinds orion you might be wondering why they choose orient because it's connected everywhere from switches and routers to firewalls

virtualization infrastructure active directory storage management tools and more while it's still unclear how the hackers first infected solar against orion forensic evidence reported in the press indicates that they worked hard to learn the company's code structure and terminology before launching the attack to make their way into the organization the attack is compromised the heart of the cicd pipeline where code is tested wrapped containerized and signed and then successfully changed solar wind source code the attacker deployed malware infamously known as sunspot which ran with high privileges standing for orientals without tipping off the developers or engineers the malware changed source file code names to deploy a backdoor following the build update the backdoor was deleted and the original file names

were restored as you can see now more than ever it is vital to understand how to build and strengthen the security posture and framework of cicd pipelines so organizations can mitigate the risk of attacks however the process of applying security to cicd pipelines isn't straightforward but don't stress i'm going to simplify this process as much as possible and share offensive and defensive techniques to build a secured ci cd ecosystem let's start with looking at important components of ci cd ecosystem and step into shoes of a hacker to see the different ways how they can exploit them one of the biggest reasons why developers are attacked is their association with various source code once the developer system is compromised

then malicious attackers can download the source code and look for vulnerabilities that they can take advantage of later on or even more in cds change the source code to contain backdoor and just as threatening trusted insight developers may take source code or databases home or to a competitor when computer security people start talking about insider threats often they're most worried about malicious callers with dubious intentions the problem is that even though developers agree that they don't need to be more resistant to attack they are unhappy about losing elevated access all the time while many developers understand the importance of security they also openly resist if those protections slow them down more than few seconds however giving flexibility such as

privileged access can expose a broad attack surface to potential attackers this can make security professionals uncomfortable developers tend to be technically smart they will find clever ways to work around hindrances if that's what it takes to get the job done we need a situation which is both flexible and secure hence it all begins with securing the engineer's work environments in a dev and security friendly way here are the some ways of achieving this always provide developers with the tools and environment they need practical tooling is essential if you want to avoid technical savvy developers finding insecure workarounds trust your developers but verify their actions educate users and trust them to do the right thing implement functions to

verify their activity and to detect suspicious activity or potential compromise reduce the attack surface of your developer environment basic measures include network monitoring to detect suspicious activity verifying software that users are installing an endpoint protection a dlp and limited privileges on the workstation and appropriate vulnerability management and patch management of the workstations and needless to mention protect access credentials and securities carefully consider how you store and handle credentials that grant access to critical services and systems using multi-factor authentication will mean that stolen passwords are not sufficient on their own to gain unauthorized taxes next one is assess the impact of compromise and apply onward controls in the event a development environment is compromised consider the onward

technical controls that will protect the products and services you produce and publish and don't operate your production systems from a development environment managing production services from development environments can be very high risk in situations where this is required try to limit the exposure of your production services consider models for at least privileged access management and temporary access credentials through a request process carry out some proactive monitoring of your development environment investing in monitoring and auditing controls will help you to verify this is happening you should have an idea of what legitimate use of your environment looks like combining this knowledge with logging from your environment can help to detect illegitimate use or potentially a compromise for example our malicious

websites being accessed and any privileged actions being carried out during unusual hours of the day and finally needless to mention educating the developers i want to now highlight the importance of source code repository protect the access to edit repositories a critical git security issue you should guard against is unauthorized access to your git repositories git on its own only keeps track of the changes occurring inside the repository when you want to share your work you need to expose this repository and you should do it in a secure manner otherwise this can lead to trouble when using ssh your private key should be protected by a fast phrase if you have several development workstations create one pair of sshps

for each of them this way it would be easy to rework access to a git repository so for a specific device that you believe may have been compromised the same is true when you give access to your git repositories to third-party applications use access tokens that can be easily reworkable instead of your current account credentials and make sure to keep them secret the sign your work git enables you to cryptographically sign your works using gpg keys signing your work is important because anyone can choose the name and the email address of the order displayed in the git comments so signing your work is an excellent way to add an extra layer of trust and segregation of privileges

defining access roles on a per repository basis to ensure developers with valid access credentials can interact with individual repositories also define the level of privileges read or write for example the actual ci server does not need to make any modifications to the code for the deployment you can limit the ci server to read only access to the underlying repository limiting the damage from a potential breach of the ci server keep git and related tools up to date as is true of software in general it is not perfect and can be impacted by vulnerabilities the recent vulnerability is a good example of this one allowing attackers to craft a malicious git repository leading to remote code

execution when prone by someone any git related tool can be impacted by similar issues and they all need to be kept up to date and restrict access to your protected branches the pull request workflow is used together with restricted access controls a developer can't push directly to the production branch but instead must create a pull request that targets the protected branch each sem vendor has a different flavor for achieving restricted access to protected branches for example with github this feature is only available for organizations using github teams or github enterprise cloud and pull requests and collaboration the pull request workflow is designed to introduce healthy friction it answers certain questions such as if a developer pushes code to a branch x

will it deploy if so to which environment at what point in the application code lifecycle is a vulnerability scan done if a security vulnerability is found how many code pushes and approvals are required before it lands in production and if you look at this table this table is useful for debugging and static documentation but also for team collaboration it's transparent to developers where healthy friction has been introduced into the workflow to prioritize code quality and security more importantly it shows the developer the expected path for code changes to raise the production the next one manage your secrets data and code leaks are the two biggest dangers in your pipeline and so they should be your focus when prioritizing

although you can use tools to inspect on comments and or staged files to prevent adding information to the git repository continually educating your engineers is the only effective solution for this problem ensure that all your repositories and code stores are private next up we will be looking at ci build environment security to do this i want to share my professional experience of looking at scenarios where there was no segregation of access management between the ci and cd environments during one of my assessments where the infrastructure was hosted on aws it was given developer access with limited privileges to build tools to configure and test the bills stages and jobs during my contest i harnessed this to my

advantage by creating an executable task in one of the stages to grab the aws instance metadata with the information or the credentials gathered in the instance metadata i could perform lateral moments and escalate my attacks to the underlying cloud account based on the privileges and the next trick works like a charm in the majority of the assessments to gain control over the build server attackers usually aim to gain interactive shell access for arbitrary command execution with a reversal technique the target machine that initiates the connection to the user and the attacker's computer listens for incoming connections on a specified port the primary reason why reverse shells are often used by attackers is the way the most firewall security groups

network acls are configured they usually do not limit outgoing connections at all with the similar technique mentioned previously i can issue a few commands uh as shown here to create a user account to gain remote access to the build server in addition to that the attacker can go an additional mile and leverage the some post exploitation tools such as like mimikats that dumps hashes from memory however this technique requires disabling the defender on the target server and bypass any endpoint protection and in one of my assessments to my surprise i came across the aws credentials folder with some highly privileged credentials hard coded for different aws accounts in their organization in fact it can also be a container which

is performing these bills and if any sensitive volumes are mounted onto the container credential theft is bound to occur even in a well architected environments these mistakes will be costly the iim privileges provided to the ci server are keys to the kingdom as discussed before the ci servers will have access to most of the accounts and tools in the cicd ecosystem i was able to train different techniques and perform lateral movement to multiple accounts all the way to root account due to cloud economies configuration and lack of trust boundaries given the limitations and trade-offs of the cicd platforms it is not recommended to rely on a single platform for implementing the entire workflow instead it is recommended a hybrid

solution that takes advantage of the strengths of each platform and covers the weaknesses now let's see how to securely architect it in such robust cloud recon structure where there is appropriate isolation between root account and chill accounts implementing segregation between ci and cd environment is always considered a good practice in this scenario the build server will have very limited privileges to perform its duties and will not have any privileges to perform like the cd continuous deployment or continuous delivery tasks this design implements separation of the concerns so that we can take full advantage of the strengths of the each platform while covering the weaknesses relying on the cicd platforms to manage the workflow or pipeline but having it

trigger infrastructure deployments or application deployments on self-hosted systems that are more locked down you don't want to give the cicd servers permissions to deploy and manage arbitrary infrastructure ci cd servers are typically not secure enough to handle sensitive information and you don't want a server that is used for executing arbitrary code and regularly used by your entire dev to have it in permissions instead we delegate this responsibility to an isolated closed off system that only exposes a limited set of actions that can be triggered that way if anyone gets access to a ca servers they can at most only kick off builds on existing code but they don't get arbitrary admin access and always avoid having a single system

with admin permissions for running a deployment instead deploy specialized versions of the deployment platforms with varying permissions for handling specific workflows by separating out the concerns for each pipeline you can reduce the blast radius of the damage that can be done with each set of credentials and to further limit the ability to run arbitrary code include functions or scripts in a stack that can be used as a trigger which expose a limited set of options and provide additional checks for source repository for example jenkins gruvi cli is a security risk for jenkins service and since one can manage the jenkins server without using the groovy cli they must disable it by default and needless to mention run your

infrastructure deployment workloads in a virtual private cloud or virtual networks to isolate the workloads in a restricted network topology configure it to run all workloads in private subnets that are not publicly accessible make sure to block all inbound internet access and consider blocking all outbound access except for the minimum required and use minimal iam permissions for deployments wherever possible restrict the build tools console login only to internal networks with appropriate segregation of duties for teams only needs access to it now that we have seen how to secure the ci build environment let's look at strengthening the cd build environment it is considered a good practice to deploy a self-hosted deploy server within your cloud account that has the

permission it needs to run in cross section deployments and it is locked down so that it is only accessible by a trigger that can be used to run predefined commands or predefined scripts likewise it is considered to have an independent deploy server within your private networks and that has the permission it needs to run application deployments and is locked down so it is only accessible via a trigger that can be used to run predefined commands and use any generic cicd server to implement a ci cicd workflow where you trigger a dry run in the deploy server gets approval to proceed from an admin on your team and then trigger a deployment in your deploy server

define your cs workflow so that the ci cd server triggers deployments against the deploy server let's discuss good options for securing the deploy server the deploy server needs to be a self-hosted platform in order to satisfy the requirement for isolation you should also avoid executing arbitrary workflows finally should support configuration options that limit what code can run on what server this limits the options for what you can use as your deploy server next limit triggers for deploy servers the deploy server should only expose a limited set of options for triggering deployments that is it should not allow the arbitrary deployments on an arbitrary code you will want to configure it so that only certain repositories branches or

users can trigger the workflow requires a single repository to require deployments by default it can be configured to limit deployments to specific branches the next one it should also require explicit im permissions to trigger deployments cool the next important one is use a vpc to lock down deploy server run your infrastructure deployment workloads in your virtual private cloud networks to isolate the workloads in restricted network configurate to run all workloads in private subnets that are not publicly accessible make sure to block all inbound internet access and consider blocking all outbound access except for the minimum required and always use minimal iam permissions for deployment avoid having a single system with admin permissions for running a deployment

instead it deploys specialized versions of the deployment platforms with varying permissions for handling specific workflows by separating out the concerns for each pipeline you can reduce the blast radius of the damage that can be done with each set of credentials at a minimum you should have two versions of the infrastructure deployment system one for deploying the application code which only has the minimal permissions necessary for deploying that applications and one for deploying infrastructure code which has more access to the environments always use approval workflows it is important that human review is baked into each deployment as covered in the ci cd workflows it is difficult to build an automated test suite that builds enough confidence in

your infrastructure code to do the right thing this is important as failed infrastructure deployments could be catastrophic to your business and there is no concept of rollback with infrastructure deployment tools this means that you will almost always want to have some form of approval workflow for your infrastructure csv pipeline so that you can review what it is about to be deployed always logged on the vcs system it is a good practice to define the deployment pipeline as a code however this means that anyone with access to those code repositories could modify the pipeline even on feature branches this can be exploited to skip any approval process you have defined in the pipeline by creating a new branch that

overrides the pipeline configuration this is not a concern if only admin users had access to the infrastructure code typically however many operations teams want contributions to the infrastructure code from developers as well and giving any developer the ability to deploy arbitrary infrastructure to production without any review can be undesirable to mitigate these concerns you should always lock down your vcs systems only deploy from protected branches protected branches allow you to implement policies for controlling what code can be merged in for most of the platforms you can protect a branch such that it can never be force pushed or it can never be merged or commit from the cli or the merge requires statistics to pass and the merge requires approval

from a number of reviewers by only building ci pipeline from protected branches you can add checks and balances to ensure a review of potentially harmful infrastructure actions and always consider a forking based workflow for pull requests when exposing your repository to a wider audience for contribution you can consider implementing a work forking based workflow in this model you'll only allow your trusted admins to have access to the main infrastructure ripple but anyone on the team can read and fork the code when non-admins want to implement changes instead of branching from the ripple they will fork the ripple implement changes on the fork and then open a pr from the fork the advantage of this approach is that many ci platforms

do not automatically run bills from a fourth for security reasons instead it means manually trigger a build by pushing the forked branch to an internal branch while this is an issue or while this is an inconvenience to devs as you won't automatically see the plan it prevents unwanted access to the secrets by modifying the ci pipeline to log internal environment variables or show infrastructure seekers using external data sources

i want to know highlight the importance of code signing modern agile development and delivery practices enable frequent updates of deployed services and this automation relies on the ability to trust the product of your bills while this has the potential of increasing flexibility and usual values of the services it may also introduce security risks so what is the solution to eliminate artifacts being compromised ensuring the authenticity of your artifacts signed pipelines create trust in the binaries that progress through your stlc by building a cryptographically signed journal that can validate the authenticity of every artifact generated by your pipeline with this protected record developers and operators can ensure that the bills created by a pipeline don't contain

compromised artifacts that have been rewritten by other processes or actions code signing ensures that a trusted organization has released the deliverables and that has the code not been altered or corrupted before being deployed in the target environment with code signing your entire pipeline is protected from planning to operation the next components to consider are the build software themselves and the plugins as of today open source and commercial build tools have a huge database of more than thousands of plugins and a growing number of users with more than hundreds of thousands of installations however its popularity has resulted in many security issues new vulnerabilities and attacks executed against build servers this is the reason why it is necessary

for anyone administering a build server installation to know the threads a build server or a tool installation can be exposed to and how to mitigate these risks and where they can seek help if there is an issue with the software vulnerability management and patching well build tools and software are no exemption from vulnerability management so build tools should also go through the process of identifying evaluating trading and reporting on security vulnerabilities this implemented alongside with other security tactics is vital for organizations to prioritize possible threats and minimizing the attack surface of the cicd ecosystem never run build tools with road or administrator privileges one should never run build tools with the administrator or root privileges

regardless of the operating system platform in addition to not running the administrator or root privileges implement least privileges by removing pseudo access to the account that build tool users implementing the least principle of lease privileges can reduce the damage caused by a compromised account protect sensitive files there are important files on build masters that should only be accessible by the account running those build tools make sure the configuration files are properly logged on by granting access only to the owner if running on a web server such as like tomcat or jboss moving on to the plugins now one of the many reasons why build tools are so popular is the breadth of the available plugins

with more than thousands of available plugins automation opportunities are endless plugins enhance the power and usability of the continuous integration automation server however if not handled correctly plugins can introduce security weaknesses it is also important to keep in mind that plugins are often developed by third parties who may lack security expertise and that these plugins can go unsupported here are several precautionary best practices for making sure unsecured or unsupported plugins don't expose an organization to unnecessary risk exercise caution in loading plugins from internet sources as they can be considered as unrestricted code uploaded to your build master so make sure you load plugins from reputable sources only constantly update build tool plugins as security issues and bugs are

continuously supported and fixed by plug-in maintainers and verify each plug-in source code for security vulnerabilities before installation whenever possible now let's look at another interesting component of ci cd well containerization is the trend that's taking over the world to allow people to run all kinds of different applications in a variety of different environments there is no exemption for ci cd and in fact all cicd jobs such as building the code performing the test and automatically deploying the code to a server can be run using docker images this allows you to define a custom built environment with pre-installed tools and dependencies needed for your project i can't stress enough how important it is to secure your container runtime and

containers a privileged container when gained access gives an attacker the privileges to run a command in the context of the container and the option to escape and access the underlying host resources this is an endgame an attacker who gains access to the container has gained access to your cluster and eventually the underlying cloud account so how do we secure this start with regularly updating your container runtime and the host if you're using docker as your container runtime make sure the docker and the host are up to date always make sure that docker is the most up-to-date version use the updated operating system and containerization software to put a stop to security issues each update has security upgrades that

are necessary for safeguarding the host and the docker run containers as a non-root user running containers as a non-root helps to mitigate security vulnerabilities running your containers on rootless mode will verify that your application environment is safe it also prevents malicious content from accessing the host container this means not everyone who has pulled your container from docker can get access to your server the next one is configure resource quarters the resource quotas are configured on a per container basis by docker they enable you to limit the number of resources that a container can consume this feature enhances container security and makes them perform at an expected speed if one container got infected with malicious code it won't let in many

resources in as the code are cut it off this will further helps to minimize the attacks and reduce the blast radius the next one always set container resource limits containers should have a resource limit setting resource limits reduces the ability of containers to consume a lot of the system resources limiting resources assigned to each container enhances the security in an event of an attack the next one keep your images clean downloading container images from untrusted sources and vendors can introduce security vulnerabilities in containers make sure that images downloaded from online platforms are from trusted and secured sources to avoid security vulnerabilities always use container images that are authentic check them out at dockerhub it is the

largest docker registry with multiple container images and make use of images that are verified by the docker content trust and needless to mention always use docker security scanning tools to help you identify vulnerabilities within your container images and the last one always secure your container registries we have now looked at ways to secure the important components of the cic ecosystem i would like to wrap up by recapping the key points to summarize when it comes to securing the cicd ecosystem always start with this preliminary question do you trust this device on which code is being written when considering build and deployment security this is the initial question you need to ask yourself before making any decisions if you do trusted the

build and deployment pipeline needs to maintain the integrity of your code while it is being deployed it can also be used to gain additional confidence in the security of your code if you don't the build and deployment pipelines becomes the point at which you need to gain confidence in the core you're deploying this is critical your onward pipeline is the gateway to protection reduce the attack surface of your developer environment implement basic measures including network monitoring to detect suspicious activity verifying software that users are installing if possible install an endpoint protection and dlp protection and limited privileges on the workstation don't operate your production systems from a development environment managing production services from development environments can be high

risk in situations where this is required try to limit the exposure of your production services consider models for least privileged access management and temporary access credentials through a request process use a pipeline you trust consider how the pipeline itself is administered and managed including the underlying infrastructure if the security of this components is compromised it is difficult to assert trust in the code you build and deploy to it if the pipeline is managed by a service provider use the cloud security principles to understand the security properties of the service protect the access to your git repositories another critical git security issue you should guard against is unauthorized access to a git repository and sign your work

layering a process of cryptographic signing and code verification on top of your repository can help to increase confidence that the core has not been tampered with signing your work is an excellent way to add an extra layer of trust and segregation of privileges define access roles on a per repository basis to ensure only developers with valid access credentials can interact with individual repositories also the privileges of read and write for example the actual ci server does not need to make any modification to the code for the deployment you can limit the ci server to read-only access to the underlying repository limiting the damage from a potential breach of the csr and always peer review code before

deployment accept or reject according to your development process this step is an important source of quality control so you should always implement technical controls to prevent it being bypassed segregate the ci and see the environments avoiding having a single system with admin permissions for running a deployment instead deploy specialized versions of the deployment platforms with varying permissions for handling specific workflows by separating out the concerns for each pipeline you can reduce the blast radius of the damage that can be done with each set of credentials control how deployments are triggered code that triggers automated deployments to protection environments should be carefully managed production deployments shouldn't be made from untrusted code repositories folks or branches run automatic testing as a part of your

deployments well thought out that's can help you gain confidence in the security of your code batteries can get in way wherever possible automate testing so that supports the deployment pipeline cheap tests can be run on every code change resource and intensive tests can be saved for notable releases don't ignore tests that fail re-evaluate and refactor testing that does not work for you carefully manage secrets and credentials your deployment pipeline tooling may require secret tokens or credentials to launch and run the code inadvertently exposing secrets may allow unauthorized taxes to your systems take care in how you store manage and inject these into your environment consider rotating keys and how this process can be automated to make it

practical in your workflow ensure deployment pipeline controls cannot be bypassed or reordered all deployment processes should be followed from development through to deployment this could be achieved architecturally or by carrying out cryptographic signing and verification at each stage avoid self-policing the pipelines should enforce rules that define whether code is accepted or rejected before deployment it's possible that these controls are themselves implemented in source code along with your product it should not be possible for individuals to polis themselves by modifying these rules be cautious of untrusted branches and pull requests consider how your automated builds and test tooling reactive branches of your code or pull requests that may be malicious for example an attacker may be able to

execute malicious code within your environment if your automated tooling runs over third particle requests consider heartbreaks and approval fully automated deployments without adequate security controls in place is very high risk if you don't have confidence in the deployment pipeline process consider a heartbreak that requires approval before releases go live in the production environment the last one vulnerability management and patching well build tools and software are no exemption for vulnerability management build tools should go through the process of scanning evaluating trading and reporting on security vulnerabilities this implemented alongside with other security tactics is vital for organizations to prioritize possible threats and minimizing the attack surface of the ais ecosystem to wrap up the combination of the

dangers facing our cybersecurity industry the knowledge gap among devops security and operations team and the numerous components that need to be secured has made identifying and rooting of the security risks lurking in the cic ecosystem a real challenge what has demonstrated today using effective offensive and defensive techniques and strategies will mitigate these risks and elevate the overall security of the cic ecosystem here are my contact details connect with me and feel free to reach out with any questions you have after this presentation i'm sure you have all become fans of ci cd security but for those who are also interested in securing kubernetes clusters as mentioned previously i'm building a kubernetes security auditing tool named

cube striker i'm always looking for new users and collaborators to develop it further so reach out if you want to get involved or learn more finally i want to leave you with some more food for thought consider this if you patch 99 vulnerabilities of the 100 it doesn't mean you're 99 secured but you're still 100 vulnerable because a hacker needs only one weak link to bring your whole system down well that concludes my presentation and happy to take any questions now