How can we integrate security into the DevOps pipelines?

#devops #devsecops #security #automation

Article was published initially on Medium ->Link

Without a doubt, this may be one of the most common questions from security teams nowadays. The reason behind it is, security teams are only being involved by DevOps teams when business clients reach out about compliance, security, and internal as well as external regulations. By the time this stage of the project is reached, the CI/CD pipeline is already built-in, and it may be too complex for security teams to understand all the stages in the pipeline process.

Image source from https://devops.com

Traditionally, DevOps teams have a singular focus on building applications and delivering on release dates with little consideration to which security layers should be added to the pipeline. This is mainly because of three key challenges:

1º — The lack of knowledge security teams possess of DevOps.

2º — The high demand business units face to deliver new features, applications, and fixes, forcing DevOps teams to skip the stage of integrating security into the pipeline.

3º — The inadequate selection of security solutions to be seamlessly integrated into the pipeline.

The “Big” Issue with this Integration and How to Overcome it

Image source: [https://blog.hyperiondev.com

The majority of the security teams today have limited knowledge in programming languages such as, Ruby, Go, Node.JS, Java, Python, and others alike. In the past, when DevOps was much less prevalent, the security team didn’t have the responsibility to verify security processes in the development pipeline. The code security was and largely still is dependent on the background knowledge of developers and best practices they rely on for their development process. In most situations, developers have autonomy over their process and how they do their job if they produce the results the business is expecting. Recent culture changes like DevSecOps have introduced a new set of tools to automate security and incident response in the process. It won’t be long until the market and the security teams start adapting and accepting this new reality.

Companies should consider investing in their people by creating cross-functional teams that focus on training developers on the security discipline and teaching security professionals about the development process to fully embrace a DevSecOps culture. This could help security teams have a better understanding of programming languages and how to use APIs to automate the simple processes and win time for a more critical task inside your companies. It may sound cliché, but think about how many people in your team are confident enough to create an automation script in python or any language or manipulate APIs to automate the regular day-to-day work. I bet it is hard, but let me assure you understand this is quickly changing and becoming a sought after skill. Every single company is becoming a software company. If your company is not well adapted to the new world, you may start to face some very complicated challenges shortly.

An excellent example of this new world is how big companies are now asking and checking your GitHub or GitLab to see projects that you have been working on. Which open source project have you been helping in the last couple of years?

The OpenSource community is growing a lot, see some extra details about it in one of the latest reports about it from DigitalOcean: Link

“Try learning some programming language fast, it will help you more than you think in the future.”

8 Recommendations To Start Implementing Security In Your CI/CD Pipeline

The examples below are the most common security layers companies across the globe add in the DevOps pipeline:

Let’s dig in deep to all of the possible security components mentioned in the diagram above:

Unit Testing is a level of software testing where individual and small units or components of a software are verified. It could be used by developers to make sure precisely the right function is providing the right return, and a change/update in a small function is not affecting the results from the application.

Static Application Security Testing or (SAST) , also known as a “white box testing,” has been around for more than a decade. It allows developers to find vulnerabilities in the application source code earlier in the software development life cycle (SDLC). SAST solutions analyze an application from the “inside out” in a nonrunning state. Finding vulnerabilities in this stage of the SDLC can help your company save money and remediate the code faster.

Dynamic Application Security Testing or (DAST) , also known as “black box” testing, can find security vulnerabilities and weaknesses in typically web apps without a view into the internal source code. It does that by employing fault injection techniques on an application, such as feeding malicious data to the software to identify common security vulnerabilities, such as SQL injection and Crosssite scripting (XSS). It uses the same techniques that an attacker uses to find potential weaknesses in the application.

Dependency Scanning is an automated vulnerability scan in the dependencies while you are developing and testing applications, which looks for security issues. Many applications nowadays use external libraries or packages from open source projects that could have libraries with known vulnerabilities, and most of the time, the developers forget to check those things.

Container Scanning is a container image analyzer for known vulnerabilities, secrets keys (private keys), compliance checklist, and malware. Executing container security scanning at all stages of the software development life cycle (SDLC) helps the operations team to gain a clear understanding of what the security concerns are inside the container before they are sent to the production environment.

Runtime Protection is a security layer used on physical or virtual machines to protect the operating system and/or container engines. Some people forget it is crucial to protect the OS on the container host, because if it is compromised it could generate a DoS (Denial-of-Service) from all the containers running on that container host or node. This solution can help you to protect against malware, vulnerabilities and also assist with the audit process using features like file integrity monitoring, log inspection, and application control.

Privileged Container Security is a container where the container uid 0 is mapped to the host’s uid 0. In such containers, protection of the host, and prevention of escape is entirely done through Mandatory Access Control (apparmor, selinux), seccomp filters, dropping of capabilities, and namespaces. Those technologies combined typically prevent any accidental damage of the host, where damage is defined as things like reconfiguring host hardware, reconfiguring the host kernel, or accessing the host filesystem. There are some concerns with this security capability as a way to protect the environment if you are giving the privileged container full access to the host. This could potentially impact all the containers running on it if something goes wrong.

Runtime Application Self-Protection or (RASP) works inside the application as a security framework that monitors and continuously inspects traffic to the application and dynamically intercepts any traffic that indicates malicious behavior. RASP solutions can protect against SQL injection, Cross-site scripting (XSS), vulnerabilities, bots, and many other web application attacks. A RASP security framework is attached at the start of the SDLC, making the application secure by default. This security concept can be used in web applications, containers, and serverless.

Those are some of the most common security layers that you can add to the DevOps pipeline nowadays. I know it may seem complicated to add all of those layers at the same time, but with a good plan, you can adapt and make significant security progress in your current CI/CD pipelines.

Additional Architecture

Following below is an architecture with more details and the breakdown of how to layer in security at different steps in a DevOps pipeline:

Every company across the globe is becoming a software company and in order to stay successful, competitive, and secure, they will need to re-think the current cybersecurity strategy for cloud workloads, containers, and serverless environments.

Conclusion

In summary, more involvement from the security team in the early stages of the project is beneficial. This facilitates more reliable communication and integration between the DevOps and security teams, to achieve higher quality outcomes and better security of the applications delivered for your customers/business.

Thank you for reading this article. I hope it helps you better understand how to build a more secure DevOps pipeline.