像 js(node)、 Python 作为服务端部署到生产环境，怎么保证源码的安全性的？

用容器加密怎么样

服务器都能让人随便登录吗？

这个。。。用一个罩子，把服务器罩起来，不让别人看到。

js 就用 webpack 或者 esbuild 等工具来打包，打包完成以后代码是会被转译+压缩的（人类不可读）。

22 支持编译独立二进制了，node

生产服务器的权限都随便给你还在乎源码的安全性吗

有一种比较好的实践是不直接把部署源代码的机器暴露在公网上的，一般最前面还有一层网关，网关到业务服务器走的是内网转发，这样会好一些。

1. node 生产环境一样要打包混淆压缩，部署源码是错误的做法
2. node 编译产物和 java 编译产物在防止泄漏源码这件事上强度差不多
3. 有直接登录生产服务器权限的人想干什么都行，你可能需要的是堡垒机

python 可以用 pyinstaller

node：
1.打包成二进制，但是只能 require 。
2.混淆部分关键代码： https://obfuscator.io/
3.部分关键业务用 Go/Rust/C 等重写，编译成 Wasm ，再调用

python 研究的不多，pyinstaller 打包可能是个不错的方法

都能进服务器了，源码再怎么加密 混淆或者二进制打包还有意义吗？


这场景似乎只在预防一种人：可以给他服务器权限但不想让他看到或复制源码

啊 那 php 的源码部署岂不是哭晕在厕所
不过换个想法
流量比源码值钱多了

