软件安全性级别怎么定，影响哪些验证

结论：级别由软件失效可能导致的伤害程度决定，不是由软件复杂度决定

软件安全性级别的定级依据是：如果软件失效（包括失效引发的危险情况），可能导致什么程度的伤害。

注意两点：

一是看伤害程度，不是看软件多复杂。 一个功能简单但控制输出的软件，级别可能高于一个功能复杂但只做数据展示的软件。

二是看失效后的后果，且要考虑外部风险控制措施。 如果软件失效后有硬件层面的保护能阻止伤害，定级时可以考虑这个保护措施的作用。

定级结果决定了后续的文档要求和验证深度，所以定错了，要么工作量过大，要么不足以支撑审查。

定级的思路

第一步，识别软件失效可能导致的危险情况。 与风险分析中的危害识别相同。

第二步，评估危险情况可能造成的伤害程度。 不严重、严重、还是可能致死。

第三步，考虑外部风险控制措施。 软件之外的措施（硬件保护、机械限位、操作流程、使用者可察觉并纠正）能否降低伤害。

第四步，确定级别。 按剩余的伤害程度定级。

第五步，记录定级过程和依据。

第三步是定级的关键，也是最容易被质疑的地方。 声称有外部控制措施而降低级别时，必须说明该措施是什么、它如何独立于软件、以及它的有效性如何验证。如果所谓的外部措施本身也依赖软件，那它不构成独立的控制。

各级别的差异

「可追溯性」是高级别的重点要求。 每条需求要能追溯到设计、到实现、到验证用例、到验证结果。这条链完整，审查时才能确认每个需求都被验证过。

定级对验证的影响

验证的深度。 高级别需要单元级、集成级、系统级的多层验证；低级别可能只需系统级。

验证的覆盖率。 高级别对代码覆盖或需求覆盖有更高要求。

文档的详细程度。 高级别需要详细设计文档。

第三方组件的处理。 高级别对第三方组件的要求更严——来源、版本、已知问题、以及是否需要额外的验证。

变更控制的严格程度。 高级别的变更需要更完整的影响分析和回归验证。

「回归验证的范围」在高级别产品上工作量明显。 每次软件更新都要评估影响并做相应的回归验证，而不是只测改动的部分。

常见的定级问题

按复杂度定级。 把复杂的软件定高级别，简单的定低级别，这个依据是错的。

外部控制措施论证不足。 声称有保护但说不清楚保护是什么、如何独立。

未考虑失效的组合。 只考虑单一功能失效，未考虑多个功能同时异常。

定级与风险分析不一致。 风险文件说某个软件功能失效后果严重，定级却很低。

未按级别配套文档。 定了高级别但文档按低级别准备。

变更后未重新定级。 软件增加了新功能，可能改变级别。

「定级与风险分析不一致」是审查中最容易被发现的问题，因为两份文件放在一起一对比就看出来了。建议定级直接从风险分析的结论推导，并在两份文件之间建立引用关系。

分级的粒度

一个产品的软件不一定只有一个级别：

按软件项分级。 不同的软件项（模块、组件）可以有不同级别。

隔离的论证。 如果高级别部分与低级别部分之间有有效隔离，可以分别定级。

隔离的要求。 隔离措施要能防止低级别部分的失效影响高级别部分。

整体默认。 没有有效隔离时，整个软件按其中最严的那一级处理。

「隔离」可以显著降低工作量，但隔离措施本身要经过论证和验证。声称隔离而实际上模块之间有数据交换或共享资源，隔离就不成立。

第三方组件的处理

高级别产品对第三方组件的要求包括：

清单。 所有第三方组件及其版本。

来源与维护状态。 组件是否仍在维护、是否有安全更新。

已知问题。 已知的缺陷和漏洞。

使用方式。 使用了组件的哪些功能。

验证。 对所使用功能的验证，或者供方提供的验证证据。

风险控制。 对组件已知问题的控制措施。

「使用了哪些功能」这一点有实际意义。 一个大型库可能只用到其中很小一部分功能，验证范围可以聚焦在实际使用的部分，而不必覆盖整个库。

定级的记录怎么写

定级过程应当形成文档，建议包含：

软件项清单。 产品包含哪些软件项。

每项的功能说明。 这个软件项做什么。

失效的危害分析。 失效可能导致什么。

外部控制措施。 有什么措施、如何独立、如何验证。

定级结论。 每项的级别。

隔离说明。 如果分别定级，隔离措施是什么。

引用关系。 与风险文件的对应。

这份文档在审查中会被重点看，因为它决定了后续所有软件工作的深度是否恰当。

级别变化的触发

以下情况应当重新评估级别：

增加了新的软件功能；软件承担了原来由硬件承担的功能；外部控制措施被移除或削弱；预期用途扩展；风险分析更新后危害评估改变；以及软件架构重构导致隔离关系改变。

