Threat Stack has embraced containers as a mechanism for distributing the agent software it relies on to monitoring IT environment for security threats.
Chris Ford, vice president of product for Threat Stack, says usage of containers to distribute agent software across multiple platform will not only advance DevSecOps processes, but also lead to better overall security because updating agents will be easier.
That capability will also enable IT organizations that have embraced Kubernetes clusters to make use of Kubernetes DaemonSets to automatically deploy Threat Stack agent software, adds Ford. By deploying its agent software as a container Threat Stack also provides more granular visibility into both containerized applications and the hosts they are deployed on.
The Threat Stack Cloud Security Platform monitors infrastructure to identify potential security incident based on patterns of risky behavior occurring across the organization. Via its agent software, the Threat Stack Cloud Security Platform is capable of automatically detecting any changes made to an IT environment. As an extension of that capability, Threat Stack also makes available a Threat Stack Cloud SecOps Program service to provide organizations with additional DevSecOps expertise.
In general, Ford says it’s not practical to bolt on security at runtime in container environments. The ephemeral nature of containers requires an approach were agent software can be just as rapidly deployed alongside the containers they need to monitor.
The debate over which approach to container security is best these days is running hot and heavy. A raft of startups focused on securing cloud-native applications have already emerged. At the same time, there is a considerable number of legacy IT security vendors that are extending their reach into the realm of containers. The latter companies tend to make a case for a single pane of glass to manage security everywhere, while startups argue that the unique attributes of containers and serverless computing frameworks require a dedicated container security platform. The one thing that all vendors appear to agree on this that containers surface up richer metadata that make it possible to craft more granular security policies.
Given the rate at which developers are now deploying and updating applications, there’s naturally a lot that can go wrong from a cybersecurity perspective. It’s doesn’t take much, for example, for a developer to accidentally include an outdated version of a library with known vulnerabilities in a container. It’s also possible to discover that longer-running containers contain a library of software in which a new vulnerability has been discovered.
Regardless of the root cause, the good news is that processes associated with remediating those vulnerabilities within the context of a containerized application are a lot faster when compared to what’s involved in patching legacy applications. The challenge is discovering where any vulnerability might lie across potentially thousands of containers.
In theory at least, the shifting left of responsibility for building more secure code on the shoulders of developers should lead to better quality applications. But as long as humans are involved in building code, the opportunity for mistakes is going to be ever present.