De-Dupe Patching Information

Content Authoring BigFix.me
1

(names of it, ids of it, source release date of it, source id of it, display name of site of it) of relevant fixlets whose ( (month_and_year of source release date of it = (month_and_year of current date - 35 * month)) and ( (display name of site of it as lowercase starts with "patches") or (display name of site of it as lowercase starts with "rhel") or (display name of site of it as lowercase starts with "enterprise")) ) of bes computer whose (id of it = 1)

will produce

	<Result>
		<Tuple>
			<Answer type="string">RHBA-2023:3333 - Httpd Bug Fix Update - Red Hat Enterprise Linux 7 (x86_64)</Answer>
			<Answer type="integer">23333301</Answer>
			<Answer type="string">Thu, 25 May 2023</Answer>
			<Answer type="string">RHBA-2023:3333</Answer>
			<Answer type="string">Patches for RHEL 7</Answer>
		</Tuple>
		<Tuple>
			<Answer type="string">RHBA-2023:3333 - Httpd Bug Fix Update - Red Hat Enterprise Linux 7 ELS (x86_64) (Superseded)</Answer>
			<Answer type="integer">23333301</Answer>
			<Answer type="string">Thu, 25 May 2023</Answer>
			<Answer type="string">RHBA-2023:3333</Answer>
			<Answer type="string">Patches for RHEL 7 Extended Support</Answer>
		</Tuple>
	</Result>

BUT

I need to return no values as I want to hide superseded patches and these are obviously both superseded as they have matching source ID's and at least one of them has Superseded in the name of the fixlet

I’ve spend way too much tie trying to work out how to fix this :frowning:

2

Is excluding fixlet with “superseded” in the name not an option? I’d have to assume that HCL do not supersede a fixlet that the vendor hasn’t, which may differ between the normal patch site and the extended support site even though they share the same ID? (or maybe its an honest oversight that needs to be corrected)

(names of it, ids of it, source release date of it, source id of it, display name of site of it) of relevant fixlets whose ((month_and_year of source release date of it = (month_and_year of current date - 35 * month)) and (name of it as lowercase does not contain "superseded") and ( (display name of site of it as lowercase starts with "patches") or (display name of site of it as lowercase starts with "rhel") or (display name of site of it as lowercase starts with "enterprise")) ) of bes computers

3

The problem is that it then returns

<Result>
	<Tuple>
		<Answer type="string">RHBA-2023:3333 - Httpd Bug Fix Update - Red Hat Enterprise Linux 7 (x86_64)</Answer>
		<Answer type="integer">23333301</Answer>
		<Answer type="string">Thu, 25 May 2023</Answer>
		<Answer type="string">RHBA-2023:3333</Answer>
		<Answer type="string">Patches for RHEL 7</Answer>
	</Tuple>
</Result>

That fixlet is superseded, it’s just not had it’s nae updated on the older RHEL 7 site as it’s no longer maintained and the fixlets that are have moved to ELS and are now updated

4

Yeah, I can see the issue which I guess is a bit of an edge case created when an OS goes EOL and onto an extended support model, though still a very real problem. Once the vendor stops providing updates unless an extended support license is procured, if the fixlet in the standard “patches for x” site was superseded, it could lead to an "security by obscurity" scenario.

I can't readily think of a way to tackle that purely via session relevance.

5

