如果归结为系统设计者如何在架构级别处理系统安全，我会说很多。
三倍体
例如，如果所采取的方法是与可信选民进行三重冗余，那么系统试验/测试将是批准实施的主要步骤。假设一式三份的开发团队之一选择使用 Boost。如果系统作为一个整体通过了所有的测试向量，那么人们可能会认为不需要通过 Boost 本身来寻找实现错误。显然，如果所有三个一式三份都选择使用 Boost，那么这将引起关注，因为这样测试向量的范围将变得难以管理。
三重复制是处理使用软件资源（如编译器、库和程序员）问题的标准方法，所有这些资源都有出错的风险。 Boost 只是其中之一。有人可能会说 Boost 共享指针显然是一种降低程序员错误风险的方法。从总体上看，这最有可能对整个系统有利。
重要，但不安全
有趣的是，当不使用三重法时，人们现在就处于真正必须信任事物的境界。有趣的是，许多系统似乎解决这个问题的方式是，最终有一个控制者来监督并能够在系统出现错误时进行干预。
例如，汽车行业有一套称为 MISRA 的编程规则。 ABS 系统的软件应该按照这个规则集编写，并且开发工具应该设置为在源代码上强制执行这些规则。我们的想法是，这会将未检测到的错误的风险降低到可接受的水平。而且因为最终有一个驾驶员在驾驶汽车，他们总是可以自己进行节奏制动。因此，汽车行业避免了重复实施 ABS 的情况。
他们正在将相同的理念扩展到更复杂的汽车系统，例如自适应巡航控制和自动驾驶汽车。我个人认为这样的延长对于自动驾驶汽车来说是不合理的。相关立法明确规定，如果此类车辆发生碰撞（即您仍在“驾驶”它），则属于“驾驶员”的过错，但光鲜亮丽的广告不会详细说明这一重要方面。
医疗器械领域也是如此；无论如何，应该有一名护士或其他人来监视病人，所以偶尔的小问题都会被这种监视所掩盖。无论如何，整个事情都很糟糕；虽然医疗设备的软件可能已经过编写、测试和批准，但这些软件通常在嵌入式 Windows XP 上运行。它们都联网并最终感染计算机病毒等。 FDA 不会让你有自动更新系统，只有设备供应商可以更新它，当然他们永远不能指望跟上。因此，您最终会得到一个编写良好、经过测试且运行在操作系统安装之上的良好医疗软件，世界上所有的黑客都在其中运行，天知道在做什么。我认为在这些情况下使用 Boost 不会给整体系统风险增加太多。
因此，如果符合 MISRA 的工具链提供 Boost 作为该工具链的一部分，那么我不明白为什么这与提供标准 C 库的工具链有什么不同。如果工具链供应商对其进行了认证，那么情况与其他任何情况都没有什么不同。
这种方法存在一些弱点。根据我的经验，我遇到过广泛使用的符合 MISRA 的工具链，当所有优化都打开时，其编译器会生成垃圾目标代码。我实际上能够在反汇编中验证这一点。然后我查看了工具链标准 C 库的源代码，它本身显然不是按照 MISRA 规则集编写的，而且它还包含明显的、可怕的错误。
然而，只要您在项目设置中勾选 MISRA 复选框，使用此工具链构建、测试和销售汽车 ABS 系统就没有任何监管障碍。将 Boost 添加到该工具链不会让事情变得更糟。
安全至关重要，无需重复
最终的方法是没有重复，也没有人工监督。这真的很难，因为你需要正式证明工具链、操作系统、驱动程序、芯片等每个组件的正确性。据我所知，对于真正的安全关键系统，如核反应堆、飞行控制航空电子设备或其他系统，从来没有这样做过。如果系统出错，肯定会致命。
据我所知，唯一接近的是 Greenhill 的编译器套件及其 INTEGRITY 操作系统。他们可以为您提供（支付一大笔费用）操作系统的每一行、所有库和编译器等一切的正式测试和验证证据。如果有人想要尝试一种真正的安全关键系统而不需要重复，那么这将是一个起点。
我认为他们还没有完成 C++11，尽管我已经将 Boost 添加到他们的工具链中并且运行得很好（它不在我急于添加的安全关键系统中）。
结论
当然，如果像 Greenhills 这样因可靠且经过彻底测试的工具链而享有良好声誉的机构提供 Boost，那么我认为人们将能够在受监管的系统中使用它。然而我怀疑整个 Boost 是否会以这种方式提供；他们更有可能遵循编译器标准。
我还知道 GCC 过去已经通过了正式的编译器验证测试，因此可以在 Stuff That Matters 中使用。我预计这种情况迟早会在 Boost 的最新版本中重复出现。
