Instead of dealing with this thing, I suggest looking at some existing system management tools like Landscape for Ubuntu or Spacewalk for CentOS/RHEL to handle managed updates... or learning how to set up a cron job to email you when security updates are available.
Really "agentless" is all a lie. The "agent" in most cases is usually sshd and you can really do better.
Also for this kind of software it makes sense to simply leverage the underlying configuration management system the admin is using. If they're using chef/puppet/cfengine they push out the client over the top of an agent-based protocol. If they're using ansible or salt they'll deploy it "agentless"-ly.
They've actually done more work to support this root-trust remote management model when they could have simplified the problem domain to just running their code (as an agent) and reporting on the one host its running on.
It seems to have been developed to tick off a buzzword ("agentless") which could have been avoided altogether.
I appreciate tools like this because they are single purpose and can be easily be retrofitted to old systems.
Also, yum security plugin does not work on centos because security errata are not published in repo. So you have to hack it even with spacewalk.
This tool definitely meets a need in the EL ecosystem.