Using open source code makes it easier to build applications, but the freely available nature of open source code introduces the risk of pulling potential security vulnerabilities into your environment. Knowing whether or not customers are actually accessing the vulnerable parts of your application is key to triaging security threats without spending hours fixing an issue that doesn’t affect end users.

Teleport 4.4 is here! The major innovation we’re introducing in this version is much improved control over interactive sessions for SSH and Kubernetes protocols. We’ll do a deeper dive into session control later, but for those who aren’t familiar with it, Teleport is an open source project. It provides access to SSH servers and Kubernetes clusters on any infrastructure, on any cloud, or any IoT device, anywhere, even behind NAT.

A SSH session can be interactive or non-interactive. The session starts when a computer or human connects to a node using SSH. SSH sessions can be established using public/private key cryptography or can use short lived SSH Certificates, similar to how Teleport works. Organizations often want to know who is accessing the systems and provide a greater level of control over who and when people are accessing them, which is where Teleport 4.4 comes into play.

“Version control” sounds a bit like something used by people scattered around the country trying to collaborate on a story. But it’s a crucial part of software development, especially in the DevSecOps era, where you need to ensure that the speed of the CI/CD pipeline doesn’t outrun quality and security. That’s because software development isn’t like an assembly line where a product moves from one group of workers to the next in a perfectly coordinated sequence.

As the number of known vulnerabilities continues to grow every year, software development and application security teams are increasingly relying on vulnerability detection tools throughout development. The result: teams are often overwhelmed with a steady stream of security alerts that must be addressed, and it’s becoming clear that it’s impossible to attempt to fix everything.

Kubernetes has some impressive baked-in role based access controls (RBAC). These controls allow administrators to define nuanced permissions when querying Kubernetes resources, like Pods, Deployments, ReplicaSets, etc. For those familiar with Kubernetes, the value of RBAC is immediately recognizable. A single Kubernetes cluster can contain your organization’s entire CI/CD pipeline, highly available SaaS products, or infrastructure that is in the process of being moved to the cloud.