It’s an interesting scenario, to report Compliance against a custom baseline rather than the actual source fixlets, or to manage large baselines for Linux patching.
These sound like several distinct issues.
“The Code is more what you’d call guidelines, than actual rules”. The idea that a baseline is limited to 100 components, or 250, or 500, is for the sake of evaluation time on the client. There’s a lot of variation there; one fixlet with huge / slow-evaluating relevance can have as much impact on the client as dozens of well-tuned fixlets. You didn’t say which Linux distributions you’re interested in, but for instance most of the Red Hat fixlets are based on RPM information, which is straightforward and cached on the client; the RPM queries perform really well, so it’s conceivable you could have much larger baselines without an issue. In contrast, many of the Windows fixlets are based on checking file metadata for dozens (or even hundreds) of files and don’t perform as well as queries against the RPM cache.
If it’s just for reporting purposes, you could add the “approved” fixlets to a very large baseline, but put the baseline in a site that doesn’t have any subscribed computers; then you could base your compliance on a query like
names of applicable computers of source fixlets of components of component groups of fixlets whose (baseline flag of it) of bes custom sites whose (name of it = "Site My Clients Do Not Evaluate")
(but you’d still have the problem of how to deliver those actions).
Aside from Baselines, you could use other methods to mark a Fixlet as “Approved”. Perhaps you’d create custom copies of them into a Custom Site, then you could take actions and report Compliance against all the fixlets in that site?
Or maybe Globally Hide the ones that are not approved (and you can make new fixlets gather as “Hidden by Default” in BESAdmin, so you un-hide them when you approve them in the Console)? I have not checked this but I’d expect that Patch Policy would ignore Globally Hidden fixlets. Test that, but even if Patch Policy doesn’t respect fixlet hiding, you could use the Console to Globally Hide / Un-Hide fixlets as you approve or reject them, and have your operators select “all the fixlets they can see that are relevant” for their actions, multi-action groups, or baselines; and report compliance based on the
bes fixlets whose (globally visible flag of it)
Do any of these seem worth further exploration? I can think of at least two other options, but they’d require some custom coding to track fixlet approvals as dashboard variables, or taking it out of the Console entirely and building an approval / orchestration using REST API (I know of at least a couple of customers who have done that, but our goal would really be to add the requisite features to WebUI so everyone benefits).