Sysdig is the secure DevOps company, and we’re at the forefront of the container and Kubernetes revolution

Sysdig

Sysdig is a universal system visibility tool with support for containers. What makes Sysdig special, is that it hooks itself into the machine's kernel and segregates the information on a per-container basis. For the scope of this tutorial, we will focus on the open-source version of Sysdig. In the next sections, you will: Install Sysdig Spin up a Wordpress installation using docker-compose Use Sysdig to collect events and analyze them at a later time Use Sysdig to analyze data in real-time Prerequisites Docker is installed on your system. For details about installing Docker, refer to the page. Install Docker Docker Compose is installed on your system. Refer to the page for instructions about how to install Docker Compose. Install Docker Compose The kernel headers are installed on the host system. Install Sysdig Follow these steps to install Sysdig inside a Docker container: 1. In a terminal window, execute the following command to pull the Sysdig Docker image: docker pull sysdig/sysdig Using default tag: latest
latest: Pulling from sysdig/sysdig
2967486b0658: Pull complete
78101b780c72: Pull complete
7e78b657334d: Pull complete
650327159ca8: Pull complete
47ebf73ab754: Pull complete
bf51ac76a6d9: Pull complete
0cd11104dbf6: Pull complete
e6dcf17d00d8: Pull complete
230d60083576: Pull complete
fd5ea9faf384: Pull complete
6de86c8ed6e9: Pull complete
8d1825f8be4b: Pull complete
Digest: sha256:bbfe6953fd2b3221a8974eb13024dd33c7e78aebef8fee3d7a0d9ecdeed84ce0
Status: Downloaded newer image sysdig/sysdig:latest for 2. Run Sysdig in a container by entering: docker run -i -t --name sysdig --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro sysdig/sysdig * Setting up /usr/src links from host
* Unloading sysdig-probe, present
* Running dkms install sysdig
Error! Your kernel headers kernel 3.10.0-957.12.2.el7.x86_64 cannot be found at
/lib/modules/3.10.0-957.12.2.el7.x86_64/build or /lib/modules/3.10.0-957.12.2.el7.x86_64/ .
* Running dkms build failed, couldn if for echo for source 't find /var/lib/dkms/sysdig/0.26.4/build/make.log
* Trying to load a system sysdig-probe, if present
* Trying to find precompiled sysdig-probe for 3.10.0-957.12.2.el7.x86_64
Found kernel config at /host/boot/config-3.10.0-957.12.2.el7.x86_64
* Trying to download precompiled module from https://s3.amazonaws.com/download.draios.com/stable/sysdig-probe-binaries/sysdig-probe-0.26.4-x86_64-3.10.0-957.12.2.el7.x86_64-82e2ae1fb159132636f7b50a762f20ef.ko
Download succeeded, loading module
root@7b14a23f22eb:/# A few things to note about the above command: The flag keeps STDIN open. -i The parameter provides Also it sets SELinux to allow the processes running inside of the container the as a process running on the host. --privileged access to all devices on the host. same access to the host The flag specifies the list of files ( ) that Sysdig can access. -v on the host Spin Up a Wordpress Installation In this section, you will install Wordpress using the command. docker-compose 1. In a , move into your projects directory and type the following commands: new terminal window mkdir wordpress-sysdig && wordpress-sysdig cd 2. Create a file called with the following content: docker-compose version: services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: somewordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
volumes:
    db_data: {} '3.3' "8000:80" 3. Run the command in detached mode with: docker-compose up docker-compose up -d Creating network with the default driver
Creating volume with default driver
Pulling wordpress (wordpress:latest)...
latest: Pulling from library/wordpress
8ec398bc0356: Pull complete
85cf4fc86478: Pull complete
970dadf4ccb6: Pull complete
8c04561117a4: Pull complete
d6b7434b63a2: Pull complete
83d8859e9744: Pull complete
9c3d824d0ad5: Pull complete
9e316fd5b3b3: Pull complete
578b40496c37: Pull complete
814ae7711d3c: Pull complete
4896fed78b6b: Pull complete
e74d71e9611d: Pull complete
46017765526c: Pull complete
280386098458: Pull complete
f32eb0d8c540: Pull complete
5c47b9ea747a: Pull complete
ecda5b7aad12: Pull complete
84256a6b6b44: Pull complete
35d4f385efb7: Pull complete
bf697c2ae701: Pull complete
d054b015f084: Pull complete
Digest: sha256:73e8d8adf491c7a358ff94c74c8ebe35cb5f8857e249eb8ce6062b8576a01465
Status: Downloaded newer image wordpress:latest
Creating wordpress-sysdig_db_1 ... Creating wordpress-sysdig_wordpress_1 ... "wordpress-sysdig_default" "wordpress-sysdig_db_data" for done done 4. You can verify the status of your containers with: docker ps If all is going well, you should see something similar to the following output: CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                  NAMES
f390eec29f52        wordpress:latest About a minute ago   Up About a minute   0.0.0.0:8000->80/tcp   wordpress-sysdig_wordpress_1
a844840626d8        mysql:5.7 About a minute ago   Up About a minute   3306/tcp, 33060/tcp    wordpress-sysdig_db_1
7b14a23f22eb        sysdig/sysdig 13 minutes ago       Up 13 minutes                              sysdig "docker-entrypoint.s…" "docker-entrypoint.s…" "/docker-entrypoint.…" 5. Now Wordpress is up and running. Point your browser to to start the installation wizard: http://localhost:8000 6. Once the installation wizard is finished, let us go ahead and create a sample post: Collecting Data to a File In this section, we'll show how you can use Sysdig to collect events and analyze them at a later time. 1. To dump all captured events to a file, move to the Sysdig container, and enter the following command: sysdig -w monitoring-wordpress.scap 2. In a new terminal window, use to make 10000 requests with a maximum of 100 requests running concurrently: ab ab -n 1000 -c 100 http://localhost:8000/?p=7 This is ApacheBench, Version 2.3 < : 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests $Revision Note that the above output was truncated for brevity. 3. Move back to tour Sysdig container and stop capturing data by entering "CTRL+C". Analyzing data Now, if you look at the size of the file, you'll notice that Sysdig captured no less than 80M of data: monitoring-wordpress.scap ls -lh monitoring-wordpress.scap -rw-r--r--. 1 root root 80M Jan  7 16:28 monitoring-wordpress.scap To find your way through this mountain of data, you'll use something called a . chisel A chisel is basically a Lua script that analyzes the event stream and performs useful actions. You can run the following command to display the list of chisels: sysdig -cl Category: Application
---------------------
httplog         HTTP requests httptop         Top HTTP requests
memcachelog     memcached requests Category: CPU Usage
-------------------
spectrogram     Visualize OS latency real time.
subsecoffset    Visualize subsecond offset execution time.
topcontainers_cpu
                Top containers by CPU usage
