In the past several years AppSec agents have gotten a bad rep, perhaps rightfully so. Development teams worry that they will break their application, especially due to the fact these agents are installed after their app is deployed. Security professionals prefer the agentless route as well, mainly because AppSec agents are usually very complex to deploy, configure and manage.
Agentless solutions aim to solve this issue, promising security observability without installing any agents. However, when it comes to real-time visibility and actual attack prevention, agentless solutions tend to disappoint.
So what’s between agent and agentless? I’m glad you asked. In this article we will explore the good, the bad and the ugly of agent and agentless security solutions, and the new alternative that has emerged.
What do we use AppSec agents for?
Agent-based AppSec solutions leverage agents for several things. First, they use them to get real-time visibility into what workloads are doing. Using agents, you can get a more accurate picture of how your workloads function, with a high-fidelity view of the flow of data between your app, microservices and APIs.
Second, agents help detect posture issues relating to how workloads are configured, and are able to intercept and block malicious behaviors.
AppSec agents are also used at runtime to block attacks on the workload level, instead of protecting the app from the outside or on the cloud environment level.
Why most of us dislike AppSec agents
So with all these great benefits, why do most security and development professionals cringe to the sound of the word ‘agent’?
There are three main reasons for that. First, they’re hard to deploy. In order for agents to provide maximum results, you need to spend a lot of time getting them into the workloads and machines you want them to be running on. You also need to configure them until they are all working properly in your environment.
Second, they’re hard to manage. Making sure AppSec agents work properly for different environments and different platforms, and can communicate back to the server is no easy task.
And third, agents introduce a lot of overhead. AppSec agents can severely impact the performance of the workloads they’re installed in. This can often make things that worked well during development, staging and testing to not work the way we expect them to in production.
So why not go all agentless?
Considering all of the above, it’s obvious why the agentless trend is booming in the last few years.
What agentless means is that rather than deploying agents on workloads or machines that workloads are running on, companies use technologies offered by cloud providers and environment providers to get security telemetry, and use it to detect problems and scan machines, without actually installing agents on those machines.
While these types of solutions have their benefits, they introduce some challenges.
For one, these solutions depend entirely on the capabilities of the cloud environment. Some environments may provide rich telemetry, while others may be more spartan about that telemetry.
Second, we get near real time visibility (and that depends on what you call real time). Agentless scanning can take time, it can be slow and expensive, and therefore you might not detect things you would like to know about until minutes, hours or even days later.
Finally, and maybe most importantly, agentless scanning typically allows to detect problems, but it doesn’t really block those problems in real time, offering little to no prevention.
So what’s between agent and agentless?
So if agents are annoying and cumbersome, and agentless is limited and not prevention-focused, are there any other options?
A third option that has emerged is security libraries rather than agents. A security library is a module where we bake security into the application during its development. This means it’s not part of your deployment process, but rather a part of your code base. Therefore, all the deployment and management issues tend to go away.
Using security libraries instead of agents makes it really easy to infuse security in as part of the application, let it run when the application runs, scale where the application scales and work the way the application works.
It’s true that overhead can be an issue if we’re putting expensive, costly security activities into our applications. That’s why it’s important to choose a security library that’s really lightweight and designed to run in an application without severely impacting performance.
When going this route rather than an agent that is deployed later on, you get to test your application during staging and testing with that same security capability turned on, preventing any surprises later on in production.
