There’s no mechanism for flagging an update from .org as being a security update or not. Updates are just updates, other than the version string there’s little to no additional meta information. Change logs might mention it, but this is assuming the changelog is accurate, or present at all.
Some plugins might follow semantic versioning, in which case you can use that to determine if it’s a hot-fix or not, but there’s no way to tell in code other than a manual whitelist.
But even if there was a security update flag, using it to conditionally install updates would be a very bad idea.
Security fixes can and regularly pose as normal updates.
By releasing a security update you advertise that there was a security exploit, giving hackers the opportunity to reverse engineer it via the fix and exploit users who haven’t updated yet. So it makes sense to sneak the fix in and then document it at a later date once users are mostly safe from it.
WP Core itself has done this in the past, usually waiting a day or two for auto-updaters to kick in before announcing it.
So always keep up to date. If you’re concerned a update may break things, then you need to employ a testing strategy. This could be a manual inspection on a local install, a staging environment, an automated test suite, etc. Or just update anyway. Most well written code built using the appropriate APIs and standards works just fine on updates