Opinions expressed by Digital Journal contributors are their own.
The application of development, security, and operations (DevSecOps) practices has gradually shifted earlier in development lifecycles in an attempt to minimize the need for downstream software fixes. As a result, DevSecOps teams have begun implementing proactive technologies like secure container images to better protect software applications and the IT infrastructure that hosts them.
Why cybersecurity practices need to change
Until roughly 10 years ago, software development teams released updates for their applications only once or twice a year, meaning security teams could wait until the end of the development cycle to look for and address issues without worrying about timeframes.
Advancements in software development necessitated changes to how security teams handled their tasks, with IBM noting that “as software developers adopted Agile and DevOps practices, aiming to reduce software development cycles to weeks or even days, the traditional ‘tacked-on’ approach to security created an unacceptable bottleneck.” The need for faster response times eventually led DevOps teams to incorporate security practices to address security issues as they emerged.
Fixing problems before they worsen is an important part of DevSecOps because security flaws are typically easier, faster, and less expensive to fix the sooner they’re identified and addressed. The added bonus of integrating security into DevOps is that it enables automated delivery of secure software without compromising the development cycle’s speed. This particular aspect of DevSecOps has become an important part of securing containers and container images.
What are containers in software development?
Explaining how DevSecOps teams secure containers and container images is little more than words without first understanding what those items are, so it’s worth briefly covering them and their functions.
For context, recall that applications are the interfaces through which people can use services and perform actions. To function as intended, applications need access to their dependencies and libraries, but this information isn’t always bound within the applications themselves. It should also be noted that applications typically require data from their users to function, but the act of transferring that data from a user to the app itself leaves it vulnerable to theft.
Containers address both storage and security issues by providing a single location where an application and all the files it needs to run can be stored, creating a self-contained entity that can be run consistently wherever it needs to work. To keep their contents safe from tampering, containers typically include security settings that let users customize security measures such as access controls and capabilities.
Manually creating containers for every application a team builds would be tedious, so IT teams use container images to streamline the process. Container images serve as static, unchanging templates for containers that deliver applications in cloud-native environments. Since the base image is the foundation for all subsequent images, container security focuses primarily on ensuring this image isn’t tampered with.
Securing container images
The actual practice of securing container images spans the entire software development lifecycle, from planning through maintenance. Each step in this cycle requires its own set of processes and practices, but these generally fall into four categories: reduction, restriction, and supervision.
Container security usually starts by minimizing the number of items that need to be secured. As a rule, the more files a team has to keep track of, the more likely they are to miss vulnerabilities, so it’s good practice to keep container images as slim as possible. After reducing the available surface area for vulnerabilities to appear comes managing container access.
One of the most common sources of container vulnerabilities comes from mismanaged permissions. If the wrong people are granted more authority to access a container than intended, they can tamper with it if they choose.
To address this issue, DevSecOps teams implement the principle of least privilege, which states that containers should be granted only the permissions they need to operate. These teams also verify that container base images come only from approved sources to ensure they don’t contain vulnerabilities of their own.
Another important part of maintaining container security is regularly scanning containers and their environments via supply chains to identify and address vulnerabilities before they can become significant problems. This process greatly benefits from automated programs that can run routine scans and report issues independently.
In practice, this might look like a DevSecOps team improving a continuous integration/continuous deployment (CI/CD) pipeline. They use automated security checks to quickly spot potential problems that could disrupt their workflows.
The benefits of pragmatism
Although security teams might once have gotten away with treating security as an afterthought rather than a core feature of the development process, today that is no longer the case. As consumer demand for faster software release cycles increases, DevSecOps teams cannot afford to wait for security issues to find them.
Pragmatism is becoming the rule, not the exception, for successful security measures, and in many instances, that starts with ensuring a DevOps team’s container images are safe and secure enough to remain so.
