The most effective and proactive way of controlling that security risk is by finding and removing vulnerabilities in base images.
Containers provide an effective way to deliver a compact, portable environment for running applications across shared server resources. But enterprises are advised to take precautions before embracing this approach to operating-system-level virtualization.
Security risks unique to container technology can be exploited in a number of ways. Breaches can quickly spread from the shared server kernel to a collection of containers residing on a server.
Untrusted code can take advantage of vulnerabilities in a system and—in the worst case scenario—expose private, sensitive information to hackers. Enterprises that are subject to regulatory mandates cannot afford security liabilities and the potential penalties, including financial losses and loss of customer trust, that arise from attacks on data integrity.
Planning, vigilance and developing an effective solution
Contending with the unique security risks of containers requires planning, vigilance, and an effective solution designed to reduce risk. The challenge is on two levels:
• Identifying untrusted code that could compromise container use
• Remediation to correct detected vulnerability issues
Containers go “bad” everyday, and often without warning. All it takes is one CVE impacting an image, and now all containers deployed using this image are at an increased level of risk of compromise. As the use of containers becomes a standard practice, existing software development and security methodologies will need to better support developing, running, and managing applications made possible by containerisation.
With the increased use of open source code in enterprise-scale applications, the repositories that serve to provide code to development teams building container images are only secure if they can be trusted.
Files and images from repositories need to be treated with the same caution given to random downloads from the Internet: you should treat every download as though someone could have embedded malicious ingredients into the code.
For all its virtues, containerisation doesn’t overcome the need for application security. And since a substantial element of most application software is open source code, organisations need to have processes in place to ensure any vulnerabilities in open source, including in containers, are patched as soon as fixes are published.
When you’re using commercial software, the vendor is responsible for deployment guidance, security vulnerability notification, and solutions for disclosed vulnerabilities. If you’re using open source software, those responsibilities shift. When Black Duck analysed audits of over 1,000 commercial applications we found the average application included 147 unique open source components. Tracking down the fork, version, and project stability for each component is a monumental task for development teams.
The security risks associated with containerised software delivery has become a hot topic in the DevOps community, where Operations teams are under pressure to identify security vulnerabilities in their production environments. But it can be difficult for organisations to see the components and dependencies in all their container images, a task made more challenging when security governance is factored in.
One important operational difference due to the nature of containers is that vulnerabilities identified within containerised applications aren’t patched using traditional patch management processes.
Instead, patches to container images are made by rebuilding the Docker image, and then replacing the existing running containers with the updated image. This paradigm shift often requires enterprises to both reassess their patching processes and continuous monitoring requirements.
Managing container infrastructure in a production environment becomes even more challenging due to the scale of deployment. One of the biggest problems is trust—specifically trust of the application. That is, can you trust that all containers in your Kubernetes or OpenShift cluster are performing the tasks you expect?
The need to maintain visibility into open source components
Given the level of adoption of open source technologies in container infrastructure, a key to protecting your applications in production is maintaining visibility into your open source components and proactively patching vulnerabilities as they are disclosed. If you assume from the outset your containers will be compromised, you can make it much harder to mount an attack from a compromised container.
Key questions operations teams need to answer in order to minimise risk include:
• What security risks might be present in base images used for your applications, and how often are those images updated?
• If a patch is issued for a base image, what is the risk associated with consuming the patch?
• How many versions behind can a project or component be before it becomes too risky to consume?
• How quickly will ‘I’ be informed of component updates for dependencies which directly impact my containers?
• Given the structure of a component or project, do malicious actors have an easy way to gain an advantage?
Secure against known vulnerabilities
Containers should be monitored continuously because new security vulnerabilities are being discovered every day. In fact, the National Vulnerability Database has documented more than 13,400 vulnerabilities this year, more than double logged in 2016. When your operations team has hundreds or thousands of containers running at the same time, finding and remediating every newly discovered vulnerability in each container is a significant challenge.
An image created with fully up-to-date components may be free of known vulnerabilities for days or weeks after its creation, but at some time vulnerabilities will be discovered in one or more image components, and thus the image will no longer be up-to-date. To ensure containers are secure from newly reported vulnerabilities, organisations should utilize a container-native security solution that can monitor the container environment and provide precise detection of anomalous and malicious activity within it.
Every organisation is different and must ensure their approach to container security scales to their containerised environment. It only takes one vulnerable container out of thousands to cause a breach, which is why organisations need visibility into every container image simultaneously. Tools alone are not enough – your organisation must also have people to manage those vulnerabilities. Tools scale, but people don’t.
Make sure that you are proactive about container security. While containers speed software delivery, it’s irresponsible to ignore the new risks they post to application security. The most effective way of controlling the security risk associated with vulnerabilities in containers is by finding and removing vulnerabilities in base images.
The volume both of newly disclosed vulnerabilities and containers deployed in production environments requires the use of a dedicated container security solution capable of preventing, detecting, and responding to threats directed at containers.
Adopt container-specific vulnerability management tools
You can’t rely on traditional security tools that aren’t designed to manage the security risks associated with hundreds—or thousands—of container images. Periodic infrastructure security scans don’t account for the pace of container application development, nor do they account for the rate of security disclosures. Organisations need to adopt container-specific vulnerability management tools and processes to minimise the potential for compromise.
Containers help speed software delivery, but they also pose new risks to application security. . Deploy and use a dedicated container security solution focused on preventing, detecting, and responding to threats specifically aimed at containers.
This article originally appeared on Information Age.