How Agile & Container technology led to the rise of enterprise DevSecOps

New development processes and open-source technologies have shifted the technology security landscape for enterprises. Previously a separate security department often dealt with these concerns. Now, more than ever, developers must build applications with a security mindset.  This security mindset reflects the recent “DevSecOps” (short for “development, security, and operations”) movement. Though considered a “buzzword” by some, the term’s significance should not be discounted. Including security measures into the software development lifecycle (SDLC)  from Step 1 is key, particularly for organizations.

To help illustrate the importance of early security we will first focus on Agile DevOps (i.e., development and operations) processes, and then discuss microservices and open-source container technologies which have become hugely popular in recent years.

What caused the rise in DevSecOps?

Changes to the software development landscape, including processes and technologies, helped bring about a DevSecOps mindset.

Agile DevOps

Agile DevOps type practices, which have become popular, stress building new features incrementally, speed of delivery and deployment, and responding to change quickly. More enterprise organizational structures incorporate DevOps teams consisting of individuals across disciplines bringing unique perspectives to projects. Tackling small deliverables at the same time leads to a faster pace and deployments at regular, steady intervals. 

Unfortunately, by prioritizing releases and new features, security measures often lack. Sometimes technical teams finish projects only to learn about security vulnerabilities in testing. This can result in costly and time-consuming delays in delivery.

Rise of Containerization and Docker

Containers package an application along with all its dependencies into the form of a container image, allowing for portability. This container image can be run on a container runtime, whose responsibility is to execute containers and manage container images on a node. Containerization raises the rate of deployment for two key reasons: portability and lightweightedness. Containerization helps implement agile DevOps practices. With it, teams break programs into containerized segments that allow for deployment and testing to occur in simulated environments. These very closely mimic the final production environment.

Docker

Docker, probably the most popular container platform, came onto the map in 2013, enabling microservices architecture, continuous deployment and delivery. The term “Docker” colloquially refers to the Docker Engine, the container runtime that lets users build images and run containers. Docker images are the portable component that encapsulates the commands and data required for instantiating and running a Docker container. Even though Docker Engine is the most broadly used container runtime, other compatible implementations, such as cri-o, currently exist.

Microservice Architecture

With isolated, resource-controlled containers, organizations can switch from a monolithic architecture to a microservices architecture. Microservices architecture arranges applications as loosely coupled services. Key advantages over a monolithic architecture include scalability and independence. Different domains of the application can be scaled independently to respond to the different load they are subjected to. Their independence also brings extreme value in the continuous delivery software development process — modifying one or a small part of an application does not require refactoring or redeploying the whole application as long as the interface between them is unchanged. The distribution across microservices reduces entanglement that would result in a complete overhaul, ultimately prompting increased enterprise adoption. Despite their benefits, microservice architectures have their own set of challenges when compared to monolithic ones. For instance, testing and deployment is generally more intricate, and intra-service calls over the network can increase application latency. 

Kubernetes

Platforms like Kubernetes, can be utilized to implement microservices architecture. Kubernetes, an open-source container orchestration system, provides an API to control how and where containers run. This allows for effective management at scale. It helps tackle operating complexities when scaling multiple containers deployed across multiple servers.

Security concerns

Security concerns center on the way that these microservices tools are accessed, maintained and orchestrated in management. These technologies enable more code – in repositories or pre-built containers – yet, tend to come from lesser known origins with more rapid deployment on distributed systems. While images can be sourced from public registries such as DockerHub, enterprises often host their own images on their self-managed registries. Additionally, data traffic, network traffic and access to code complexity also increase.

Docker images

Security concerns regarding Docker images center upon verification of origin and integrity particularly when images are hosted on a public registry, like DockerHub. Snyk, a company which helps developers secure use of open source code, published its report, Shifting Container Security Left, showing that the top 10 official container images on the registry contain at least 30 vulnerabilities. Even of the top 10 most popular free Docker-certified images, 50% have known vulnerabilities. Fortunately, the Docker content trust, launched in August 2019, helps mitigate concerns regarding verifying origin and integrity. As noted, enterprises can host their own images to ensure more security, though this contrasts the open-source mindset.

