0

For a project that's going to live/used/maintained by the developer for a very long time (ex: 20-50 year); Is custom (self made) framework better than (open source) popular frameworks? Basically my highest priority requirement is security and very long term lifetime.

My current situation is having to maintain 15 year-ish old web application written in PHP5 (at the time, it was a cutting edge application since PHP5 released at July 2004. The application used custom, closed-source framework (since I imagine at that time there's yet any popular or mature frameworks yet)

The application have served the organization for long time, and it's rather business critical. I'm trying to make a new mobile friendly version of it (to run alongside the old one). Should I use the same framework, or should I use newer frameworks like symfony or laravel?

[A] When I read the source code of the old framework, I realized that there's a lot of demerit:

  • a lot of it didn't follow some of OWASP best practices (I can't say which ones);
  • no automated test, no documentation (every time we need to change something, we're reverse engineering it and hope things didn't break);
  • a lot of bad PHP programming practice in general (variable name upper\lower-casing, drowning in warnings, gigantic monolith, no null safety, very loosely typed, no error logging, not using abstraction layer, basically going against every PSR that exist out there)
  • basically a very huge technical debt

[B] Even so, the consideration of keep using our old, custom, closed-source framework is that:

  • it's more secure
    • security through obscurity (only us know the source code, unlike open source frameworks which their code are basically 'leaked' through the internet),
    • AND security through very strict network firewall rules,
    • AND security through enforced legal and organizational law);
  • more understandable by the team (us);
  • PHP5 will still run on servers;
  • it's lifetime is forever (since the team: us; still maintain it and patch security vulnerabilities), - it will never get deprecated, never get breaking changes; I know that symfony provide LTS release that receive maintenance for 4 years. But it's still very-very short in term of the application's lifetime (our team expect 20-50 year);
  • it's receiving very huge amount of request every day, no framework (less footprint/resource usage); even if I try to change to new framework and follow every best practice out there, it'll be bad practices again after 20-50 year
  • our requirements doesn't mind if the app appears old (in html/css presentation); that's not where our customer find us

My question is:

  • should I propose for a change of framework and design?
  • is there any of my point in [A] or [B] that is wrong or misguided?

Related question (but quite different): https://stackoverflow.com/questions/1836351/thoughts-on-abandoning-proprietary-framework-for-a-larger-open-source-project (my question is more on security and long lifecycle)

5
  • 4
    (a) PHP 5 is obsolete and is not receiving security fixes; (b) Strict network firewall rules can be implemented with open source frameworks. One has nothing to do with the other. (c) The lifetime of PHP 5 is not forever (see point a in my comment); (c) You can get technical debt with or without open source frameworks; (d) Laws still apply to open source software, and so will organizational policies; (e) Every bad practice in your current code can be replicated using an open source framework (for better or for worse). Nov 30, 2020 at 15:14
  • Using a framework means standing on the shoulders of others. If you don't do that you have to do everything yourself. You may not want to do that for ever and ever. Nov 30, 2020 at 23:16
  • "it's lifetime is forever (since the team: us; still maintain it and patch security vulnerabilities)" Brave of you to assume you won't quit or die. See COBOL. That being said, best strategy is just to start paying off that technical debt. A well documented and tested internal codebase is just as good as a well documented and tested external one. You might even get it to a point where you will be able to publish parts. Dec 1, 2020 at 7:07
  • PHP5 won't run forever. Eventually the new server hardware will not be supported by the old OS and the current OS version will not support the PHP5 binary anymore. And recompiling PHP5 from source will be a lot of work and that too won't work forever, unless your team intends to maintaint that forever as well. This has little to do with your main question though: you can have your own framework and port it to a supported version of PHP as part of your application maintainence.
    – Rad80
    Feb 9, 2021 at 16:26

2 Answers 2

3

There is a lot to unpack here. Let's start with...

1. Security through obscurity

Obscurity in and of itself does not provide additional security, unless it is so utterly complete and total, that it barely balances being usable.

Are your company records secret?

Are you sure an attacker can't find out who used to work for your devteam?

Are you sure none of ex- or current employees have any copies of the source code on their home machines?

Are you sure that they maintain secrecy and will not spill the beans willingly upon social engineering attempt?

Is your server running an OS that has no vulnerabilities?

