4.x
We are looking into using Godot for enterprise applications where security & compliance requirements are generally stricter than most games.
For this, I wonder if there has been any formal security assessment performed / documented on the Godot 4.x codebase?
If not, is there any interest from the community, if we were to sponsor such a test? Do we have anyone on the forums here who know of qualified provider for this?
Thanks!
I’m not aware, that any security assessment of the Godot 4.x codebase has been performed.
Security threats come in many forms, and it can never be said that a program is resistant to all of them (even programs from large companies have breaches), but this depends on whether your program remains server-side or is mostly client-side. If everything remains on the server and the client is merely an administrator, checks should focus on server inputs, which generally aren’t particularly complex (compared to other advanced security measures). On the client, almost anything is possible (as long as the threats are subtler than your program), and keeping it secure requires careful analysis of each section based on documentation and reference code.
But essentially, the only danger that threatens Godot with GDScript is the objects that are created because nothing but an object can do anything, so security tests at the endpoints should be done on this. This also applies to anti-cheat systems that we use in games, and as long as you know that threats won’t spend hours trying to break into your program, there’s nothing wrong with it.
Godot doesn’t have documentation for security review methods, but for more information, you might be able to get help from security@godotengine.org. They won’t essentially tell you the weaknesses (if there is a known weakness), but they will probably give you security details to the extent that you are sure that you can find a suitable way for security checks (although basically the method that the motor security team uses must remain confidential), the best thing you can get is the method of independent testers for reporting bugs even if they have failed.
This is a gross oversimplification.Security holes and issues extend way beyond what you can “normally” do with such an engine. There was already a recent example of this with the GodLoader situation
In enterprise applications, you should ALWAYS assume that someone, somewhere will do their absolute best to break whatever it is you built, or whatever tools you’re using. Most, if not all enterprise applications require some form of pentesting to make sure there aren’t any obvious security holes, sometimes they’re not in the program itself, but rather an external library the engine relies on.
Security is only as good as it’s weakest link, and if there’s even a single library that godot uses that has a vulnerability, no matter how good your code is, that can probably be exploited.
I agree, I saw it when I posted the GodLoader information, and what I meant by “with GDScript” was to exclude such cases.
And that’s exactly why I say “as long as you know” because in many game security reviews we also make that assumption. What makes things difficult is that it’s not just the actual app that could be targeted, it’s more likely, as you said, that one of the tools used could be targeted. This would give the attacker enough reason to target many apps with just one attack.
Thank you, these are helpful comments.
Of course, the security of any application under active development is a moving target. The important thing is that vulnerabilities are proactively found and patched.
I will send an email to the Godot security team and ask about their methods. For ourselves and our enterprise customers, what would be nice is some proof that security testing is being performed and acted upon.
If I’m not able to obtain these, we might run some tests of our own and share the findings, if any.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.