There is a security aspect to such things, though, as how do you know the content is from a trusted source? That is the bugaboo with multicast. It needs to be information that isn't going to hurt anything if it is bogus. Also, it opens up a DoS possibility with noise traffic sent to the multicast group.
SSM with encryption?
Well, certainly, but source address can be very easily spoofed with a UDP multicast stream. Now that could be mitigated with a lot of network configuration rules but something is needed that just works without all that. So using multicast for things like software updates to computers over the general internet to the general public probably isn't going to work. Encryption is also an issue because it doesn't really work well over multicast. How do I encrypt something in a way that anyone can decrypt but nobody can duplicate? If I have a separate stream per user, that is easy. If I have one stream for all users, that is harder. The answer is probably in some sort of digital signature but not really encryption. Using public/private key encryption over multicast, I would have to distribute the private key so others could decrypt the content. If they have the private key, they can generate a public key to use to generate content. Encryption is probably overkill anyway. What is needed is a mechanism simply to say that the content is certified to have come from the source it claims to come from. So ... basically ... better not to use multicast for anything you really might have any security issues with. Fine for broadcasting a video, not so fine for a kernel update.