随着移动互联网、人工智能等相关产业蓬勃发展，软件源代码防泄密这一传统话题再次成为焦点，关于是否有必要保护源代码以及如何保护的讨论也是如火如荼。

　　首先，对于源代码防泄密是否有必要，不少产品开发人员认为内部源代码防泄密的意义不大，因为即使拿走产品全部源代码也未必能够重现商业上的成功。

单纯从产品角度看，上述观点确实很有道理，也具有一定代表性。

但问题在于，我们无法确定别人拿走源代码就一定是为了重新搞个产品、开个公司、重现商业上的成功。

全面分析产品漏洞，搞挂马、攻击之类的也非常常见，亦或是其它，谁又能保证？　　另外，试想一下，核心代码泄露这样的信息，会给公司带来多大的舆论冲击。

用户对公司的信心必然备受打击，我们完全没有必要让自身陷于被动局面。

综合考虑，与其面临巨大的不确定性与风险，不如早做准备、未雨绸缪。

　　其次，关于如何保护内部源代码实现防泄密，传统的文档加密软件与沙盒防泄密的做法是依赖进程进行一系列策略设定，这不仅带来源代码防泄密系统实施、维护、升级上的麻烦，更会带来源代码防泄密系统自身安全性上的巨大风险。

若在此基础上再对源代码本身进行处理，则进一步带来卡、慢、死机、损坏数据等问题。

显然，传统防护手段难以符合用户需求。

　　究其根本原因在于：　　1）源代码进程众多且调用关系复杂；　　2）开发环境复杂；传统的文档加密软件与沙盒防泄密的做法并不适用。

　　事实上，文档加密软件更适合文档类数据加密，沙盒更适合防病毒，而不是防泄密，尤其是主动防泄密。

也正是考虑到上述两点事实，当前源代码防泄密的普遍做法是采用DSA数据安全隔离技术，通过构建源代码存储、流转、使用的安全区域，来实现源代码防泄密。

整个DSA防泄密过程完全避免了源代码防泄密的两大误区：1）依赖进程进行一系列安全策略设定；2）对代码本身进行处理；　　毋庸置疑，保护内部源代码安全，防止其泄露、扩散，不仅很有必要，而且还必须充分考虑到源代码防泄密的特殊性，采取更加合理的防御措施，避免源代码内部保护误区。