Developers are increasingly turning to containers to make building, testing, and running applications across a variety of environments faster and more efficient. As containers have grown in popularity, so too has the understanding that we need to find solutions to keeping the code within them secure from vulnerabilities.
According to Forrester’s latest survey on the state of container usage, security is cited as the biggest barrier to container adoption by organizations. However, if developers hope to keep pace with the industry, containers are a must have, making finding solutions for keeping them secure a top priority.
One of the most significant challenges that development teams face when it comes to security is overcoming the lack of visibility of the code within.
Lacking the full picture – missing dependencies
Developers love working with containers because they are lightweight units known for their efficiency and speed of movement. They answer to modern day agile work environments and the ever-shortening times to market. The downside of their compact size, often measuring only tens of megabytes, is the loss of some of the most important bits that tell us the story behind our applications.
To achieve their lightness, containers mandate a strict cut-off point for all application dependencies. When dependencies are cut off from the components that go into the container, they cannot be retracted and the ability to track them to their source component is lost forever. Think about it like a plant being uprooted. Good luck guessing which flower came from which set of roots.
These dependencies are important for security concerns, particularly as they pertain to identifying components with known vulnerabilities which are the primary threat to open source usage.
SEE ALSO: When monitoring containers, machine data is essential
The issue with open source dependencies
Open source components, built on a chain of dependencies and linkages with open source libraries, are interconnected to one another in “invisible” ways only accessible with the help of Software Composition Analysis tools (SCA) that automatically and continuously track these connections.
Developers rely on dependency management tools like Maven (Java), Bower (JavaScript), or Bundler (Ruby) that pull in third-party dependencies automatically, further increasing the invisible net of open source dependencies that are likely to go unnoticed.
Unlike in non-containerized environments where all dependencies, direct and transitive, remain attached to one another by default, in containerized environments transient dependencies are chopped off to conserve space.
When vulnerabilities are detected in the dependencies that were cut off, there is no possibility to trace them back to the component – now containerized – which they affect. The result is a contaminated container, with a known vulnerability in it, with no way to locate the vulnerability in the containerized environment. Without the ability to identify the libraries in those dependencies, known vulnerabilities which would otherwise be flagged may make their way into the containerized application.
If you think a vulnerable container is headache enough, think again
As opposed to VMs that operate as isolated units fully equipped with their own operating systems, containers are still essentially applications running on the same OS and therefore are affected by each other.
This connectivity, as Forrester’s 2017 report cites, raises the stakes for users that have multiple containers running as a vulnerable container with as little as a single exploited kernel may affect all containers related to it. Security teams should be cognizant of how the lack of visibility into one container can have a domino effect on the security of all other containers in its orbit.
SEE ALSO: Containers: Big opportunity or big distraction?
Vulnerability management in the build stage
The answer to open source security concerns is early detection. Checking for open source vulnerabilities in all stages of the SDLC and picking up on them during the build stage allows for timely remediation and eliminates costly post-deployment tear and replace ops.
This approach is doubly true for container usage particularly because of the structure of containers and the security limitations that inform containerized spaces. In this environment, it is about taking inventory of the open source components in your container in build time, pre-packaging, pre-bundling, and of course pre-cutting off of dependencies.
If you’ve gotten to production and still haven’t checked your container for vulnerabilities – you’ve gone too far.
The post For security hygiene, scan your containers in build time appeared first on JAXenter.
Source : JAXenter
