Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS) Information

openeox.org

Post reply on HN
Print view View original

11–18 of 18 posts

Re: OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS) Information

#11

Post by repelsteeltje »

Arnavion wrote: post #7
repelsteeltje wrote: post #6

I think it will take a while for people to realize this effort looked great, but wasn't the right approach. Or no silver bullet, at least. The presentation with a simple diagram that combines this data with an sbom to yield "information" gives me navel gazing vibes of UML being the future of coding . Just as architecture didn't equate to well designed and maintainable software, I fear this initiative won't fix horrib…

It doesn't force someone who already wasn't checking their dependencies for CVEs / maintained-ness to start doing that. It does make someone who *was* doing that be able to show they're doing that in some standard way. In other words it doesn't force you to add an SBOM + EOX checker step to your CI pipeline. But if your compliance auditor wants you to check your dependencies, adding such a standardized step makes it…

I'm basing this mostly off first hand and anecdotal evidence - but through the years I've found that the major contribution of audits lies in having to think about the checkboxes every now and then. And what they mean in the context of my organization or project.

Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements.

That is to say that if this leads to more efficiency and makes it easier for compliance audits and such, I fear is stream lining the least impactful part of its goals.

Re: OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS) Information

#12

Post by Arnavion »

T3OU-736 wrote: post #9

Htm. So, how does this compare, and/or is different from https://endoflife.date ?

The standard is for software to report its own EOL / EOS status. The website you linked is the opposite direction - it's aggregating that status for a certain set of software.

Re: OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS) Information

#13

Post by hiatus »

repelsteeltje wrote: post #11
Arnavion wrote: post #7

Earlier quoted context omitted.

It doesn't force someone who already wasn't checking their dependencies for CVEs / maintained-ness to start doing that. It does make someone who *was* doing that be able to show they're doing that in some standard way. In other words it doesn't force you to add an SBOM + EOX checker step to your CI pipeline. But if your compliance auditor wants you to check your dependencies, adding such a standardized step makes it…

I'm basing this mostly off first hand and anecdotal evidence - but through the years I've found that the major contribution of audits lies in having to think about the checkboxes every now and then. And what they mean in the context of my organization or project. Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements.…

> Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements.

I am confused when I hear people say stuff like this. I guess if you turn on a tool and never look at it again, it won't result in material improvements. But complying with regulations or a particular compliance regime should _absolutely_ result in at least _some_ material improvement to your security posture. Like you can implement segregation of duties just as a checkbox, or use the requirement to revisit the way you gate changes to production, as just one example.

Re: OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS) Information

#14

Post by T3OU-736 »

Arnavion wrote: post #12
T3OU-736 wrote: post #9

Htm. So, how does this compare, and/or is different from https://endoflife.date ?

The standard is for software to report its own EOL / EOS status. The website you linked is the opposite direction - it's aggregating that status for a certain set of software.

Aha. Very good point. SW self-reporting requires buy-in, though, which seems like a pretty high barrier.

I am very much hoping the effort succeeds, but I am also mindful of the fact that the site to which I have linked is more successful by virtue of having better coverage.

Re: OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS) Information

#16

Post by genter »

Hackbraten wrote: post #15

That EoX logo though. Every organization or committee that designs a logo should be legally required to have at least one teenager on the board to prevent accidental goatse or other inadvertent blunders.

Goatse has been around long enough that the teenagers are now in their thirties.

Re: OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS) Information

#17

Post by captn3m0 »

T3OU-736 wrote: post #14
Arnavion wrote: post #12

Earlier quoted context omitted.

The standard is for software to report its own EOL / EOS status. The website you linked is the opposite direction - it's aggregating that status for a certain set of software.

Aha. Very good point. SW self-reporting requires buy-in, though, which seems like a pretty high barrier. I am very much hoping the effort succeeds, but I am also mindful of the fact that the site to which I have linked is more successful by virtue of having better coverage.

We (endoflife.date) are also excited about OpenEoX.

Re: OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS) Information

#18

Post by repelsteeltje »

hiatus wrote: post #13
repelsteeltje wrote: post #11

Earlier quoted context omitted.

I'm basing this mostly off first hand and anecdotal evidence - but through the years I've found that the major contribution of audits lies in having to think about the checkboxes every now and then. And what they mean in the context of my organization or project. Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements.…

> Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements. I am confused when I hear people say stuff like this. I guess if you turn on a tool and never look at it again, it won't result in material improvements. But complying with regulations or a particular compliance regime should _absolutely_ result in at least _som…

It depends on where you're coming from. Your code base, that is.

If it's already outstanding, you spend a lot of time revalidating what you already know and it's often a noisy process with many false positives.

If it's in a horrible state, however, the regulation often leaves a lot of wiggle room where you do some work to achieve, say, PCI compliance and then spend a lot of time arguing why this and that don't apply in your specific case.

So admitted, the is probably some improvement in the latter case but it's hardly proportional.

So IMHO, it doesn't help those of good will & expertise and does too little for the negligent. It adds noise and in the end quality still depends on factors other than compliance and certification.

Post reply on HN