Is it normal for sysadmins to own tickets on vulnerability reports?

>normal for sysadmins to own tickets on vulnerability reports Yes, quite normal/common. Security is a fundamental part of sysadmin's job/responsibilities. Really part of essentially everyone's job - but that's another topic. So, e.g. as part of my sysadmin(/DevOps) job/role, one place I worked not that long ago, we'd get these security/vulnerability reports - based upon some scans. They'd be like 10,000+ like worksheets - not exactly highly useful/actionable in that format. Yet I'm handed 'em and basically "deal with it". So, I wrote some programs ... mostly Perl - but whatever, Python or the like could probably do it too. So ingest all that data - IPs, severity, specific vulnerability details, etc., and greatly simplify it into highly useful actionable information. For all relevant IPs, added hostnames, simplified a lot of redundant verbiage, grouped hosts having matched sets of vulnerabilities giving single entry for each such grouping and containing the list of host and count of hosts impacted, had adjustable severity threshold to cut out the "noise", and turned it into a highly actionable summary report that would typically be between 6 and 25 rows of worksheet output, ranked by highest severity in a matched set of vulnerabilities, then within that sorted by number of hosts having that same set of matched vulnerabilities, and on down to whatever cutoff had been selected. This then gave us highly useful intelligent information both for overview of the situation and highly actionable, as we could target a specific set of vulnerabilities as a group, across and entire range of hosts (all having such) at once (or chop it down into smaller subsets thereof for operational reasons - e.g. don't reboot all 600 prod hosts at once to address the same kernel issue). So, yeah, all part of a day's work - pretty routine stuff as far as I'm concerned. Yeah, I'm not at all uncommonly the one who spots and reports vulnerabilities - creating tickets or the like, handles vulnerabilities and other security issues, makes security and other recommendations, implements fixes, much etc. Even taught sessions on security. E.g. one I've presented multiple times, I titled something like "security for developers from a sysadmin perspective" - not so much that developers don't pay attention to security, they (generally/hopefully) do ... but mostly tend to come at it from a different perspective, and often miss things that are quite relevant, or make mistakes or poor design decisions that could be much better handled - notably with some more attention to relevant OS considerations. And I'd oft give many examples of security problems that originated from development side, that could've been well avoided with some better knowledge and/or attention to relevant OS considerations. (developers are often mostly focused down within the code itself, and perhaps also thinking about common network and related exploits, and oft mostly or entirely overlook everything else that's rather to highly relevant to security).