Are you absolutely sure an attacker can't get access directly to the server physically?

Is your team really THAT good and all the points of contact (which are exposed and therefore not obscured at all) in your framework are secure?

If you can't answer a strong "YES" to every one of those questions (and many others), than obscurity is not going to help much.

Which brings us to...

2. More open means more secure

It is just a simple numbers game. There is a set percentage of security specialists amongst the population of developers in the world. If more people have access to your code—higher number of professionals will check it out and spot the problem.

This has been the working solution for pretty much every collaborative project in the past couple hundred years. That is how Wikipedia operates. And it is how most modern frameworks operate. They are open sourced in part due to security concerns. It allows them to prove that they are not hiding anything, and in turn, security professionals from all around the world have an opportunity to contribute their experience and skills to the creation of these frameworks.

The dedicated security solutions implemented in open source frameworks will beat you in terms of security. That is, unless you are absolutely sure that your team is able to achieve a world-class security in your custom-tailored closed-source project. Which brings me to...

3. Longevity of code

You have to rememember, that your framework is not floating through the void of space. Your code interacts with a lot of other systems.

You say that you use PHP5. It is now firmly in its "end of life" stage and will never be updated again. Are you comfortable using a system that has a bunch of well-known and widely publicized vulnerabilities? No matter how good your code is, and how strongly you obscure your system, those are not going anywhere.

When you say that PHP5 will still run on servers, do you imply that it will just work indefinitily? Because it most surely won't. As the years go by, support for it will be dropped by major webservers, because there is no reason to drag all of this old, vulnerable, and barely used code along.

So unless you are going to keep your entire architecture the same for the next 50 years, your application is going to stop working as expected at some point. And if you do, then expect to have a lot more vulnerabilities to worry about.

4. Nothing lasts forever

Here is a list of things that did not exist 30 years ago: https, http cookies, JavaScript, PHP.

It is difficult to tell what the web will be like in 5–10, let alone 50 years. Requirements will change. Your application will have to adapt. If your team can pull off writing an web application that will live for so long, using a closed-source framework, based on technologies that are already dying—hats off to you.

4
  • number 3. Are you comfortable using a system that has a bunch of well-known and widely publicized vulnerabilities? can't I say as long as nobody knows that I'm using php5, then its security by obscurity?
    – Kristian
    Nov 30, 2020 at 15:52
  • 3
    @Kristian: Obscurity is not security. Not at all. I wish the phrase "security through obscurity" were banished from IT forever into a lake of fire. Pain and woe awaits the one who thinks obscuring a giant hole in the castle wall is all it takes to keep the enemy from invading. Hackers love obscurity. It's not secure, and it's also hard to detect you've been invaded. Nov 30, 2020 at 18:16
  • @Kristian "nmap" is capable of identifying operating systems simply by how they respond to being poked from the outside. If it for any reason it becomes capable of identifying which operating system and which version of PHP your webserver is written in, you are no longer the only one who knows that you are using php5. Nov 30, 2020 at 23:19
  • then what if I try to workaround it with installing various php scripts/libraries with polyfills (redefining deprecated methods); then put the app in php7? is it secure enough then?
    – Kristian
    Dec 1, 2020 at 4:11
0

In general, yes, its probably better to have your own targeted, purpose-built framework in place for such a long term project. I say this as someone who manages a few 20+ year old PHP applications. You would not have wanted to be stuck with something like PHP-Nuke for 20 years. Frameworks are convenient, but you have to go into them understanding that you're placing a great amount of trust in their future viability. And if they make too major a change to the framework, one that requires too much re-wiring effort on your part to upgrade, that can leave you stuck 'locked' into an old, insecure version.

To your larger point, you seem to be proposing an all or nothing type of replacement, when such a choice isn't necessary. Your application isn't written in PHP 5. It's written in PHP. PHP is still around, and the latest versions can run code intended for PHP 5 often with little or no changes. So your better approach may be to adjust the code to run well with the latest maintained versions of PHP 7.

2
  • so.. is polyfills is a good idea? if not/yes, why?
    – Kristian
    Dec 1, 2020 at 4:44
  • 1
    As a temporary solution, they can work. Better though, for long term maintenance purposes, to replace the depreciated functions. Just start picking pieces and refactor them. Dec 1, 2020 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.