Today I received two security-related enquiries. One concerned a vulnerability in software we don’t even use. The other concerned a decade-old SSH library that someone was apparently considering deploying into a modern product. Guess which one worried me more.
It’s been one of those days.
We’ve spent a good part of today dealing with the fallout from PHP2Shell. Customers are understandably concerned, security teams are sending out questionnaires, and somewhere in the process our products have ended up on somebody’s list of things that need investigating.
There’s just one small problem.
Our software doesn’t use PHP.
Not a single line of it.
Nevertheless, we have to respond. We have to reassure customers, explain our technology stack, and confirm that the vulnerability doesn’t apply to us.
It’s frustrating, particularly when you’re running a software company and would rather spend your time actually developing software. But I understand it. Someone has identified a potentially serious security issue, and organisations are trying to establish their exposure.
Fair enough.
Then another email arrived.
And suddenly, answering questions about PHP didn’t seem quite so irritating.
A licence problem. Apparently.
The second email came from a company considering using an old version of our Maverick SSH library.
Specifically, version 1.5.5 of J2SSH Maverick, a release from roughly a decade ago.
Their automated licence scanner had flagged the library as GPL-licensed. On closer inspection, they’d discovered that the Maven POM declared GPL while the source headers and repository indicated LGPL.
A perfectly legitimate discrepancy.
They’d done their homework, too. They’d inspected the published sources, checked GitHub, examined the POM metadata and established that the binary didn’t contain a separate licence file.
They wanted us to confirm the correct licence, fix the Maven metadata and potentially publish an updated binary containing the licence text.
All very thorough.
Except I found myself staring at the email, wondering why nobody appeared to have asked the most obvious question.
Why are you considering introducing a decade-old SSH library into your software in 2026?
The things that happened in the meantime
Ten years is an extraordinarily long time in security software.
Consider Terrapin, the SSH protocol vulnerability disclosed in 2023. It exposed weaknesses in how certain SSH encryption modes handled sequence numbers and allowed attackers in suitable circumstances to manipulate the initial encrypted handshake.
Mitigating it required changes to SSH implementations and, in particular, support for strict key exchange.
A library released years before the vulnerability was discovered cannot simply be assumed to have those protections.
Then there are dependencies.
Anyone who lived through Log4Shell will remember the frantic scramble to establish which products included vulnerable versions of Log4j, directly or indirectly. A library doesn’t have to contain the vulnerable code itself to introduce security exposure through its dependency tree.
I’m not suggesting that this particular Maverick release necessarily contains a vulnerable Log4j dependency. That requires examination of the actual software and how it’s deployed.
But that’s precisely the point.
Where is that examination?
What cryptographic algorithms does the library support? Which are enabled by default? What vulnerabilities have been discovered since its release? What dependencies does it bring into the application? Who is responsible for maintaining it when the next vulnerability emerges?
These aren’t obscure questions.
They’re the questions I would expect a security review to ask before approving an SSH implementation for use in a commercial product.
And yet the email wasn’t asking any of them.
It was asking us to fix an XML declaration.
When compliance becomes a substitute for judgement
To be clear, licence compliance matters.
Organisations need to understand the obligations attached to open-source software. GPL and LGPL are not interchangeable, and incorrect metadata can create genuine problems for automated compliance systems.
The scanner wasn’t wrong to flag the discrepancy.
In fact, it was doing exactly what it was designed to do.
But that’s also the problem with automated compliance. It can create an illusion of thoroughness.
A dependency gets scanned. A licence is identified. A vulnerability database is consulted. A report is generated. Someone works through the exceptions until the dashboard turns green.
And somewhere along the way, it’s possible to lose sight of what the exercise was supposed to achieve.
A scanner can tell you that a particular library has no known vulnerabilities recorded against its coordinates.
It cannot necessarily tell you that the library is secure.
It cannot tell you that its cryptographic implementation reflects current best practice, that its dependencies have been properly assessed, or that someone will maintain it when a new attack is discovered.
And it certainly cannot replace an experienced engineer looking at a ten-year-old SSH implementation and asking whether it’s an appropriate foundation for a new product.
Absence of a vulnerability report is not evidence of security.
Sometimes it just means nobody is looking anymore.
Software doesn’t become secure simply because it still works
There’s another misconception worth addressing.
Software doesn’t have to stop functioning to become obsolete.
An SSH library written ten years ago might still connect perfectly well to a modern server. It might authenticate users, transfer files and perform every operation its developers originally intended.
That doesn’t mean it’s suitable for a new deployment.
Security software exists in an environment that changes constantly. New attacks are discovered. Algorithms are deprecated. Protocol implementations are hardened. Expectations around authentication, key management and cryptographic configuration evolve.
The fact that an old library continues to function says very little about whether it continues to meet those expectations.
And if you’re incorporating that library into software used by your customers, you’re taking responsibility for those decisions.
Not the original open-source developer.
Not Maven Central.
Not the licence scanner.
You.
Two emails, two very different concerns
Which brings me back to today’s inbox.
On one hand, I have customers asking whether our software is affected by a PHP vulnerability, even though our products don’t use PHP.
It’s annoying. It consumes time. And yes, I occasionally wonder whether anyone has bothered to look at what our software actually does before sending the questionnaire.
But at least they’re asking about security.
They’re trying to establish whether the software they already depend upon exposes their organisation to risk.
On the other hand, I have a company apparently considering introducing a decade-old SSH implementation into its product, having conducted a remarkably detailed investigation into whether its licence metadata is correct.
Perhaps they’ve already performed a comprehensive security assessment. I certainly hope so.
But nothing in their enquiry suggested it.
And that is what concerns me.
We’ve built an entire industry around software compliance, vulnerability scanning, dependency inventories and automated security reports.
All useful tools.
But none of them absolves us of the responsibility to exercise engineering judgement.
Because ultimately, the question isn’t simply whether you’re legally entitled to use a piece of software.
It’s whether you should be using it at all.
And if I have to choose between spending my afternoon explaining why our Java software isn’t vulnerable to a PHP exploit, or explaining why someone shouldn’t build a new product around an obsolete SSH library, I’ll take the PHP questionnaires every time.
At least those people are worrying about the right thing.