我的上一篇博客文章的开头是“无论可能的残余风险......”。我今天想重点关注的正是这些残余风险。为此，我将首先定义何时可以谈论残余风险，然后更详细地研究它们。
残余风险 - 简短定义
用经济学术语来说，剩余风险可以定义为我作为公司或个人能够承受的风险。这意味着“我的”风险暴露是我可以接受的，这种风险的发生虽然令人痛苦，但不会对我的公司或我个人产生严重影响。这本质上是风险管理流程的目标。当然，灾难性事件发生概率非常非常低的情况很有趣，比如陨石掉到我头上的概率。但下次再详细讨论。
我不想进一步讨论这个经济方面——即使严格来说，它与 hotmail 电子邮件列表 我的进一步评论相关。当然，软件的开发和运营也是经济风险管理的一部分。
我对最大的视角更感兴趣：如果我不断用尽所有技术和组织选项，还会剩下什么风险？我知道我可能超出了必要的限度。
下一步，我想简要讨论一下实际需要做什么，以便我能够谈论技术和组织上不可避免的风险。
实现最低风险的先决条件
实现这一点的先决条件是实施尽可能安全的安全软件开发流程和操作（通常称为 DevSecOps）。其中包括（无需详细说明）以下几个方面：
完全了解安全要求并实施适当的措施。
进行设计分析或威胁模型（最好多次）。
进行工具支持的静态代码分析，并有选择地通过手动代码审查和修复可能的漏洞来补充它们。
如果可能的话，持续依赖管理（有时也称为软件组成分析）可在 24 小时内修补已使用的存在漏洞的第三方库。
强化的操作和网络环境。
经过安全测试的配置。
安全处理密钥和凭证。
定义、实施和测试恢复时间（例如 RPO、RTO 或 WRT）。
适当的授权概念。
全面的安全测试概念 - 包括可能的动态分析和渗透测试。
不要忘记评估安全机制、漏洞和可能的解决方案的专业知识。
防范 DDoS 和 DoS 攻击的措施。
演示文稿当然有点简短，但其目的是表明所有已知的措施都是通过专业知识实施的。