topprocs_cpu    Top processes by CPU usage

Category: Errors
----------------
topcontainers_error
                Top containers by number of errors
topfiles_errors Top files by number of errors
topprocs_errors top processes by number of errors log log in Note that the above output was truncated for brevity. To retrieve detailed information about a chisel, run the command followed by the flag and the name of the chisel, as in the following example: sysdig -i sysdig -i httptop Category: Application
---------------------
httptop         Top HTTP requests

Show top HTTP requests by: ncalls, time or bytes
Args:
[string] by - Show top HTTP transactions by: ncalls, time or by
                tes, default is ncalls Continuing our example, here's how you can use the chisel to display the top HTTP requests: httptop sysdig -r monitoring-wordpress.scap -c httptop ncalls              method              url
--------------------------------------------------------------------------------
2001                GET                 localhost:8000/?p=7
14                  OPTIONS             *
2                   GET                 localhost:8000/favicon.ico
1                   GET                 /wp-content/themes/twentytwenty/assets/fonts/inter/Inter-upright-var.woff2
1                   GET                 localhost/v1.24/containers/6bd8418eb03f/json
1                   GET                 localhost/v1.24/containers/06def7875617/json
1                   GET                 /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600
1                   GET                 /v1.24/images/db39680b63ac47a1d989da7b742f7b382af34d85a68214f8977bad59c05901
1                   GET                 localhost:8000/ You can see the same information in a format with the flag: container-friendly -pcontainer sysdig -r monitoring-wordpress.scap -c httptop -pcontainer ncalls              container           method              url
--------------------------------------------------------------------------------
1000                wordpress-sysdig_wo GET                 localhost:8000/?p=7
1000                host                GET                 localhost:8000/?p=7
43                  wordpress-sysdig_wo OPTIONS             *
1                   sysdig              GET                 /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600
1                   sysdig              GET                 localhost/v1.24/containers/06def7875617/json
1                   sysdig              GET                 localhost/v1.24/containers/cd06093b141b/json
1                   sysdig              GET                 /v1.24/images/00e230fe24da9067f9b6e65cfbe9935a5affac1ae8e44edb6a5b0ccc26374d
1                   sysdig              GET                 /v1.24/images/db39680b63ac47a1d989da7b742f7b382af34d85a68214f8977bad59c05901 Digging Deeper Sysdig captures content-rich information that lets you get detailed insights into the inner-workings of your containers. Let's suppose you're running a few containers and want to know which process consumes the most CPU. 1. List the containers that were active during the period in which you captured events: sysdig -r monitoring-wordpress.scap -c lscontainers 2. You can identify the container that consumed the most CPU with: sysdig -r monitoring-wordpress.scap -c topcontainers_cpu CPU%                container.name
--------------------------------------------------------------------------------
5.37%               wordpress-sysdig_wordpress_1
1.35%               wordpress-sysdig_db_1
0.84%               host
0.51%               sysdig 3. You can dig even deeper and identify the most CPU intensive process with the chisel: topprocs_cpu sysdig -r monitoring-wordpress.scap -c topprocs_cpu container.name contains wordpress_1 CPU%                Process             PID
--------------------------------------------------------------------------------
0.12%               apache2             8383
0.11%               apache2             9413
0.11%               apache2             9300
0.11%               apache2             9242
0.11%               apache2             8897
0.11%               apache2             8422
0.10%               apache2             9372
0.10%               apache2             9241
0.10%               apache2             8424
0.09%               apache2             9429 If you want to see more details,  the chisel provides a more verbose alternative: ps sysdig -r monitoring-wordpress.scap -c ps container.name=wordpress-sysdig_wordpress_1 TID     PID     USER        VIRT       RES        FDLIMIT   CMD
5896    5896    root        232.82M    22.32M     429496729 apache2
8383    8383    www-data    307.44M    25.46M     429496729 apache2
8422    8422    www-data    235.44M    22.90M     429496729 apache2
8424    8424    www-data    307.44M    25.46M     429496729 apache2
8897    8897    www-data    235.44M    22.89M     429496729 apache2
9154    9154    www-data    235.44M    22.91M     429496729 apache2
9241    9241    www-data    307.44M    25.66M     429496729 apache2
9242    9242    www-data    307.44M    25.67M     429496729 apache2
9300    9300    www-data    235.44M    22.89M     429496729 apache2
9372    9372    www-data    235.44M    22.89M     429496729 apache2
9413    9413    www-data    233.44M    20.77M     429496729 apache2 Tips Useful If you run Sysdig to capture events as in the above example ( ), the event file will grow continuously until it consumes all the available space. There are a few methods that can help prevent this from happening: sysdig -w monitoring-wordpress.scap Specify the number of events Sysdig should capture by passing it the flag. Once Sysdig captures the specified number of events, it'll automatically exit: -n sysdig -n 5000 -w monitoring-wordpress.scap Use the flag to configure Sysdig so that it breaks the capture into smaller files of a specified size. The following example continuously saves events to files < 10MB: -C sysdig -C 10 -w monitoring-wordpress.scap This will create a bunch of files no larger than 10 MB: ls -lh monitoring-wordpress* -rw-r--r--. 1 root root 9.6M Jan  7 17:13 monitoring-wordpress.scap0
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap1
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap2
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap3
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap4
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap5
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap6
-rw-r--r--. 1 root root 9.6M Jan  7 17:14 monitoring-wordpress.scap7
-rw-r--r--. 1 root root 6.4M Jan  7 17:14 monitoring-wordpress.scap8 Specify the maximum number of files Sysdig should keep with the flag. For example, you can combine the and flags like so: -W -C -W sysdig -C 10 -W 4 -w monitoring-wordpress.scap The above command will only keep the last four capture files: ls -lh monitoring-wordpress* -rw-r--r--. 1 root root 7.2M Jan  7 17:21 monitoring-wordpress.scap0
-rw-r--r--. 1 root root 9.6M Jan  7 17:21 monitoring-wordpress.scap1
-rw-r--r--. 1 root root 9.6M Jan  7 17:21 monitoring-wordpress.scap2
-rw-r--r--. 1 root root 9.6M Jan  7 17:21 monitoring-wordpress.scap3
root@cd06093b141b:/ # sysdig -C 10 -W 4 -w monitoring-wordpress.scap Real-Time Monitoring With Sysdig, you can also analyze data real-time. At first glance, this can seem like a daunting task because, by default, all events are continuously printed out to the console. Fortunately, chisels are here to help. Let's take an example. Analyze Processes on a Per Container Basis 1. Run the following command to list your containers: docker ps CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
5b253e74e8e7        sysdig/sysdig 9 minutes ago       Up 9 minutes                               sysdig
06def7875617        wordpress:latest 3 hours ago         Up 3 hours          0.0.0.0:8000->80/tcp   wordpress-sysdig_wordpress_1
6bd8418eb03f        mysql:5.7 3 hours ago         Up 3 hours          3306/tcp, 33060/tcp    wordpress-sysdig_db_1 "/docker-entrypoint.…" "docker-entrypoint.s…" "docker-entrypoint.s…" 2. You can analyze the processes running in the WordPress container with: sysdig -pc -c topprocs_cpu container.name=wordpress-sysdig_wordpress_1 3. Similarly, you can analyze the processes running in the MySQL container: sysdig -pc -c topprocs_cpu container.name=wordpress-sysdig_db_1 Note that, not much different from this example, Sysdig can monitor network traffic, disk usage, and so on. In this tutorial, you have gone over the fundamentals of using Sysdig to get a clear understanding of the activity generated by your containers. The examples in this blog post helped you get started and, in future tutorials, we'll show you how to use and . Csysdig Sysdig Inspect