「软件承担了原来由硬件承担的功能」是容易被忽略的触发因素。 出于成本或灵活性考虑用软件替代硬件保护，这个改动可能显著提高软件的级别。

我们的做法

承接含软件产品的委托时，我们会了解委托方的定级结论及其依据。如果定级与我们对产品风险的理解有出入，会先讨论清楚 ——因为定级决定了验证的深度，定低了做出来的验证可能支撑不了审查。

对于声称有外部风险控制措施而降低级别的情形，我们会关注该措施是否真的独立于软件，并建议对该措施做实际验证 ——设计文档上写有保护，与实测保护确实动作，是两回事。

如果你在做软件相关的准备，不确定定级怎么定、验证做到什么深度，可以把软件功能和风险分析发过来一起讨论，或者直接联系：132 4819 8029。能力范围见服务介绍，流程见检测流程，更多内容见知识库。

English version

Conclusion. Software safety classification rests on what degree of harm could result if the software fails, including hazardous situations arising from failure. Two points follow. First, the criterion is harm rather than software complexity: simple software controlling an output may classify higher than complex software that only displays data. Second, the criterion is the consequence of failure taking account of external risk controls: where hardware protection would prevent harm after software failure, that protection can be considered in classification. The classification determines documentation requirements and verification depth, so getting it wrong means either excessive work or work insufficient to support review.

How to classify. Identify the hazardous situations software failure could cause, the same exercise as hazard identification in risk analysis. Assess the degree of harm those situations could produce, whether non-serious, serious or potentially fatal. Consider external risk controls, meaning whether measures outside the software, such as hardware protection, mechanical limits, operating procedures or a user able to notice and correct, would reduce the harm. Determine the class from the residual harm. And record the process and basis. The third step is both the key to classification and the most frequently challenged: where a lower class is claimed on the strength of external controls, the measure must be described, its independence from the software explained and its effectiveness verified. Where the supposed external measure itself depends on the software, it does not constitute an independent control.

Differences between classes. Requirements documentation moves from basic to detailed and traceable. Architectural design moves from a brief description to detailed design documentation. Detailed design may not be required at lower classes and is required at higher. Unit verification likewise. Integration verification moves from basic to detailed. System verification is required throughout, more comprehensively at higher classes. Traceability moves from basic to complete traceability from requirement to verification. And configuration management is required throughout, more strictly at higher classes. Traceability is the key requirement at higher classes: each requirement must trace to design, to implementation, to verification cases and to results. A complete chain is what lets a reviewer confirm that every requirement was verified.

Effect on verification. Verification depth increases, with higher classes needing unit, integration and system level verification while lower classes may need only system level. Coverage requirements increase, whether code or requirement coverage. Documentation detail increases, with detailed design required at higher classes. Third-party component treatment becomes stricter, covering provenance, version, known issues and whether additional verification is needed. And change control tightens, with higher classes requiring fuller impact analysis and regression verification. Regression scope is a noticeable workload at higher classes, since every software update requires assessing the impact and verifying accordingly rather than testing only what changed.

Common classification problems. Classifying by complexity, assigning high classes to complex software and low to simple, which is the wrong criterion. Inadequate justification of external controls, claiming protection without explaining what it is or how it is independent. Ignoring combinations of failures, considering single functional failures only. Inconsistency with risk analysis, where the risk file describes a software function's failure as serious while the classification is low. Documentation not matching the class, with a high class assigned and documentation prepared to a lower one. And no reclassification after change, when new functions may alter the class. Inconsistency with risk analysis is what reviewers find most readily, since placing the two documents side by side reveals it. Derive the classification directly from the risk analysis conclusions and cross-reference the two documents.

Granularity of classification. A product's software need not carry a single class. Software items such as modules and components can be classified individually. Where effective segregation exists between higher and lower class parts, they can be classified separately. Segregation must prevent failure in the lower class part from affecting the higher class part. And absent effective segregation, the whole software takes the highest class. Segregation can reduce workload substantially, but the segregation measures themselves must be justified and verified. Claiming segregation while modules in fact exchange data or share resources does not establish it.

Third-party components. At higher classes, requirements cover a list of all components and versions; their provenance and maintenance status, meaning whether still maintained and whether security updates exist; known issues, meaning known defects and vulnerabilities; how they are used, meaning which of the component's functions are exercised; verification of the functions used, or evidence supplied by the provider; and risk controls for known issues. How they are used carries practical significance: a large library may contribute only a small part of its functionality, and verification can focus on what is actually used rather than covering the whole library.

How we handle it. For products containing software we establish the client's classification and its basis. Where it differs from our understanding of the product's risk we resolve it first, since classification determines verification depth and a classification set too low produces verification that cannot support review. Where a lower class is claimed on the strength of external risk controls we attend to whether the measure is genuinely independent of the software and suggest verifying it in practice: design documentation stating that protection exists and measurement showing that it operates are two different things.

Send us the software functions and risk analysis and we will work through classification and verification depth. Phone or WeChat: +86 132 4819 8029.