导致安然标题问题标软件缺点首要有两种：摆设中的缝隙和设计中的缺点。此刻软件安然市场中的大年夜部门重点都放在发现和修复缝隙上，这主如果因为主动代码审查东西让这个过程变得很简单。但其实软件设计和架构中的缺点标题问题也据有很大年夜比率，它占所有安然标题问题标50%。

　　简单地说，假定我们想要解决软件安然标题问题，我们就需要把更多寄望力放在缺点上。

　　利用ARA寻觅软件缺点

　　多年来，我们都在致力于软件风险阐发和设计审查。当我们在1997年第一次开端审查系统的安然性时，我们采取了专业的编制--三个专业人士在房间里利用一块白板来审查。而此刻，当我们深进查抄软件架构中的缺点时，我们采取的是被称为架构风险阐发的编制。

　　ARA包含四个步调。步调0(我们凡是是从0开端的，因为我们是奇客)是获得一个架构图。这可能听起来很笨拙，但不管你信不信，从开辟团队获得相干的最新的架构图比听起来更坚苦。例如，一些开辟团队指出“代码就是设计”，对此，我们不敢苟同。

　　这个步调的最终方针是成立软件系统的单页总览视图。单页总览视图很是首要，因为我们想要“丛林级”的软件视图，避免“只见树林不见丛林”。我们都知道，缝隙呈此刻树木级，而缺点则在丛林级。我们不想要看到大年夜堆代码，我们不想要UML，也不想要防火墙建设收集地图。在良多环境下，我们可以经由过程扣问软件架构师、开辟人员和测试人员本身绘制一页纸的总览图。

　　你的图表需要包含一些首要元素，此中包含，但不限于，DAO/持久层、营业逻辑/营业法则、安然功能、东西包(WSE、WCF、Ajax)、中间件、web办事、云计较API、缓存和分发。

　　当你获得架构图后，你需要进行三个专门的阐发步调：1)已知报复打击阐发，2)系统特定报复打击阐发，和3)相干性阐发。(我们从头定名了ARA的这三个步调以便用户更等闲理解)。

　　1)已知报复打击阐发很等闲理解，正如其字面意思。获得与你的架构相干的已知报复打击列表，并一一进行查抄。微软的STRIDE编制(有人将其误叫成威胁建模)就是一个很好的例子。STRIDE是棍骗、窜改、否定、信息泄漏、拒尽办事和特权晋升的缩写。这就是微软已知报复打击清单。

　　已知报复打击阐发的关头是要知道一些已有的报复打击。假定你能拟定一份设计层面的报复打击的列表，这就已成功了一半。STRIDE可能合用于把持系统供给商，而你需要按照本身的市场和本身面对的奇特的报复打击者成立本身的列表。成立这类列表的编制之一是扣问你的缝隙治理团队，看看哪些报复打击最多见。

　　当你发现列表中的某个报复打击具有相干性，计较其影响力，并思虑你该若何修复架构来降落风险。请寄望我们这里利用的是“降落”。有时辰缺点其实不需要完全解决或完全肃除，我们只需要按照特定环境将风险降落到可接管的程度便可。

　　假定可以或许找出根赋性的缺点，对企业来讲，真的很有价值。发现一个出缺点的设计，经由过程准确摆设安然节制，降落数十或数百个缝隙带来的风险，这莫非不是功德吗？我们可以经由过程输出编码来实现这一过程。

　　2)系统特定报复打击阐发侧重于按照系统的运作环境来揭穿无按照的假定、深挖歧义内容和寻觅新报复打击。这个步调需要最丰硕的经验和先天，因为安然本身是软件的新兴的属性。你知道，有时辰软件本身运行时很正常，但当它被添加到更大年夜的生态系统时，它就完全离开轨道了。这就是我们的意思。预感天然产生的后果多是很是毒手的工作。

　　在良多环境下，分化标题问题可能会有所帮忙。最起码，在这个步调中，我们可以思虑信赖建模(明白肯定信赖鸿沟)、数据敏感性建模(肯定隐私和信赖标题问题)和威胁建模(肯定报复打击者，并从报复打击者的角度考虑)。请寄望，我们这里利用的威胁建模的术语与微软的有所不合。

　　在这里，我们想夸大年夜的一种编制是综合不合的不雅点。你可否试想，两个软件架构师，一个架构，在统一个房间，会产生甚么事？提示：这里不存活着界和平。操纵很是有经验的架构师对不异系统的不合不雅点，可以或许帮忙你周全综合地解决标题问题。

　　在此步调中，寄望你所发现的报复打击及其影响。想想你该若何经由过程点窜设计来降落这类风险。

　　3)相干性阐发在于，肯定你依托的其他软件架构的运作环境。让我们面对实际吧，此刻的软件几近老是依托于他人设计和构建的组件和框架的正常运作。它们的前提前提是甚么？它们若何影响你的系统？假定框架“横行霸道”，你的设计会如何？

　　请从你正在依托的组件开端，确认这些标题问题：你依托的组件中是不是有已知缝隙？(不管是开源组件或其它，谜底凡是是必定的)。你是不是在这些框架中构建了足够的安然节制？它们真的有效吗？(不幸的是，谜底凡是是不是定的)还有其它功能或特点需要被禁用吗？(可能)。框架在默许环境下安然吗？(可能，假定你比来把持恰当的话)。

　　写下你发现的事实，思虑其影响，肯定该如何做。在完成ARA的四个步调后，你会发现你面对良多风险，也会产生良多改进设计的设法。考虑这些风险，并明白对营业的影响。然后将你发现的风险进行优先排序，提出解决方案来解决你所发现的最首要的缺点。

　　接下来有些毒手：弄清晰若何故及甚么时辰进行重大年夜的架构变动。在某些环境下，解决方案需要几年时候才能展开，对此，请不要太尽看。

　　轻量级设计审查

　　ARA听起来很等闲吗？但事实并不是如斯。因为这个过程很密集，并且触及良多专业常识，深进的ARA其实不会合用于所有你的利用。ARA是关头系统必备的架构，但对非核心系统，这并没有需要。在今后的文章中，我们将切磋应当若何解决在这些“不太首要的”系统中的缝隙标题问题。

　　修复你的缺点

　　不管你的架构审查过程是不是会带来快速的重构或利用多年的多个版本企业架构的变动，此刻是时辰让我们开端正视软件安然标题问题。我们不克不及抛却缝隙检测和用来发现和修复缝隙的东西，但与此同时，鉴于缺点也据有一半的标题问题，我们需要谨严地解决这些标题问题。