Sysdig: What It Is and How to Use It

Breaches and cyber attacks dominate headlines today. Hardly a week goes by without news of another massive data leak or ransomware attack bringing a company to its knees. In fact, studies show that the of organizations have experienced cyberattacks. As threats proliferate, organizations invest heavily in security tools and staff. large majority The average enterprise uses a ridiculous and technologies. More tools mean more alerts and more alerts lead to alert fatigue. Unsurprisingly, a found that too many tools decrease effectiveness, hindering cybersecurity efforts. Exhausted security teams struggle to separate signal from noise, leading to missed threats and breaches. 45 different security solutions survey This rising tide of alerts threatens to drown security teams. A found that security analysts can’t deal with 67% of the daily alerts they receive. Most alerts are false positives and not worth the time. study by Vectra AI New cybersecurity vendors like Kivera are pioneering preventative approaches to cloud security. Rather than just detecting threats, before they happen to reduce the number of alerts in the first place. This prevents issues upfront rather than reacting after the fact. Kivera stops misconfigurations The Root Cause of Most Cloud Breaches The root cause behind most cloud breaches is misconfigured resources and permissions. Research suggests will result from customer misconfigurations by 2025. Cloud environments are incredibly complex, with thousands of services and configuration options. Just one mistake can leave an opening for attackers to exploit. 99% of cloud security failures All those misconfigured cloud resources trigger floods of policy violation alerts. But detecting problems after they occur is too late. The damage is already done. Attackers move quickly to take advantage of any slip-up. By the time an alert is triggered, sensitive data may have already been stolen. That's why forward-thinking organizations are shifting to preventative security controls. The traditional reactive model of detect-alert-respond is simply unsustainable. Prevention stops mistakes and policy violations before they ever happen. The Limitations of Detection-Focused Tools Cloud-native security tools on the market today focus heavily on detection and response. These tools are valuable layers of defense but come with inherent limitations: Cloud security posture management (CSPM) solutions from vendors such as Wiz and Orca continuously monitor cloud configurations and permissions. They identify resources that violate security policies or best practices. But again, problems are only detected after misconfigurations occur. The latest evolution in cloud security is cloud-native application protection platforms (CNAPP). Companies like Sysdig and Palo Alto Networks provide CNAPPs that combine security tools such as CSPM and CWPP with code scanning for cloud security. While these platforms embed security in code and templates, they face limitations in infrastructure-as-code scanning, restricted to specific programming languages. Kivera overcomes this by operating at the API level, offering a more universal and adaptable security solution.\ However, CNAPPs still rely heavily on threat detection and response. They aim to identify anomalies in cloud applications and resources. However, gaps that allow the attacks in the first place are not directly addressed. The Preventative Security Model The limitations of these detection-focused tools highlight the need for a preventative approach to cloud security. The ideal security model employs a mix of preventative and detective controls, commonly referred to as the “layered security model.” Preventative controls stop policy violations and misconfigurations before they happen. Rather than reacting to events, preventative controls proactively enforce security requirements within systems. Prevention provides a first line of defense to maintain a strong security posture. Detective controls then provide a second line of defense to identify threats that make it past the preventative line. Detective controls are still vital for monitoring, investigation, and incident response. Historically, implementing detective controls in a preventive manner has been challenging, but new tools provide an effective solution to enforce these common detective controls preventively, enhancing overall security posture. Why We Need Preventative Cloud Security This is where preventative approaches to cloud security become essential. Adopting such methods involves deploying inline security measures between users and the cloud. As deployment requests are made, these security systems analyze them against configured security policies. Any requests that violate these policies are immediately blocked, ensuring that only compliant resources are created. This approach emphasizes prevention over detection, eliminating the flood of policy violation alerts by avoiding misconfigurations in the first place. Security teams can then concentrate on real incidents rather than addressing misconfiguration. Vendors like are at the forefront in this area of cloud security. Kivera's solution allows customers to define flexible guardrails and policies tailored to their organization's needs. It then enforces these policies in real-time as users interact with the cloud, preventing misconfigurations at their source and avoiding reactionary measures after the fact. Kivera Best practices for implementing a prevent-first strategy include phasing in prevention by starting with the highest-risk misconfiguration threats and then incrementally expanding policies. Prevention should also be combined with detection tools for layered defenses to catch novel threats while tuning alerting to focus only on critical issues not prevented outright. Processes and training must align with prevention, emphasizing configuring policies over correcting violations. And any violations that still occur should be regularly reviewed to identify and address gaps in coverage. The Future of Cloud Security Today's cloud-first world demands a new approach to security. The volume and pace of threats have rendered traditional reactive models ineffective. Organizations need to prevent threats upfront before damage occurs. The future of security is prevention combined with detection. Organizations still need layered defenses to catch evolving threats. But prevention must come first to establish a robust security posture.

The Missing Piece in Cybersecurity: Tools that Go Beyond Issue Detection