The one option can be used is (name of it as lowercase does not contain "superseded") but fixlet name itself does not contains superseded and hence it will anyways reflect in query. Another way is to is globally hide these contents and then use filter AND (globally visible flag of it")
Not sure if this can be helpful

6

Yeah I agree with @SLB on this one, I think it likely that RHBA-2023:3333 - Httpd Bug Fix Update - Red Hat Enterprise Linux 7 (x86_64) in Patches for RHEL 7 is probably not marked as Superseded, because the patch that Supersedes it is only published in the Extended Support site; and if a system is not entitled to Extended Support, then maybe this fixlet is the last version that it could install?

For my money, the "right" answer is to install either this fixlet, or the thing that supersedes it, so that there are no more relevant computers for it :slight_smile:

7

If only it were that easy :sweat_smile:

The problem is that I show outstanding patches in a mm/yyyy format on a custom tool ever built and this one (and a number of others) pops up for some systems.

The flow is show mm/yyyy where patches are outstanding then when the user clicks the date it opens a modal that shows the patches.

The business doesn’t want to install them just now so on the front end a de-dupe was added to the code that then shows only the extended patch (perfect) and there's a toggle to then hide superseded patches which then obviously hides the one named superseded but to see.

The issue then is that the modal opens and shows no patches but because the relevance runs before the modal loads with the code to hide and toggle, it makes it look like they have something outstanding to patch.

Hope this makes as much sense in writing as it does in my head :joy:

8

Hm.
I'm loading up more sites now, but... does the Patches for RHEL 7 EUS site contain everything from Patches for RHEL 7, or does EUS start where Patches for RHEL 7 ended?

I'm wondering whether there's a path to only subscribing systems to one site or the other, or putting "Include End-of-Life Software" behind an extra click or something like that.

9

It looks to me like the Patches for RHEL 7 EUS site includes everything from "Patches for RHEL 7" that was not superseded at the time RHEL 7 went Extended. So...I think probably any single machine should only be subscribed to the standard or to the Extended support site?

If that were the case, any machine subscribed to the EUS site should filter out the Superseded fixlet, and won't show the non-ESU fixlet because it's not subscribed to that site; and any machine that is not entitled for EUS support, should subscribe to the normal site, and should be flagged for that missing patch?

Incoming Rant

But also, I think this example brings up something that's a real danger in the way that things get reported in BigFix and is often overlooked.

If we ignore things that are Superseded (which is the default!), then we cannot tell how far out of compliance any given machine is. In most cases, any given patch will be superseded by another. When we ignore Superseded patches, once a new patch is released, we can only report that our machine is missing the newest patch; we cannot tell if our machine is one day behind, or three years behind, because everything between yesterday's patch and three years ago was superseded and ignored.

Here you're demonstrating a three-year-old patch, where you want to hide it from view because it's superseded and the user shouldn't install it, they should install the latest thing instead. A reasonable approach, from the viewpoint of least-effort for the user - they need not install this fixlet, they only need to install the latest version, and ignore the superseded things.

But, this ignores the fact that the user hasn't gotten around to installing this fixlet, or the things that superseded it earlier, for the last three years.

They didn't install 23333301 when it was released in May 2023.
They didn't install 24494301 that superseded it in July 2024.
They didn't install 24710101 that superseded that in September 2024.
They didn't install 25149971 that superseded that in September 2025.

At this point, you'd ask them to install 26007501 which was released in January 2026 and supersedes all of these previous ones; but if they wait a few more months you'll hide this one as well, and only tell them about the latest-and-greatest fixlet they're missing. In the meantime though, in the shortest display you'd show their system is missing a patch from January, not the patch that was released three years ago to which they're still vulnerable.

So, my advice would be -- handle with care. I think it's a really small edge case where, if the customer was keeping up with patching, there might be a small overlap where the same fixlet is relevant from both sites; that edge case goes away when they apply any of the superseding fixlets from the EUS site.

But if that edge case never goes away, because they aren't applying any of the patches, then put them on blast and show every missing thing they have.

When I look at compliance reporting, I turn on Superseded Evaluation so all the old fixlets show relevant, and report every one of them. Any external auditor would do the same.

But if you really, really want to not show the fixlet from the old site...just unsubscribe the computer from the site. Only leave them subscribed on the EUS site.

3 Likes
10

Just for the record, I completely agree with you! Every single bit of that “rant” is how I feel too and have voiced.

The RHEL 7 site contains some patches that were never moved over to the new EUS site which is why we have to keep both active BUT I think you've accidentally just solved the problem :sweat_smile:

If I change the RHEL7 site subscription relevance then I might be able to match source IDs from the EUS site and essentially make the RHEL7 site relevant only when there’s content available for the endpoint and then when there is compare the two source id's and again make it not relevant for the site if they match.

I’m not even sure it's possible to do that but if it is it might fix it.

11

It strikes me that what's desired is a venn diagram comprising:

  1. Patches that have not been installed.
  2. Licensing state of endpoints vs patches
  3. Latest available version of X package, within Y release stream.

IMO, BigFix (platform) is good at [1].

Regarding [2], I can't think of a way for BigFix (platform) to highlight a gap between machine lacking patches and the need for separate licensing (e.g. EUS).

For [3], IMO a "trust but verify" strategy applies, with something like Tenable or Qualsys providing an additional assessment. OTOH, maybe Compliance helps? (We don't have Compliance.)