Essentially, it all still applies. TBH I'm not clear on the unpatched security issues that OTRS upstream are referring to, but if they have CVEs (Common Vulnerabilities and Exposures reference number) then it's fairly easy to check whether the security issues have been patched in Debian or not. And if not, it should be possible to see why.

FWIW, I just searched the Debian Security tracker and can't see any open security issues against OTRS, so I would assume that they are all patched. FWIW, read more about the Debian security tracker here.

Debian Jessie (what v14.x is based on) is expected to receive backported security updates until April 2020.

With regards to OTRS version we'll have in the next major release (v15.0), I'm not sure what version it explicitly was at that point (when I posted before), but the link is still relevant, and that says that the version will be 5.0.16.

I am inclined to dispute the perspective presented by jojo as I know for a fact that at least on occasions the Debian Security Team DO develop their own security patches to backport fixes for security related issues in packaged software. Whether or not that directly relates to OTRS though, I'm not 100% clear.

The Debian Security team focus on "stable" (currently Debian Stretch, i.e. the basis of the upcoming v15.0) and "oldstable" (currently Debian Jessie, i.e. the basis of v14.x). Once "oldstable" support ends (12 mths after the release of a new "stable") the responsibility is handed to the LTS (Long Term Support) team, who continue the work. We have a close working relationship with the current Debian Project Leader, Chris Lamb. He is also part of the LTS team, so we get a fair bit of behind the scenes insight into Debian in general, including how things are done with regards to security.

Having said that, to be completely transparent, there is a possibility that there are unpatched security issues. All security issues that the Debian Security team (and/or LTS team) are aware of are triaged and on occasion they deem particular issues unimportant and/or low priority (for a range of possible reasons). These "unimportant" issues are still tracked, and often eventually fixed, but their priority is lowered and they are often released in batches (i.e. multiple "low level" and/or "unimportant" issues all patched at the same time). The importance of a security bug is considered in terms of how easy it is to leverage by an attacker, and how much damage could be done if it were. I.e. a bug which is easy to leverage (even if it doesn't do much damage), or a bug that is hard to use, but would produce devastating results, would generally both be classified as "serious".

It's also worthy of note that often the real issues with security vulnerabilities is not the individual issues themselves. But how they can be daisy chained by attackers. As a mythical example, an attacker may use a bug in OTRS to get access to Apache, then leverage a bug in Apache to gain access to the system, then leverage an OS level privilege exploit to gain access to your root user account. In many respects an OS such as Debian (who package everything) is in quite a unique position as they can consider the implications of how these different vulnerabilities could be used in conjunction. This also works back the other way too. I've seen multiple occasions where potential security issues in web apps have been mitigated by changes in webserver configuration (which are provided as auto-installed security updates in TurnKey).

Regardless, I have signed up for a user account over on the OTRS forums and will follow up with jojo. I'm particularly interested whether he has any specific information on any unpatched security issues in OTRS 3.3. If he can demonstrate that there are indeed any unpatched issues with concerning implications, we will certainly take it up direct with Debian, and would also consider switching to an upstream install (i.e. direct from OTRS) for v15.0. Unless there is a quick fix, we'd probably pull the current OTRS appliance too (until we have a fixed version), as well as developing documentation on how current users such as yourself could manually upgrade to an unaffected upstream version.

I'm not keen to do that if we don't have to though. Installing and maintaining servers with software installed from upstream is much more labour intensive both for us and for end users such as yourself. It also means that the risk of a particular server having unpatched security updates is much higher (especially when upstream release major versions that require significant changes). We try to release as often as we can, and always prioritise security issues (and pull appliances if there are known and unpatched issues). But we are not yet at a point where we can produce an updated appliance everytime upstream provides a new version. So IMO, as a general rule, using Debian packages is a much better end user experience and less work for us (so we can spend our limited resources doing other stuff).