The Certified Kubernetes Security Specialist (CKS) exam is the most challenging in the lineup of practical Kubernetes exams from CNCF.  I won't delve deep into its specifics here, as the Internet is full of relevant information.  It's worth saying that only those candidates who have passed the Certified Kubernetes Administrator (CKA) exam successfully  are eligible for the CKS exam. The topics required for the exam can be found . Additionally, proficiency with tools like falco, sysdig, and trivy is essential. You need to keep in mind that the Kubernetes cluster version used in the exam is updated following the release of each new Kubernetes version, and the delay between the release of a new Kubernetes version and the exam's version update usually does not exceed two months. here Preparation: Initial Steps and Unexpected Hurdles My preparation began two years ago with a course on . However, after two months, I had to interrupt my studies due to family circumstances. When I returned to my preparation some time later, I was faced with the necessity to move to another country. Due to it I had very little time for my studies, and I decided to take the exam without proper preparation. As expected, my first attempt was unsuccessful. kodekloud.com Next, I turned to the course offered by , but I found its content too sparse for independent preparation. Following the community's advice, I purchased a course from , which eventually proved to be the most beneficial, especially in the practical aspect. linuxfoundation.org killer.sh Nevertheless, a number of questions in the simulator were limited, and most of them did not provide a full picture of the possible exam tasks. This prompted me to create my own exam emulator based on AWS EC2 spot instances, using Terraform and Terragrunt. killer.sh CKS Simulator: Birth and Growth While developing the simulator, I managed to prepare for the exam and passed it. It happened on the second attempt due to technical problems from the examination center. After having passed it, I decided to share my experience and tools. It  led to the creation of the CKS Simulator project. Since then, 9 other professionals have joined the project. At present some of them are helping to update the database with exam questions, while others are assisting with documentation and the release of new versions. We are actively gathering feedback from those who've taken the exam to improve our simulator continuously. Mastering the CKS Exam: Insights and Tips For the examination, candidates connect through a secure browser to a virtual machine's desktop (similar to VNC). You won't have access to your browser bookmarks. Within this virtual machine you can launch as many terminals as you like and access the allowed documentation. However, remember that you can only have one page open at a time. It’s common to have problems with exam infrastructure. They include slow terminal responses or connection issues. If you encounter any such difficulties, immediately contact the support, and they'll reschedule your attempt. Having connected to this virtual machine, you'll find connections pre-configured for approximately 16 Kubernetes clusters. As a rule, each exam question utilizes its cluster. Questions vary in their point values, usually ranging from 1 to 12 points. Time management is crucial in this exam. As experience shows each point corresponds to roughly 1.1 minute. So, if a question is worth 4 points, try not to spend more than 5 minutes on it. If it takes longer, mark the question and move on to others, returning to it after you've seen all the remaining questions. Aim to use imperative commands as much as possible, such as for creating pods, deployments, secrets. Save manifests from these commands, edit the obtained manifests, and apply them to the cluster. The virtual machine's terminal has the alias set up. Make use of it, and also use the auto-completion feature (Tab key). Prioritize using the 'help' feature of console utilities whenever possible, as searching through the browser can be time-consuming. k=kubectl How the Simulator Works: The simulator sets up a VPC (Virtual Private Cloud), subnets, 10 Kubernetes (k8s) clusters with prepared resources, and a work-PC with tests for validation. To create exam infrastructure we use Terraform modules as templates. Terragrunt manifests consist of some modules and their parameters. Terragrunt executes these manifests and creates all the necessary exam infrastructure. The module handles network creation. vpc The module manages the creation of SSH keys. ssh-keys sets up a k8s cluster with specific parameters, such as the k8s version, EC2 node type, the number of worker nodes, their labels within the k8s cluster, and runtime ( , , ). k8s_self_management containerd cri-o containerd_gvisor The module is responsible for creating the work-PC. work_pc For convenience, all launch scripts have been added to a Makefile. To set up a new mock exam, you just need to execute the command , and to remove it . TASK=01 make run_cks_mock TASK=01 make delete_cks_mock Once the exam is set up, the script's output will provide you with the IP address of the work-PC. You log into it and complete the assignments. To check the remaining time for the exam, use the command, and to evaluate the assignments, use . time_left check_result For a detailed guide you can refer to the or watch the . documentation video tutorial Resources and Future Plans Currently, we have ready-made Terraform modules for scenario creation, lab works, and simulators for CKS and CKA exams, as well as video materials. We are planning to develop the simulator for the CKAD exam and lab works for AWS EKS in a very short time. : The Most Effective Path to Passing the CKS Exam Purchase the exam during discount periods. For example, during Cyber Monday, discounts can exceed 50%. I recommend buying and going through Kim Wüstkamp's course. Dive into all the theoretical materials and complete the practical assignments provided in the course. Upon purchasing the course, you'll gain access to a Slack channel. Here, you can pose questions to the course author and interact with other participants who are also preparing for the exam or have recently passed it. It's an excellent opportunity to learn about new exam questions and add them to your simulator. Regularly take the mock exam on our simulator until your final score consistently reaches 90% or above. Complete the mock exam on the platform. Its user interface closely mirrors the real exam, which will help you get accustomed to the format and prepare better . killer.sh After going through all these preparatory steps, you'll be ready to tackle the actual CKS exam. Conclusion If our project draws your interest, join us on or our . We always welcome new members and their feedback. We hope our platform will assist many engineers in passing the CKS and other IT-related exams successfully. GitHub YouTube channel If you have any changes or additions to share, please let me know!

The Path to Passing the CKS Exam: From Challenges to Creating a Simulator

