![Simbiat](/assets/images/avatars/e0/93/b1/e093b19da2658e0da94f7fb8569f25b9c68371a3d3b22bf1f1284344110638af536ce7d1ca7953a1500d561e88ffd1e54b1ba9ca175fa8ebed97c0868aaff3a9.webp)
I have been working through Security Journey training the last couple of weeks, and one of the lessons I had this week was talking about securing your code, including decision regarding what parts of it can be kept in public repository(s). The lesson, essentially is advising not to make the code public, because knowledge of the code can be exploited, if there is a vulnerability there, and because others can replicate the code, too. While these are absolutely valid risks, that's not something I will do. Or at least I do not plan on ever doing that.
Repository for my website is fully public. Initially I made it public just for the sake of free license for JetBrains PHPStorm, but there is also nothing that interesting inside there. I mean, even though I do have an authentication and authorization logic, it's not yet open to public, so I am not collecting any data, and the database does not really have any of my PII aside from what I already expose on social media. But the plan is, that it won't always be like this.
I do have a desire to implement certain services, that may be useful for others and I want to find ways to monetize them for some [relatively] passive income. I doubt anything I will be able to implement will bring me tons of money, but that does not even matter, because there will be some data collected, and that would definitely make the repository more interesting for potential attackers. One would even say, that I need to make it private right now, because there can already be some vulnerabilities, especially since I code almost everything from scratch, and there is a high chance, that I am not aware of these vulnerabilities, and thus they will be exploitable years from now.
But I won't.
Even if I make repository private and move to some framework (Symfony would probably be the best choice for me, since I am already using their libraries), there would still be potential for data breach, since both it and other libraries have public repositories. The main difference would be, that if the exploit used is not part of my own code, I would not be able to fix it quickly (because I may not be familiar with the library/framework code or because it will take time to merge a pull request). If it's just on me... Well, firstly, I will be thinking about potential attack vectors more from the start, and secondly, I will be able to fix things quicker. At least if I know the root cause of the breach.
Then there is the scare of someone ripping off the code and making a clone product and making a buck from it. "Scare" should be in quotes, though, because I am not scared of that. I would even say I welcome it. If you can take what I have created and make a better product - I'm all for it. Heck, I may even then abandon my own code, and use what you have created. Furthermore, since I probably will always be the only coder, if something happens to me, it would still be possible to recrate the service somewhere else, if the code is readily available. I am even thinking of ways to share the collected data, too, but have not figured out a good way to do that yet.
And to top it all off, I do want to maintain as much transparency, as possible. I touched upon this in my post about DarkSteam, but I think, that one of the reasons that project was monetary successful (to a certain extent, of course) was the level of transparency I kept, and the communication with the public. I want to be able to do the same with this project, too.
Even before registration was implemented on the website, I had prepared pages with Terms of Service, Privacy Policy and Security Policy. All 3 pages have history of changes, and while they were all created using templates I took care to customize them to tell exactly what is being collected and how it's being used (which will be reviewed before registration opens). Having my code public will allow people to validate, whether what I am saying is true. And that's something that I do not want to compromise on.
In fact, that's the core of this website's ideology: no compromise. If something needs to be done - do it. If something is not working - fix it. Yes, that's one of the reasons things are progressing extremely slowly, with the other being me writing stuff from scratch, and probably reinventing a couple of wheels. But I have seen in the recent years to many cases of companies compromising on something for the sake of a quick release for a quick buck, and providing a bad service after that. Don't know about you all, but I am sick of that. I'd rather be like LTT and deliver something later, but of the best quality I can, than release something quickly and annoy people with lack of basic functionality (looking at your store, Epic Games).