In addition to containers with unsecure images, other common security vulnerabilities include:

• Unrestricted communication between containers: Kubernetes helps address this significant challenge for enterprises using microservices, by adopting networking policies which helps DevOps teams limit communications between containers. However, Kubernetes also brings additional security challenges (discussed below).
• Improperly isolated containers:  Improper isolation from the host can lead to host attacks. Since containers differ from virtual machines (where hypervisors provide control over host access), users may be able to escape the container and access to the host. Security practices like hardening your kernel, and not running containers as root help mitigate such threats. Using open-source kata containers, which feel and perform like containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense, can be another solution.

Clashing mindsets: Speed vs. Security

The common developer mindset in which development speed clashes with the code security compounds the problems above. According to Forbes, 80% of developers do not test images before deployment.

A company’s development department is not the only which includes mindsets that need remediating, security teams also need to improve. Newly popular open-source technologies bring inputs that traditional security teams lack the equipment to manage. In fact, Snyk’s report indicates problems with ownership — 68% of security teams believe developers should be responsible for owning container security.

Orchestration and Kubernetes

Even with mitigating vulnerability concerns relating to containers, implementation and orchestration can bring security threats. Referencing the popular container orchestration platform Kubernetes again, 46% of organizations accept traffic to Kubernetes pods from any source (according to Unit 42 threat research). In on-premise, this compares to deploying a server and then leaving it open to “any”’ on the internet. Since, few, if any would do this it’s remarkable that nearly half would do it on a public cloud.

Solutions

1. Developing a DevSecOps mindset

Aligning with its very nature, developers approach projects with a security mindset in DevSecOps. The solve for security issues while continuing to achieve speed and deployment. Although it may be difficult to change ingrained ways of thinking, practices do exist to help:

2. Security testing

Security testing, an integral part of the DevSecOps lifecycle, is detailed as follows:

• Developers produce code and then commit the changes to version control management systems such as GitHub Enterprise, Atlassian Bitbucket, or GitLab.
• Another developer performs a code review of the newly committed code. Static code analysis tools that look for common programming flaws and security vulnerabilities may help.
• The application is deployed to a testing environment and security configurations are applied. Test suites run against the various aspects of the application, including security, back-end and UI (user interface).

Upon successful completion of these steps, code can be deployed to production environments as needed while continuously looking out for security threats. This iterative workflow makes DevSecOps easily integrable with Agile processes, allowing development teams to fix security issues. Addressing security issues through this framework also saves time, money, and resources that could be expended elsewhere.

3. Other DevSecOps best practices

More broadly, DevSecOps is contingent on a few key practices. These include: 

• Recommend/provide tools to integrate into CI/CD (continuous integration/continuous delivery) pipeline and workflow.
• Increase developer knowledge building, particularly around security.
• Automation early and often through the SDLC. This saves time, money and reduces friction between security and development teams.

4. Static analysis security testing and code review suites

Static analysis security testing (SAST) through linting tools can benefit DevSecOps. Code review suites, which combine many linting tools, can be even better. 

While configuring and integrating linting tools into the CI/CD pipeline is key, it also presents challenges that lead to delays and inefficiencies, managing and maintaining multiple tools. Additionally, running several linting tools on a large codebase can delay development and sometimes break the build due to non-compliance (for more on using multiple individual linting tools, see our blog on the Drawbacks of Linters).

Code review suites 

Code review suites, which integrate numerous linting tools on one platform, helps mitigate such challenges. Teams do not need to worry about configuring and maintaining individual linting tools using these.

Codacy

For instance, Codacy provides a wide variety of linting tools to support 31 programming languages. This includes many in which it provides extensive rules for security checks. While performing automation, a key practice above, it checks for vulnerabilities, particularly in the OWASP Top 10.  

In addition, with Codacy, security checks are done early in the development process to help prevent issues’ impact later.  It performs code analysis when developers review new pull requests, rather than in the CI/CD pipeline. Also, any linting rules can be easily enabled or disabled with a click of a button through the dashboard, rather than diving into the configuration files and creating new headaches.

Please feel free to try Codacy out as you start incorporating DevSecOps practices.