For mature enterprises, planning, building, and managing foundational cloud technology platforms accelerate value for their internal clients. Once these enterprises reach a certain size and level of dependency on technology, establishing these foundational platforms help eliminate complexities, boost the effectiveness of its use base, and help adhere to compliance standards across the enterprise. Building these foundational platforms as a SaaS (Software as a Service) enables organizations to maximize their client experience and Return on Investment (ROI). Here is a sample that breaks down the path to SaaS success into four distinct phases (Business Planning, Product Strategy, , and Launch/Go-To-Market), each representing a critical stage in the move to SaaS. SaaS Journey Framework Minimum Viable Service At a broad level, SaaS Journey Framework allows you to accomplish the following: Articulate the compelling factors for bringing up a Platform as a Service, the Target market within the organization, and the potential customer segments. Have a strategy that articulates a clear set of capabilities/offerings that target specific personas within the consumer base. Identify critical capabilities for your Minimum Viable Service (MVS), and set clear definitions and expectations of the launch, timelines, target customers, and how you will engage potential customers to capture feedback. Before you launch, establish a Customer Advisory Board (CAB) to ingest voice-of-customer feedback and prioritize an appropriate sense of urgency; create measurable product adoption expectations. In the rest of the sections, we will get into each key pillar of success, as you build out your Cloud Platform as a Service. These key pillars of success can both be treated as a set of design principles and also as recipes for success. Content Overview Multi-Tenant Experience Control Plane Tenant Workloads Isolation On-boarding and Identity Foundation Self-Service CI/CD Pipeliness as a Service Centrally Managed Products Security by Default Conclusion Multi-Tenant Experience When you design your Cloud Platform for housing multiple tenants, you may want to take advantage of the economies of scale that come with . Simultaneously, the tenants require sharing infrastructure resources across tenants some of the resources to be dedicated to them. Different SaaS models such as Silo, Pool, and Hybrid provide different levels of multi-tenant experience and workload isolation. The silo model refers to an architecture where tenants are provided with dedicated resources. For example, each tenant of your cloud platform may have their own AWS account, that’s vended from a master aws organization’s account. Silo: The pool model refers to an architecture where tenants share resources. These resources typically belong to the base infrastructure. For example, networking services in aws such as NAT Gateway or VPCs could be shared across all your tenants. Pool: The hybrid model refers to an architecture where some resources of your platform are implemented in the Silo model and some in the Pool model. Hybrid: This pattern acknowledges the reality that you cannot exclusively design for Silo or Pool. In scenarios where you must comply with strict workload isolation for teams, choose Silo model. In scenarios where you would benefit from economies of scale (for example, a common set of VPCs, subnets, and NAT Gateway for a set of customers), choose Pool model. Immaterial of which model you choose, each environment managed by your platform still relies on a shared identity, onboarding, and operational experience where all tenants are managed and deployed via a shared construct. This is where a comes in to help. Control Plane based operation Control Plane Control Plane is a management and operations layer that houses central SDKs and CI/CD Pipelines and operates across multiple accounts. It is a critical part of your multi-tenant strategy that ensures that all your Infrastructure as Code pipelines (including On-boarding pipelines) are unified, and managed through a central account (Single Pane of Glass). With Control Plane, you can: Launch Base Infrastructure Resources across multiple hosts (aka accounts) through configuration. On-board teams across all your platform-as-service offerings, through a single, automated, repeated process. Manage platform admin CI/CD Pipelines as products, thus achieving standardization across all admin pipelines. Build standard Admin Deployers that enable you to provide CI/CD Pipeline as Services. Tenant Workloads Isolation When you build and operate a multi-tenant platform as a service, you must ensure that . each tenant is prevented from accessing another tenant’s resources The following strategies help in enforcing workloads isolation: ABAC is an authorization strategy that defines permissions based on attributes. For example, you can enforce a policy that allows permissions to a user only when the user’s matches the resource’s Attribute-Based Access Control (ABAC): team name tag team name tag. All resources in your cloud provider may not support ABAC. In such scenarios, the NBAC strategy additionally helps you to enforce permissions to a team based on resource naming convention. For example, you can enforce a policy that allows permissions to a user only when the resource starts with the to which a user belongs. Use this as a complementary strategy on & above ABAC. Name-Based Access Control (NBAC): team name In AWS, IAM Policy Conditions element and IAM Policy Resource element are excellent ways to enforce both ABAC and NBAC. Beyond tenant workloads isolation, ABAC (using Tags) also allows you to measure the cost impact of individual tenants. Designing multi-tenant experience for your platform as a service requires deliberate planning. The above patterns and techniques (Silo/Pool/Hybrid, Control Plane and Authorization strategies) should help you in coming up with a robust design. On-boarding and Identity Foundation There are several channels (sign-up page / GitHub Pull Request etc.) through which you may want to onboard tenants for your platform. Most often, tenant onboarding is initiated directly by tenants, but this could be a provider-managed process too. Immaterial of the channel, this step often requires the orchestration of a number of components to successfully provision and configure all the elements needed to create a new tenant. For example, let’s take a scenario where we have decided on our authentication strategy as IAM with MFA. When a Team (composed of a set of users) is on-boarded, the platform may perform the following steps: Create for each user within a team & attach the tag to the user with an appropriate value. IAM User team name Attach IAM User to one or many , depending upon the attached to the user in the request. IAM Groups persona Create with appropriate permissions that underlying cloud services will use for execution. For example, the platform may create separate Team Execution Roles for SageMaker & Glue. Team Execution Roles Create AWS SNS Topic for a Team as well as for each user. These topics can then be used for sending notifications to the team or a user. Attach that govern platform usage across all users. For example, mandate MFA before any service is accessed through Console or CLI. common policies By pre-packaging all preventive permissions and team-specific resources (like execution roles) during on-boarding, you can deliver a secure, governed yet easy-to-use and repeatable on-boarding process that just works. Self-Service Self Service is a key pillar that unlocks by empowering consumers to launch cloud resources and pipelines with little or no intervention from administrators. accelerated delivery Enabling Self-Service on Cloud Platforms is hard since you need to simultaneously satisfy two goals that are seemingly contradictory: On the one hand, you need to provide flexibility to end users. On the other hand, you require your cloud resources to be secure and compliant. AWS offers a couple of interesting models for self-service that you can embrace. CI/CD Pipelines as a Service Pipelines as a Service offers a toolchain standard to be re-used by application teams. In this model, end-user teams launch a governed deployment pipeline from AWS Service Catalog. CI/CD The workflow for this model is as follows: Cloud platform engineers develop a . service catalog product A product comprises one or more AWS resources and is created by designing AWS CloudFormation templates that combine resources, their relationships, and the parameters that the end user can plug in when they launch the product. For example, a CI/CD Pipeline Service product may create an AWS CodePipeline project that connects with a GitHub Repository branch (plugged in by end-users) for the followed by a which invokes a Lambda Deployer Function that performs the required deployment. source stage, deploy stage, The input to the Lambda Deployer function comes from a configuration file, which is supplied by end-users. DSL The launch of a product just creates a fully functional CI/CD Pipeline. Now, whenever end-users push the DSL configuration file & any other associated required files into the GitHub Repository branch, the CI/CD Pipeline kicks off and the Lambda Deployer function performs the deployment & also notifies the end-user through Team SNS Topic. Key Benefits: End-users are provided with the flexibility to specify configurations & details pertaining to the deployment (flexible), but admin takes care of the actual deployment to the cloud (standardization and compliance) Standard deployers, but flexible configuration: Every deployment of a resource by the consumer team is forcefully driven through the . Further, this follows a full-fledged way of implementing Continuous Delivery for cloud-native applications. GitOps & DSL driven: GitHub repository PR-Merge process GitOps Eliminates individual personnel dependency https://twitter.com/kelseyhightower/status/953638870888849408?s=20&embedable=true Centrally Managed Products This model allows end-user/consumer teams to provision resources managed by a central operations team . as self-service In this model, Cloud platform engineers publish infrastructure portfolios to AWS Service Catalog with pre-approved configuration. This locks down how infrastructure is configured and provisioned. For example, consider offering In this case, the workflow would be as follows: S3 Bucket as a Service. Cloud platform engineers design and create a CloudFormation template, with appropriate end-user parameters such as team name, bucket name, etc. They pack in all required security and compliance requirements (No Public ACLs, enforce in-transit and at-rest encryption, etc.) They add required tests and DevSecOps validations. They roll out this as a Service Catalog Product. When end users launch this product, they receive a fully secure and compliant resource that is locked down to their team. Key Benefits End users are NOT provided elevated benefits. They must use Service Catalog products to launch resources. Principle of least Privilege: All resources created through Service Catalog exhibit thus accomplishing standardization and compliance. Standardization & Compliance: the same behavior, With models, platform admins can provide superior self-service to end-users while adhering to the highest levels of security, standardization, and compliance. Centrally Managed Products & CI/CD Pipelines as a Service Security by Default Security is a key pillar that provides multi-fold benefits, especially when you are launching a platform as a service. Building all capabilities and services with principle ensures that hundreds of teams in your organization use these products, . Security by default without worrying about managing security in the cloud Below are a few strategies to ensure that platform offerings are secure by default: A strong Identity Foundation that is either built with MFA (or) Single Sign-on, and a Teams construct that ensures that workloads are appropriately tagged and authorized. A preventive permissions model that protects cloud resources across all channels (console, CLI, programmatic access) and also enforces . team permissions A carefully designed Tenant Workloads isolation through Attribute Based Access Control (ABAC) and Name Based Access Control (NBAC) ensures teams can access only what is theirs. A Control Plane architecture that ensures that all products and pipelines are launched into accounts from a central account (single pane of glass). A carefully enforced data encryption standards (transport layer & at-rest) while launching products through , through appropriate configuration. Centrally Managed Products & CI/CD Pipelines as a Service Built-in DevSecOps controls through standard libraries like Checkov, which are codified at the source, and automated for efficiency. Integrated container security during Continuous Integration with tools like sysdig. A hardened security posture for externally exposed services with appropriate controls such as CloudFront, Web Application Firewall (WAF), API Keys, and Usage Plans. Enforce standard tags across all resources launched (including admin resources) for attribution, security, and FinOps. By establishing preventive guardrails, including DevSecOps in all builds, protecting data privacy in the capabilities offered, and isolating team workloads, you can deliver an exceptional security by default that works for teams at scale. Conclusion Cloud Platforms as a Service provide agility and innovation to mature organizations. By treating them as full-fledged SaaS services with the help of the SaaS journey framework, and also coming up with a solid architecture with the help of the above-mentioned pillars, organizations can unlock exceptional service experience and also increase agility. “Platforms and platform thinking aren’t cure-all solutions. They’re conduits and catalysts for your strategic goals. To harness their full potential and realize their full value, they must be designed and built with your unique goals in mind.” — Rachel Laycock, Global Managing Director, Enterprise Modernization, Platforms and Cloud References Realizing the potential of platforms SaaS Journey Framework — One Minute White Paper SaaS Journey Framework Accelerate Deployments on AWS with effective governance Platform Engineering Product Teams Realizing the potential of Platforms The enterprise guide to platform thinking Also published here.

