It might be a threat to gaining monopoly and riches, sure. But what about server stability and user data's security?
I am thinking that letting people know server structure makes it more prone to SQL / NoSQL / GraphQL injection, for instance. Also, knowing where and how you host makes it prone to DoS.
Top comments (24)
Not disclosing your source code is mere security by obscurity, which is the last and least effective line of defense against attackers. I've seen so many teams and projects to rely on security by obscurity so much that they avoided fixing security issues at all that I've grown sceptical of the whole concept.
On the other hand, putting your source code online will also allow security researchers to find weaknesses and inform you so you can improve the security of your code. However, security is always a conscious and never-ending effort. If you're not able or willing to make that, it might be better not to go open source your code - or even host the service at all if it is handling critical data, as you might be liable for its loss.
What about bad people reading code finding security issues before others and not reporting it but abusing it? Or the fact that someone copies your whole project and just changes frontend? How could you know they have your code out there and invest no effort in it while providing same services and dropping the price? Just because they started with your code doesn't mean they need you to update it they can go different path. It's really unfair to your company owner as he paid people to have it built and someone just clones it does a little modification and gets some potential customers and even if they fail they still do some damage to your company. Competitors are great but fair ones each investing their own resources and time into same type of project. My company has competitors and we're discussing with them on how to provide same data structure and features so users can use both systems or choose or even switch and I would gladly discuss all my code with them but they have theirown and don't care about code but more about architecture and features which we do share info about
First, bad people will find vulnerabilities with or without your code. The question is not if, but when. So you are currently speculating that the bad guys are faster than the good guys. Well, there's this thing called "Hacker ethics". People who know how to find these vulnerabilities usually earn enough money not to be too easily corrupted. The rest is usually script kiddies who wouldn't find a vulnerability with a map and a compass. I am more concerned about relying on security by obscurity than I am about security issues - because the former usually means the latter never get fixed.
What about some people taking your code and providing the same service? What's stopping them from doing so even without your code? Usually, any product worth its salt will have both front end and back end code. So unless they copy the parts of your front end that rely on the same back end, the rewrite is going to be pretty involved. In the meantime, you're developing your product, faster than they do. If you do your work well, you'll either spot them copying your code from an IP range away (and then it's a legal issue) or they'll never be competitive anyways and you can safely ignore them.
Point that most of people who spot the vulnerabilities are paid enough to actually report bugs makes sense.
On the other hand, there's a lot of foreign players and "corporate espionage" which has been lately and issue. I explained that once damaged the comment "your developing faster" makes no sense as we don't care if the bad guys go down, they will at some point anyways, but we should care that some good company got damaged or in this case we're discussing a company that you (the one that exposes code or such) have some involvement in like employee or owner. You can find about what some companies did back in China and it did some damage to companies in US, countries in Europe, and some Asian like South Korea. I really don't want to write in comments about it
Sony was speculated to be hit by these kind of guys however I don't think it was proven to be some other company that wanted damage done to them but rather "wild" hackers. This case is not about exposing the code but rather proving a point that exposing code will help the bad guys also who are paid enough but in this case to damage you.
I mainly focused on good idea getting developed in small startup or some mid sized company in some cases where the "you move faster" is not true and someone can abuse it.
"What's stopping them from doing so even without your code?" way off the point and "sually, any product worth its salt will have both front end and back end code." shows misunderstanding of potential ways to exploit it. Fronted can be different in terms of UI and many methods could be rapidly refactored to look different both for the backend API and frontend. So how could you ever assume that someone took your code? No serious rewrite will happen in terms which I described like small startup with a good idea. Say you take 4 devs to develop a nice project in couple of months. Now most time spent goes on domain research. This whole code can be rewritten in many cases by 1 single guy in a month who didn't spend a dime on salaries, office, domain experts (well someone who knows domain pretty well probably not real expert). Now if he jump starts solution from 1 month without any investments, gets couple of clients without anyone knowing what he did, he can also hire later devs to develop maybe even in different direction. There's a good chance no one will ever know and a fine chance of damaging company that started the project without you knowing nor even considering that they did such a thing. On the other hand they could also be scanning your code for vulnerabilities to make problems to you and back off potential customers of yours
I was mainly having these statements as I read about these cases and was wondering if I wanna start a company is it smart enough to expose the whole code.
Security by obscurity is one thing. Keeping things secrete is another as additional protection layer is another. I don't know any army, national or such projects being open source until they decide they are good enough to let go.
Working in as a developer seeing some things made me realise that not all owners are "capitalistic bas***" they are just taking some additional measurements which they can as they don't want to get burned again. Some of them just trying to ends meet and it usually does provide enough security to hide the code as most of those "kiddie" hackers are people they know in some way and those guys can only benefit from the code.
Real world example 2015, neighbour of a company owner wanted to hack him and make a similar product, he got most of the code and that's how hacking took place. Made huge AWS bill, but Amazon was nice enough to stop attack return the money and tell them to change they're dev keys. Now there's a wrong way of doing things but it was development and they were hitting deadlines thinking who would hack them as no one even knows about the product except potential customer.
In most cases, the API itself will not be worth too much without the content to back it. The latter obviously shouldn't be open-sourced, except if the service you provide is free in any case (then competitors cannot outbid you).
Unfortunately, especially in startups, security is too often an afterthought and not an underlying theme - not only the APIs themselves, but also company security and security of your internal systems. But if your security is bad to begin with, not going open source will not save you in the long run is what I'm saying.
As for your point that one guy can single-handedly rewrite a complex API that took 4 skilled developers multiple weeks to come up with to the point of being completely unrecognizable within a much shorter time, I don't really believe you. This one guy will still first have to understand the solution, which with the code won't take far less time than without it.
It takes renaming API endpoints not to get a warrent to be able to comapre 2 codes. That's all it takes.
On security side I put my money where my mouth is. I would never expose my backend code. I don't see code for AWS stuff nor Azure nor Google search engine and so on.
But if anyone wants to go ahead. I'm not buying "obscurity" statment as good enough to say go expose your code.
You're not fooling anyone if the data structure and the output is still the same. Also, I'm not saying that you should by all means expose your code, just that the "security" argument is leading into dangerous thinking about security.
I think licensing and make a lawsuit is another topic. Of course, I know LICENSE is one thing, and sue is another.
That should be thought be open sourcing or licensing.
Licensing has no impact on you knowing that anyone took your backend code nor gives you any ability to detect such things if you have non obfuscated code (even when you do but it's quite improbable) especially in languages where you use only that language; like Java where you mainly relies on Java libraries and most people avoid native calls except well-known ones from the system or such were you depend on other external parties that you have no influence of.
Let's say you get your Python/Java/whatever service online and expose that code on GitHub. Someone clones it, makes a couple of changes to fit their idea and is silent competitor to you with smaller prices since he didn't invest in human resources to get the API done. He makes fully new frontend and viola. How can you ever know that he didn't just had same idea? Would you really ask someone to check their code if it looks like yours? Only way to know is to have some developer inside their company and tell rest of the world ohh this is copy from X project.
This can happen with small or maybe even mid size projects, while big ones are not as vulnerable as even getting up and running such projects might cost a small fortune and a lot of professionals. And no one ever has to know. You loos potential clients you fail to generate enough revenue to keep project alive and your company suffers. It doesn't matter if someone who did a copy fails also, you were damaged and never knew. Or it doesn't even matter if you knew if you failed because of it nothing will fix it since customers went away and have no intention of coming back.
So I would say that at some point if you get big enough you don't have to worry about getting damaged by stolen code then you can consider these issues about security. If you don't keep sensitive info you can risk bad hacker not reporting bug and using it to steal info which may impact your revenue but not actual end users which should be less of a worry than exposing actual user info.
That's not the security issue. It's the business-building issue.
Not focusing on security with that answer but rather replying to your Licensing comment as solution to it. How does the licensing solve security at all? It doesn't. This part "What about bad people reading code finding security issues before others and not reporting it but abusing it?" was security and licensing doesn't help in any case. If you don't detect malicious activity on time nothing helps
Possibly controversial opinion, but as a potential investor, I would consider a company whose business model relied as much as you seem to imply on their competitors not providing exactly the same services to be nonviable.
Looking at it differently, yes, being open source may make life easier for competitors, but it can also make life easier for your developers, because it opens the possibility of getting external contributions that you don't have to pay for at all. Adding to the comment about security researchers examining your code, it's not unusual if they have all the source code for them to submit patches upstream (that is, to you) to fix the vulnerabilities they find. Similarly, unless you're in a niche industry, it's not unlikely that regular end users may submit patches to fix small bugs they come across.
Build a business, and earn investors' trust as a Quality Stock is hard, and it does correlate with funding.
But earning on Patreon or OpenCollective is another thing. It is hard to get much or reach the target, though.
Is it good to delegate to third party security expert, probably via CI? Do I have to open-source?
If you don't have the time or expertise to focus on it, then someone who does has a greater ability to stay on top of it than you do. There are a few different ways of saying it, but my company likes: "Security is a journey, not a destination". Basically, security is not something that you "have" – it's a continuous process.
If it's in your budget, then I would outsource. If it's not in your budget, then you need to budget time and resources to do it yourself. Given that you won't do it as well, and it still comes out of your budget, then that's where you have to balance the tradeoffs. What's the likelihood of being attacked? What is the expected cost of a breach? etc.
No, you don't have to open source anything that is just for you.
It's a little different if you're selling a security product. By not open sourcing commercial security code you will be open to a lot of criticism. People won't necessarily trust your product. They will claim you are trying to achieve Security by Obscurity. Indeed, such products often become targets for people trying to break in. This means that if there are any flaws in your implementation, then the only people with that information are malicious third parties, and you have no ability to get feedback through public auditing. (Security researchers often audit such products). But this doesn't sound like your situation.
The first line of defense is your developers. You should pay for their security training and have that regularly. The second line is hired experts who do security reviews, threat modellings, attack scenarios and so on. The last line is encryption of sensible data. No, that's a joke. The last line is management, who needs to remain vigilant and employ the other lines of defense a lot.
Widely depends on the data your app is working with. Tho generally not a good practice unless its a necessity and you really know what you are doing.
That's where GitHub private repo comes in? if you need online git?
For example, I still sometimes need git CI/CD.
Also, how do I let people post server-side issues without making it public?
People can post if you provide a drop box. Either email (which isn't necessarily secure, but not too bad), or a web page form.
I have seen a GitHub repo with only one file,
README.md, though. Not sure how people manage that.Oh, I see. I thought you were trying to allow people to post issues without their post being public. Sorry
Does anyone actually have data points they can bring to this discussion? The only reports I have seen are old, and we have seen a big increase in volume and activity in open source, yet I have still to see an updated report.
I have seen the WhiteSource/Snyk/Blackduck reports, but they only look introspectively at open source and do not provide any real analysis against non open source. Anyway point to some interesting posts?
I want to add to what everyone is saying. "Security by Obscurity" is a well known security mistake, so much so that there is a Wikipedia page for it. You aren't obliged to put your code out there, but if you think that you're gaining something by keeping it secret, then:
Keeping the source secret is not a flaw in your security, but you really can't rely on it doing anything for you.
If the security of your application depends on obscurity of the source code you are not exactly secure are you? Your application should not contain deployment artifacts, credentials, or anything else that exposes how your particular installation runs.
If you make your code open source and others use it they will have an interest in reviewing and resolving security defects. Open means honest. No hiding defects, they must be resolved.
Now this isn't magic. Just because you release your code on github doesn't mean magic coding fairies will fly in and perform a security audit on all your code. If your code has more holes than swiss cheese releasing it would be nuts. So at the very least resolve the issues you know about and have a go at hacking it yourself.
At the end of the day something that is in wide use as open source is far more secure than something that is used by only one organisation which is closed to inspection or review. Most of your stack is probably open source already. Obscurity only gives you a false sense of security.