There is no question that gets asked more by security teams, as they are typically brought into the DevOps world once the CI/CD pipeline is already built and clients are asking about compliance, security, and internal company regulations. Without the background on the process of building the pipeline, it can be complicated for security teams to comprehend all the stages in the process. Conventionally, the focus of DevOps teams is not on security, it’s on building applications and delivering them on time, but who is to say that can’t be done securely? Let’s dive into the main pain points. 

Download the e-book version: How Can We Integrate Security into DevOps and Infrastructure as Code Pipelines?

The “Big” Challenge of Integrating Security and Overcoming It

Generally speaking, if you mention words like Ruby, Go, Node.JS, Java, or Python, security teams aren’t necessarily going to be able to join into the conversation—to no fault of their own. When DevOps was just becoming popular, security teams weren’t deemed responsible for the verification of the development pipeline. Back then, and even now, the security code within the pipeline depended on the knowledge of the developers and best practices they relied on for their development process. Now, with the more recent introduction of DevSecOps, a new set of tools have been introduced to automate security and incident response. This provides more of an incentive for security to learn the language of DevOps and work together.

It won’t be long until security teams start adapting and accepting this new reality. Working together starts with an understanding of one another’s processes. If security teams understand the pipeline process, they can start planning security in the very early stages of any new application. Applying security directly into the integrated development environment and CI/CD pipeline will lead to faster detection and response of new security flaws that may be introduced and give developers real-time feedback to fix it.

To embrace a DevSecOps culture, a company needs to look at cross training their teams, for instance, teaching developers about security and educating security professionals on development processes and how to build new applications on demanding timelines. When we better understand one another, we can learn to speak each other’s language and work better as a team without so much friction. Now, the mention of programming languages won’t make security teams look at you with confusion and they may even understand how APIs can automate mundane tasks. Wouldn’t that be nice?

Imagine if your security team had the knowledge to write and understand an automation script in Python, Node.JS, or any other scripting language that would allow them to manipulate APIs to automate the regular day-to-day work. Many organizations are automating security processes and technologies for more effective and efficient security. This would include the use of APIs across build pipelines and runtime platforms and environments, but security needs to understand how it all works. If your company is not well adapted to the new world, you may start to face some very complicated challenges.

Nine Security Recommendations to Begin Implementing into Your CI/CD Pipeline

The methods below could be applied to monolithic applications or microservices applications using technologies like container, serverless, or cloud-native solutions.

  1. Unit Testing 
    This type of security verifies individual and small units of a software. Developers could use this to test if the right function is providing the right return, or to ensure a change/update in a small function isn’t affecting the results from the application.
  2. Static Application Security Testing (SAST)
    SAST is more commonly known as “white box testing”. This type of security testing gives developers the ability to find source-code vulnerabilities earlier in the software development life cycle (SDLC), which can help you remediate the code faster. SAST solutions analyze an application from the “inside out” in a non-running state.
  3. License Scanning
    This scanning tool helps you find what licenses your project uses in its dependencies, and decides whether to allow it or not.
  4. Dynamic Application Security Testing (DAST)
    DAST is more commonly known as “black box testing”. This type of security testing allows you to find security vulnerabilities and weaknesses in web apps without a view into the internal source code.
  5. Dependency Scanning 
    Many applications use external libraries or packages from open-source projects. This technique helps to automatically find vulnerabilities in your dependencies while you are developing and testing applications.
  6. Container Scanning
    This technique analyzes container images for known vulnerabilities, secrets, compliance checklists, and malware. You will want to execute this at all stages of the SDLC to help operations teams gain a clearer picture of what the security concerns are inside the container before they are sent to the production environment.
  7. Runtime Protection 
    This layer of security is used on physical or virtual machines to protect the OS and/or container engines. If the OS were to be compromised, it could cause a Denial of Service (DoS) from all the containers running on that container host or node. This solution can help you to protect against malware and vulnerabilities, as well as assist with the audit process using features like file integrity monitoring, log inspection, and application control.
  8. Privileged Container Security 
    This is 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, seccomp filters, dropping of capabilities, and namespaces. Those technologies combined typically prevent any accidental damage to the host. There are some concerns with this security capability. If you are giving the privileged container full access to the host, it could potentially impact all the containers running on it if something goes wrong.
  9. Runtime Application Self-Protection (RASP)
    RASP works inside the application as a security framework that monitors and continuously inspects traffic to the application. RASP dynamically intercepts the traffic that is deemed malicious, protecting you from 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.

These are just a few of the many security layers you can integrate into your DevOps pipeline. With a strategic approach, you can slowly begin to implement the proper security layers to gain assurance that your pipeline is secure, while continuing to move quickly.

Below is an architecture that shows how to layer in security at different steps in the DevOps pipeline:



Source link

Previous articleGoogle Calendar will break down how much of your work is spent in meetings
Next articleWeekly analysis – 16th June 2012 to 23rd June 2012

LEAVE A REPLY

Please enter your comment!
Please enter your name here