Building Cloud Platforms as a Service — Key Pillars of Success

335 Stories To Learn About Serverless

Many enterprises that implement Kubernetes don’t realize how insecure it can truly be out of the box — and even when they do, they’re not sure what to do about it. And since Kubernetes is an extremely complex and flexible tool that in production can consist of hundreds, if not thousands, of moving parts — understanding the vulnerabilities of Kubernetes, potential solutions, and relevant regulations and trends can be a time-consuming and daunting task. For most any business, this makes it way too easy to introduce serious legal or security issues into their clusters and production applications. With KubeCon Europe 2023, I was impressed with (and happy to see) the number of security solutions entering the market. Continuing from 2022, the biggest theme from KubeCon Europe 2023 was software supply chain security — ensuring that you know what’s running in your cluster and that it’s vulnerability free. I was struck then, as I have been in recent years, by the importance of software supply chain security. With cloud-native apps, containerization, and Kubernetes, today’s software organizations are in an arms race with malicious attackers who seek to undermine and poison our software. So I was pleased to come across several additional projects at KubeCon Europe 2023 that are dedicated to tackling the challenge of Kubernetes security. In this article, I’ll give a whistle-stop tour of those projects. But let’s start with a quick overview of the conference and what I consider to be the most important aspects of k8s security. Breaking Down Kubernetes Security First, the conference. I was a little worried that the IT recession might mean the conference wouldn’t be as meaningful as in past years — but I’m happy to say that I had no need to worry! While I wasn’t able to attend in person, through remote and post-conference conversations with those that were there, the conference seemed to be as exciting as ever! While there weren’t any standout new trends at the conference, there was a ton of tooling and discussion around Kubernetes security. To keep everything straight in my mind, I categorize k8s security into three particular aspects: attestation, provenance, and SBOM: Attestation: Confirming your artifact’s origin and that it is what it claims to be. Attestation typically comes in the form of signing containers, packages, and so on, in a way that the receiving party can verify. Provenance: The audit trail of where the artifact came from and who had interactions with it. Often used in connection with attestation if something doesn’t look right. Software bill of materials (SBOM): What are the packages and dependencies inside the artifact? These are increasingly necessary for regulation and as a demonstration to customers. With that in mind, let’s walk through the solutions. OpenClarity consists of a suite of tools that aim to bring insights into different levels of the cloud-native stack, from security to observability. OpenClarity The two relevant components to this post are KubeClarity and VMClarity which create SBOMs and perform vulnerability analysis for Kubernetes clusters and virtual machines respectively. runs on any Kubernetes cluster and provides a UI and CLI for analyzing images and generating SBOMs. By default, KubeClarity doesn’t have its own SBOM generator or vulnerability scanner, but instead, supports third-party tools that you can enable in any combination, making it great for adding additional interfaces for existing toolchains. KubeClarity If you would rather not install each of the components yourself, then they’re commercially available as part of . Cisco Panoptica Support includes the following SBOM generators and vulnerability scanners: Syft CycloneDx-gomod Trivy Grype Dependency-Track We’ll cover some of these projects in more detail below. works similarly but within the context of VMs used by cloud services to host containers and clusters. Compared to containers, VMs may be as (or even more) vulnerable to threats and they typically need complex tools for analysis. VMClarity Following a similar pattern to KubeClarity, VMClarity supports aggregating multiple tools into one UI and CLI. in-toto is an open-source project that focuses on the attestation part of software supply chain security. You use it to define a “layout” for a project, i.e., how the different components should fit together. in-toto A project ships this definition with its code, and then another user of that software can compare what they have with the attached definition to see if it matches the structure and contents they expect. If it doesn’t, then this could point to external tampering or other issues. Trivy is a mature and comprehensive open-source tool from Aqua Security that supports scanning multiple sources, from file systems to containers and VMs. Trivy also looks beyond vulnerabilities, to scan licenses, secrets, infrastructure as code misconfiguration, and more. Trivy It supports different SBOM output formats, attestation using in-toto, as well as scanning the attestation for vulnerabilities. To tie all these features together, Trivy has an ecosystem support, complete with IDE plugins, CI/CD, and a Kubernetes operator. Slim.ai Historically, aimed to help you understand the contents of an image and how to “slim” it down to the essentials. The platform has now expanded its feature set to include vulnerability scanning. Slim.ai Slim.ai presents the data in a more user-friendly way than many of the other tools in this post. On top of its open-source for identifying the contents of an image, Slim.ai uses Trivy for vulnerability scanning. SlimToolkit You can then use the “harden” feature to create a new version of the image that’s removed any vulnerabilities and extraneous packages. The Update Framework A common reason behind insecure software is out-of-date package versions, but how do you trust that an update is what it says it is and won’t cause you more problems? Release signing—or attestation—was a hot topic at KubeCon among vendors, with many offering their own solutions. One in particular that stood out was CNCF’s recently graduated (TUF). The Update Framework Confusingly named, it’s not a framework, but a specification that developers can follow when implementing their update systems to help users know they can trust the updates they receive. There’s also a . Python reference implementation Syft is a popular open-source CLI tool created by for generating an SBOM from container images and filesystems. It’s designed to provide a catalog of dependencies for other tools to use as a data source. Syft Anchore It supports many popular programming languages, package managers, and container image formats. With its support for different SBOM file formats and custom templates for reports, Syft has become an ideal component for vulnerability scanning toolchains. Grype is another popular open-source tool from Anchore. Working with SBOM files, Grype scans container images and filesystems for vulnerabilities. Grype supports different output formats for vulnerabilities and custom templates for output. Grype sigstore is another suite of tools that focuses on attestation and provenance. Within the suite are two tools I heard mentioned a few times at KubeCon: and . sigstore Cosign Rekor Cosign is used for signing containers through a variety of different methods. It has strong integration with other open-source tools, such as . Kyverno Rekor is a tamper-resistant ledger for metadata generated by a software supply chain project. This means that parties can query the metadata to help them make decisions based on decisions previously made by others. It’s not a very well-known project, but it is growing in popularity. Kubescape is a comprehensive Kubernetes security platform and CNCF sandbox project. It can scan clusters, Helm charts, and YAML manifests to detect misconfigurations. It supports various frameworks, including , , and the . Kubescape NSA-CISA MITRE ATT&CK® CIS Benchmark Chainguard Taking a very definite enterprise approach, is impossible to try without first speaking with their sales department. But as far as I can tell, it consists of two main products. Chainguard Chainguard Images are specialized, hardened images that focus on a minimal footprint, promise no vulnerabilities, are as small as possible, and ship with SBOMs. Chainguard Enforce combines the creation of policies for your software supply chain with the enforcement of those policies. You write policies in YAML or by using a CLI tool to configure a Kubernetes agent that reports back to the service. You can view reports via the CLI or a GUI. Policies can include image signing, SBOM inclusion, and more. Chainguard also appears to have several . The most popular one is , used for building OCI images from APK packages. open-source projects apko Falco is a well-known open-source security solution originally created by Sysdig. It’s a CNCF incubating project and one of the few (as far as I can tell) options on this list that uses eBPF to scan for vulnerabilities. Falco This does mean it needs a few extra steps to install, and you can only test it on Linux systems. However, once you have Falco set up, it runs more performant than any container agent and can detect vulnerabilities at all system levels. The Future Is Complicated I hope you enjoyed this overview and found a few tools that will help you secure your enterprise. Most experts believe that cybersecurity will become more complex and challenging as more aspects of the world are dominated by software: IoT, smart cars, and drones—and now, we’ve added AI and LLMs to the mix. The arms race between attackers and defenders doesn't seem to favor the defenders. And deploying solutions is a complicated endeavor. Now is a good time to find the tools and workflows that suit you and your organization before you become the target. Have a really great day!

