Chromium项目研究人员经研究发现，项目中的所有高严重性安全漏洞，其中有70%来自于内存安全漏洞，也就是由C/C++指标操作错误所造成，而这些错误中又有一半是释放后使用（Use-After-Free）的bug。
这个结果来自于对2015年以来，Chromium的912个高或严重安全性bug，对稳定版本所造成影响的研究，这些bug平均分布在程序代码库中，并且其中有一大部分非稳定性错误，是由同样类型原因造成，这些漏洞让用户暴露在风险之中，同时还增加了修补和交付Chrome的成本。
虽然Chromium的安全基础架构的设计，便是默认程序代码库存在这些bug，并用沙盒降低bug所产生的伤害，但研究人员提到，这并非解决问题的根本之道。Chromium会用沙盒执行程序代码，当其中bug遭到利用，便可以防止黑客接管主机，在过去几年，Chromium一再强化了安全基础架构，确保网站相互隔离，而这些工作也确保Chromium能够走在攻击者之前，让Chromium免于严重的安全威胁。
但是研究人员认为，Chromium已经达到了沙盒和网站隔离的极限，其中最重要的限制是，虽然程序是隔离的最小单位，但是以程序进行隔离的成本并不低，尤其是在Android上，过多的程序会影响设备运行状况，有可能使像是其他应用程序或是浏览器的分标签等后台程序，被终止的频率变高。
目前仍有程序共享多个网站的信息，像是由C++编写的网络服务，就是一个大型组件，用来解析来自网络上各种复杂的输入，根据Chromium的开发第二规则，网络服务是一个大型且易受攻击的目标，具有许多严重的漏洞，落在毁灭区间（Doom Zone）中。
要用网站隔离的想法来处理网络服务为不可能的任务，虽然当把每个网络服务程序都绑定单一网站，会大大提升网络服务的安全性，但这也会使Chromium程序数量激增，进而严重影响性能。研究人员表示，在坚持第二规则的情况下，会冲击Chrome新功能的开发，因为要启动一个新的程序来处理不可信资料的成本太高。
研究人员指出，现在已经无法从更多程序或是更强大的沙盒，来抵御攻击者新型的攻击，而成本最低的做法，便是从源头减少错误。因此Chromium项目研究人员正着手研究，采取解决内存不安全问题的所有必要手段，包括自定义C++函数库，加入硬件缓解决方案案，并在适当的地方使用更安全的语言。
总结主要方法的两个方向，其一是大幅更改C++的开发方法，像是禁止使用原始指标等，但这些做法可能连带影响程序性能，另一个方向，则是为程序语言设计编译时的安全检查，虽然对性能的影响较小，但是在桥接C++和新语言时会有一些麻烦。