I fought hard about four years ago at a previous company to upgrade us from PHP 5 to 8 because I think 5 was going EOL or something like that (could be wrong about that now). Based on my experience in software, I have to imagine the vast majority of normal developers do not give a damn about security in being in security patch lifecycles on software.

▲

forgotaccount3 4 hours ago | parent | next [-]

> I have to imagine the vast majority of normal developers do not give a damn about security in being in security patch lifecycles on software.

I just don't think it's the developer's responsibility.

Depending on the size of the team of course, but the work that developer's do comes from someone else. Empower me to make decisions and I'll make them, but don't blame me for the choices other people make if you won't empower me.

▲

jjice 4 hours ago | parent | next [-]

I think I get where you're coming from. I've worked mostly on small teams (sub 30) so it's always been on us. The engineering leadership never prioritizes security unless it's something as big as the log4J stuff because it was on customers' minds.

That said, if they're software packages from something like Node or PyPI, I do think that it falls on the developer. If the point is that leadership needs to give devs the ability to act on that, that's very fair.

	▲	3 hours ago \| parent [-]
		[deleted]

▲

Terretta 2 hours ago | parent | prev | next [-]

Exactly. It's not the bricklayer's responsibility when mortar fails. It's the person who specified that mortar.

So I'd agree it isn't not a coder or developer's responsibility when they're given a bill of materials and told how to build, but it is an engineer's responsibility. Comp should recognize that as well.

▲

expedition32 3 hours ago | parent | prev [-]

That's the problem with the tech industry. Nobody gives a fuck.

When a doctor makes a mistake they get to practice medicine in Peru for the rest of their life.

▲

Cthulhu_ 4 hours ago | parent | prev | next [-]

I've worked at a company that delivered on-premise software, and the runners of said software were... risk-averse, but in a strange way in that they didn't really want to upgrade software if it didn't need to. So the software was stuck on PHP 5.something, also because newer versions required a RHEL update which they also didn't like to do.

▲

4 hours ago | parent | prev [-]

[deleted]