An Overview of Kubernetes Security Projects at KubeCon Europe 2023

Organizations now recognize the significant role of integrating security in the software development lifecycle. DevSecOps is a powerful approach that has emerged to achieve this goal. By incorporating security practices at the earliest stages of development, DevSecOps helps organizations identify and reduce vulnerabilities more effectively, minimize the risk of security breaches, and build more secure applications. This article will discuss the fundamental principles of DevSecOps and provide key steps for securing your organization’s CI/CD Pipeline. DevSecOps Principles : Organizational principles It is important to involve Security teams right from the beginning of a project to make sure that security requirements are given serious thought and attention early on. This step can prevent the discovery of security problems later in the development phase, which could be more expensive and time-consuming to fix. Involve Security Teams Early: In DevSecOps, it is important for Development, Security, and Operations teams to work together. By promoting a culture of shared responsibility for security, organizations can ensure that all team members play a part in creating secure applications and in identifying and solving security issues faster. Collaboration and Transparency: DevSecOps incorporates security practices early in the development process, also known as "shifting left." It helps organizations to detect vulnerabilities in the codebase before they escalate into expensive and time-consuming issues. Shift-Left: DevSecOps advocates for the inclusion of security procedures throughout the entire software development process, ensuring continuous security. This involves implementing automated security testing, constant monitoring, and regular security evaluations. Continuous Security: The concept of security chaos engineering involves deliberately introducing security-related problems and disruptions into a system to verify its ability to withstand them and reveal weaknesses. Security Chaos Engineering: By replicating actual security incidents, organizations can obtain significant insights into their system's performance during challenging conditions. This enables them to take proactive measures to address vulnerabilities and enhance their overall security position. Security Awareness/Training principles: To make security a top priority of your organization, provide your team members with security training and resources, encourage collaboration, and recognize that everyone is responsible for security. By doing this, you can cultivate a culture that prioritizes and integrates security throughout your organization. Foster a Security Culture: Developers should be encouraged to adopt secure coding practices like input validation, output encoding, and proper error handling. These practices will help mitigate security vulnerabilities in the code and reduce the risk of potential attacks. Adopt Secure Coding Practices: Gamification techniques can be adopted by organizations to encourage a security-focused culture and educate team members on security best practices. Gamification of Security Training: By transforming security training into an enjoyable and competitive experience, engagement and knowledge retention can be enhanced, ultimately promoting better security practices throughout the organization. Technical principles: Automating security processes can bring various benefits to organizations. These include increased efficiency, reduced human error, and the consistent application of security best practices. Automation: To maintain security during the development process, it is important to regularly run security checks and tests within the continuous integration and continuous deployment pipeline. This will ensure that security concerns are constantly evaluated and addressed. Integrate Security into the CI/CD Pipeline: Use tools like static application security testing (SAST) and dynamic application security testing (DAST) to check for weaknesses and potential security threats in your codebase. These automated security testing tools should be added to your organization's CI/CD pipeline to provide real-time security feedback. Implement Automated Security Testing: Securing the CI/CD Pipeline: Key Steps and Solutions To secure your CI/CD pipeline, protecting the Build environment is the first essential step. Only authorized personnel should access Build servers and infrastructure. To prevent unauthorized access, implement robust authentication methods, such as multi-factor authentication (MFA) with hardware keys. Additionally, keep the Build environment up to date with the latest security patches, and configure it according to the best industry practices. Secure the Build Environment: To safeguard your code repository, implement robust access controls that permit only the necessary access to authorized personnel, and monitor it frequently to identify any suspicious activities. Also, keep reviewing and updating user permissions and use encryption to protect sensitive data stored in the repository. Secure Code Repository: Hardcoded credentials, such as passwords or secret keys within the code, is a serious security risk as they can provide unauthorized access if the code is exposed. Hardcoded Credentials Scanner Solutions: Open-source solutions: TruffleHog - https://github.com/trufflesecurity/trufflehog - GitLeaks https://github.com/gitleaks/gitleaks - GitSecrets https://github.com/awslabs/git-secrets Enterprise solutions: GitGuardian - https://www.gitguardian.com/ SpectralOps - https://spectralops.io/ Bridgecrew - https://bridgecrew.io/secrets-scanning/ To automatically detect any potential security weaknesses in your code during the build process, integrate SAST tools into the CI pipeline. These tools can help you find problems such as insecure coding practices, input validation errors, and potential code injection vulnerabilities. Static Application Security Testing (SAST): Open-source solutions: SonarQube - https://www.sonarsource.com/products/sonarqube/ Semgrep CLI - https://github.com/returntocorp/semgrep Enterprise solutions: Veracode - https://www.veracode.com/products/binary-static-analysis-sast Checkmarx - https://checkmarx.com/cxsast-source-code-scanning/ - Coverity https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html To ensure the security of your application, you can use SCA tools to track third-party libraries and open-source components that you use. SCA tools can check for potential security risks such as outdated components, known vulnerabilities, and licensing issues. Software Composition Analysis (SCA): Open-source solutions: OWASP Dependency-Check - https://owasp.org/www-project-dependency-check/ - Nancy (GoLang) https://gonancy.dev/ - RetireJS (JavaScript) https://retirejs.github.io/retire.js/ - Safety (Python) https://github.com/pyupio/safety Enterprise solutions: - Black Duck Hub https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html Mend - https://www.mend.io/sca/ Snyk - https://snyk.io/ In case your software uses containers, make sure to follow container security best practices, which include implementing minimal base images, scanning for vulnerabilities, and enforcing strict access controls. Additionally, it would be best if you used specialized container security tools, like container vulnerability scanners and runtime security monitoring solutions. Container Security: Open-source solutions: Trivy - https://github.com/aquasecurity/trivy - Grype https://github.com/anchore/grype - Clair https://github.com/quay/clair Enterprise solutions: Aqua Security - https://www.aquasec.com/products/software-supply-chain-security/ Sysdig Secure - https://sysdig.com/products/secure/ Snyk - https://snyk.io/product/container-vulnerability-management/ Incorporate security checks into your use of IAC tools like Terraform, CloudFormation, or Ansible. This is to ensure that the configuration of your infrastructure is indeed secure and free from potential security misconfiguration. Infrastructure as Code (IaC) Security: Open-source solutions: Checkov - https://github.com/bridgecrewio/checkov Tfsec - https://github.com/aquasecurity/tfsec KICS - https://kics.io/ Enterprise solutions: Bridgecrew - https://bridgecrew.io/infrastructure-as-code-security/ Prisma Cloud - https://www.paloaltonetworks.com/prisma/cloud/infrastructure-as-code-security - Snyk https://snyk.io/product/infrastructure-as-code-security/ To test your application in a real-time environment, add DAST tools to your CI/CD pipeline. These tools can uncover vulnerabilities that may only become visible when the application is executing, such as configuration issues, authentication problems, and access control concerns. Automated DAST tools should be used for thorough security testing. Dynamic Application Security Testing (DAST): Open-source solutions: OWASP Zed Attack Proxy (ZAP) - https://www.zaproxy.org/ - Nikto https://github.com/sullo/nikto - GoLismero https://github.com/golismero/golismero Enterprise solutions: Fortify WebInspect - https://www.microfocus.com/en-us/cyberres/application-security/webinspect Rapid7 InsightAppSec - https://www.rapid7.com/products/insightappsec/ - Checkmarx https://checkmarx.com/checkmarx-dast/ To enhance the security of your application and infrastructure, it is essential to continuously track and analyze their behavior. This can be achieved by implementing solutions for constant monitoring and logging. By doing so, you can quickly identify and respond to any potential security incidents that might occur. Continuous Monitoring and Logging: To facilitate this process, tools like SIEM (Security Information and Event Management) systems, intrusion detection systems, and log analyzers can be used to detect and alert you on security events. Open-source solution: ELK Stack (Elasticsearch, Logstash, and Kibana) - https://www.elastic.co/ Enterprise solutions: Splunk - https://www.splunk.com/en_us/products/enterprise-security.html Datadog - https://www.datadoghq.com/ To maintain the security and adherence of your CI/CD pipeline to industry standards and regulations, it is essential to conduct regular security audits and assessments. This includes examining the code, testing for potential vulnerabilities, and assessing the infrastructure. By implementing these measures, you can ensure that your pipeline is secure and compliant. Regular Security Audits and Assessments: Open-source solutions: OpenVAS - https://github.com/greenbone/ - BurpSuite Community https://portswigger.net/burp/communitydownload Enterprise solutions: Tenable Nessus - https://www.tenable.com/products/nessus QualysGuard - https://www.qualys.com/cloud-platform/ - BurpSuite Professional https://portswigger.net/burp/pro To be well-prepared for any security breach or incident, it is essential to create a clear incident response plan that lists the necessary steps to take. To ensure the safety of your application, your CI/CD pipeline must have the ability to roll back any deployments, patch any vulnerabilities, and immediately redeploy secure versions of your application. Incident Response Planning: Open-source solution: TheHive Project - https://thehive-project.org/ Enterprise solutions: IBM Resilient - https://www.ibm.com/products/qradar-soar Cortex XSOAR - https://www.paloaltonetworks.com/cortex/cortex-xsoar - D3Security SOAR https://d3security.com/enterprise-soar/ is a beneficial tool for DevSecOps teams. It's an open-source vulnerability management tool created by the OWASP community. Vulnerability Management and Reporting: DefectDojo This tool helps manage security vulnerabilities in the development process. One central space for all the information regarding defects is provided by DefectDojo. It makes it easier for teams to generate detailed reports and keep track of their progress over time. DefectDojo promotes clear communication about vulnerabilities, which ensures that security issues are resolved efficiently and promptly. As you can see, it is crucial to secure the CI/CD pipeline to implement a successful DevSecOps process. To achieve this, organizations need to incorporate security checks and tools throughout the pipeline. By doing so, they can identify vulnerabilities in advance and address them before they can cause security breaches. This helps to ensure that their applications are secure and comply with regulations. With the steps and practices outlined in this article, you can establish a robust and secure CI/CD pipeline for delivering software quickly and safely.

SYSDIG

sysdig.com

-- employees

Since n.d.

COMPANY RANKING

SYSDIG

EVERGREEN INDEX #10128

Representing this company? Click here to claim and customize this page!

Sysdig WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

SYSDIG

sysdig.com

-- employees

Since n.d.

COMPANY RANKING

SYSDIG

EVERGREEN INDEX #10128

RELATED COMPANIESRANK

STORIES ABOUT SYSDIG

Representing this company? Click here to claim and customize this page!

Sysdig WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!