@darksword21 pyinstaller 保护不了源码 运行速度还慢
@grayfox 建议看看 nuitka 这个打包源码 我用 ida 看了下 字符串基本都加密了如果觉得打包慢可以封装部分模块配合 pystand( https://github.com/skywind3000/PyStand) 打包详情看知乎文章
https://www.zhihu.com/question/48776632/answer/2336654649

你门都被别人 x 开了，你关心的居然是源代码？难道不是直接把你库脱了嘛

服务器被登陆比代码泄漏严重几个数量级，屎山代码开源都没人看的。

你的业务代码这么值钱吗？
如果很值钱，可以考虑代码混淆、定制加密解释器，例如 pyarmor 。
反正，有成本的。

Java 能直接反编译啊...

“只要有登陆到生产服务器的权限”，你家门都被人打开了，家里的东西再怎么遮盖，用处也不大了……

用 python 就别想闭源了

可以购买加密软件

@0o0O0o0O0o 人家问要怎么做，你跟人家说这件事要做，就是不说怎么做

node 不清楚，Python 我知道可以用 Pyarmor ，支持跨平台编译

有一说一，放在服务器上的代码都不值钱，就算直接给你源码都没用。真正值钱的代码人家都编译成一个可执行程序直接给你，你要是破解它，人家能把你告到倾家荡产。所以人家也不怕你破解。

说一个实际接触到的商用场景，乙方交付工程给我们使用，部署在我们给定的机器上，但是源码并没有售卖给我们。乙方使用了自定义 Python 解释器+源码混淆加密的手段保护自己的源码。可以运行，但是逆向难度极大。

应该是防同事吧，防新来的？既然这样服务器权限干脆别给。。

@x2420390517 #21 我指出我觉得 OP 理解有误的地方（**主流的部署在服务器上的**编译后的 java 项目并不比打包后的 node 项目保护强度高），并给我觉得更合理的方案（堡垒机用于授权监察审计），请问有什么问题吗？真顺着 OP 的思路去探讨不适合这个场景的混淆加固方案吗？不是我不会，是我觉得不合适。

@x2420390517 你这纯杠了，人家这个回答清清楚楚的表达出「 OP 可能是源码部署，但是实际事情是有解决方案的，只是没喂到嘴里」

@jianchang512

“这场景似乎只在预防一种人：可以给他服务器权限但不想让他看到或复制源码”

有这样的场景的，比如你提供的是一个语雀这样的服务，客户要求私有部署，你又不想让他看到源码

python 可以打包成 so 部署

都有自己的编译方式，同时也有对应的反编译方式。学过逆向的都知道，道高一尺魔高一丈，只能拉高门槛，根治是不现实的。

都进服务器了，谁还要源码啊，直接 clone 数据库了~

人家能进服务器
看不看源码重要吗

惹毛了给你 rm -rf 都干了

我们用 bytenode ，编译环境和实际运行环境的 node 版本要一致。

私有化部署下是常见的需求：甲方要求服务部署在他们自己的服务器上，服务由乙方部署，因为服务器是在甲方手上，为了保护服务不被甲方自行破解或者拷贝滥用，乙方会对服务进行混淆甚至加密，以防止服务被修改或者拷贝

我服了很多人的逻辑。。。。 戾气极重
没有好的解决方案就看看不行么。。。

nodejs 的话，一般会使用混淆+编译为二进制文件 bytenode, node18 之后开始原生有 Single executable applications 的相关接口

动态脚本是这样，不用编译直接运行。代码篡改是服务器安全问题，不是代码问题。

@RangerWolf 中国人就是这样的

@darksword21 #9 这垃圾玩意没人用的

@djasdjds 那用什么，我不熟悉 python 相关的东西，我这里是要部署到客户提供的机器上

这个问题很简单啊。你程序跑起来之后，把 .py .pyc 文件全删了就行。

只要你的源码够烂，依赖环境够乱。就算源码丢了别人也跑不起来。

直接开源，从源头解决问题

其实 java 或者其它编译后的语言也并不安全，现在所谓的 jar 包保密方案，也只是给文件加个密，然后 Java Agent 启动时解密，但随便丢个 arthas 之类的工具上去，从内存中拿字节码反编译出来根本防不住。

所以哪有什么绝对安全的方案，只要你的软件价值小于别人攻破你的成本就行了

能直接登到生产服务器上的，是啥都防不住

我选择直接开源

@BreadKiller 都公司了, 更应该用商务法律得方式解决, 你拷贝我抓到罚钱就是, 怎么可能禁止拷贝

其实并没有太好的方法，就是混淆加固，但是 python 的加固效果一般，除非你们找个算法变种的论文自己做一遍，上面 24 楼的兄弟说的就是一种办法

其实我很好奇现在有了大模型帮读代码之后混淆还有用吗

@dododada 公司之间得破解没啥意义, 说实话, 就算能破解, 你公司敢直接服务器用破解过的吗, 别人查到直接告你, 罚巨款

js 有混淆

@yb2313 容器是一个神奇的词么，连加密功能都有？
（虽然后来确实有了，但我相信你说的肯定不是那个）

python:nuitka 或者加密源码
nodejs:
在 Node.js 中，将项目打包成二进制文件的常用工具包括 pkg 和 nexe 。这些工具可以将你的 Node.js 应用程序连同其依赖项一起打包成一个可执行文件，方便在目标系统上分发和运行。

1. pkg
pkg 是最常用的工具之一，用于将 Node.js 项目打包成可执行文件。它支持 Windows 、macOS 和 Linux 平台。
... --- gpt

跑起来之后把硬盘上的代码删了

私有化部署并不代表要交代码呀，而且别人服务器有漏洞，被盗走了也不好

确实很麻烦 所以我们喜欢用 go

编译混淆一下。 再写个 wasm 之类的做哈希校验？

js:bytenode
python:pyarmor

@julyclyde 不懂, 我只是凭直觉认为容器应该有这功能, 因为这非常 cooool

@hansnow 你以为内存就提取不出来？[doge]

问题的关键是保证源码安全？不应该是把服务器权限做好吗？

1.堡垒机。
2.Node 源码能打包混淆，不会直接运行源码。

官方有提供编译线上只给编译代码。没有就买商业加密软件。

所以我现在软件都转向 go 编写。build 后随便对方拿去破解。能逆向破解，那是他本事了。

@xuanbg 值钱的是核心算法以及数据库（海量）数据。

pyinstaller 也可以，会臃肿些

@zeusho871 我这个呢 https://github.com/ZhaoQi99/pyencrypt-pye 感觉用起来还行..就是不知道容不容易被破解

@yb2313 你这是容器迷信
虽然这次你蒙对了，但是你的思路不对

真的，能登上服务器的人对屎山代码真不感兴趣，但数据库大概率要被拖……

楼主 问这个问题 有些本末倒置。问题是 该如何登录到 生成服务器？如果能登录，别人的目标是看你的代码吗？

本就不存在这样的问题，也就不会好的解决办法。

恕我直言，公司的代码根本不用专门混淆

解释型语言拿去编译字节码也是敝帚自珍，主要是给老板提供心理安慰

唯一值得保护的也就是配置文件，证书 API key 之类的

其他的，那不是针对谁。。。

真的，Github 上的开源代码我们都看不过来……

都有你服务器权限了，源码不是太看得上。想开个淘宝之类这不是光有个源代码就解决的。更别提他们复杂到吓人的架构了。开源商城就更多了。

配置文件有其它服务账号密码这个可能更感兴趣些。

@wupher 确实，私有部署给客户的话，光一个打包工具的默认混淆，绝大部分人就已经搞不定了，更别说通过这份混淆代码，梳理清楚业务架构，那就更恐怖了，99.99%的公司都没有这个资金干这个事。。。

业务代码没那么重要，无所谓吧，重要代码打个包得了

deno 可以编译项目代码成可执行文件, 不知道反编译强度够不够

@yin1999 你猜爬虫这个岗位是干嘛的

@wenrouxiaozhu 基于 rsa 和 aes 的? aes 密钥从后台发的还是

没用的，要提交代码，我都进了你服务器了你数据全是我的了，我看代码干嘛

虽然编译了也能逆出来，不过能解决大部分场景了。稍微提几个

1. 印象中有三四个专门做代码混淆的，甚至混淆后的代码还能带有效期（发请求拉时间戳）
2. nuitka --module 打包成动态的 .so/.pyd ，不熟悉用法可以直接 Github 找我发的 nuitka simple gui 。只编译核心代码就行，不要编译依赖
3. 丢 serverless 之类的地方上面，不过也还是丢在服务器上做隔离，服务器不隔离也没用

不加密，严格做好数据和代码分离。服务器真无所谓的

python 也可以混淆啊

@zeusho871 随机生成的

@wenrouxiaozhu 那不好说 因为毕竟在本地 不如编译成 c 因为永远不可能逆向出来源码

@incubus 知道啊，如果真有更高的要求，那用 WebAssembly 技术或其他的编译型语言去。如果没有，压缩+混淆已经足够了。要还原也得耗费人力金钱。

@zeusho871 加载器编译成 so 了，没办法做到所有源码都编译成 C

用 docker 把源码打入镜像，用 k8s 部署。基础镜像选择 alpine 类的。。这玩意连 ssh 和 telnet 都没有。

我 golang 的服务都是源码部署，何况 nodejs 和 py 的

@datou golang 你怎么源码部署的呀？运行时现场编译吗？运行多个副本就编译多次？

@julyclyde go run main.go

@datou 那你真的是多个副本分别编译一遍吗？？厉害了

不编译呀，golang 本来就支持这么运行

@tyc 又中国人是这样了，闹麻了

@datou 这并不是解释运行啊，依然是先编译后运行啊

@datou https://pkg.go.dev/cmd/go#hdr-Compile_and_run_Go_program
COMPILE and run
并不是只有 run

现在 js 的打包工具可太多了，所以你为什么不打包？

@leconio docker cp / 是不是可解

@julyclyde 无论 golang 内部机制如何，我这确实是源码部署呀

只传了源码，没传二进制

@datou 你确实是源码部署了。不过我关注的是，你难道真的不在乎多次编译的开销？？