35、集成应用安全测试工具到ALM系统实现自动化与可追溯性

最新推荐文章于 2025-10-16 17:04:11 发布

stem5

最新推荐文章于 2025-10-16 17:04:11 发布

阅读量67

点赞数

CC 4.0 BY-SA版权

分类专栏：构建安全汽车：软件安全之道文章标签：应用安全测试工具 ALM系统自动化测试

本文链接：https://blog.youkuaiyun.com/stem5/article/details/151603819

构建安全汽车：软件安全之道专栏收录该内容

39 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

集成应用安全测试工具到ALM系统实现自动化与可追溯性

1. 集成的意义与考虑因素

将应用安全测试工具与应用生命周期管理（ALM）系统集成，以实现测试自动化，能让汽车行业组织更好地管理需求可追溯性。这不仅能减少时间和精力的投入，还能确保需求、测试及测试结果等信息保持最新状态，避免可能代价高昂的人为错误。不过，要充分利用这种自动化解决方案，需要进行周全的考虑。

组织首先要明确工作流程，清楚进行相关应用安全测试所需的软件目标、需求、测试工具和设备。同时，调查将合适的应用安全测试工具与ALM系统集成过程中所需的手动步骤也很有必要。之后，组织可以进一步研究如何利用不同应用安全测试工具支持的各种应用程序编程接口（API）来实现工作流程的自动化，从而与ALM系统集成，尤其有助于实现需求可追溯性。可以考虑逐步将应用安全测试工具与ALM系统集成，优先关注那些提供合适接口且易于集成的工具。

常见的可用于汽车软件开发周期（SDLC）的自动化应用安全测试工具包括：
- 静态代码分析工具
- 软件成分分析工具
- 漏洞扫描工具
- 模糊测试工具

不同的应用安全测试方法可分为静态和动态两种，下面将分别介绍它们与ALM系统集成的具体情况。

2. 静态应用安全测试与ALM系统集成

2.1 静态代码分析

静态代码分析可以通过访问源代码或二进制文件，以静态方式对目标软件进行测试。集成静态代码分析工具与ALM系统的步骤如下：
1. 从ALM系统的测试用例中读取MISRA或AUTOSAR指南。
2. 根据测试用例信息，准备启用相应MISRA或AUTOSAR检查器的配置文件。
3. 使用配置文件启动静态代码分析工具进行扫描。
4. 扫描完成后，静态代码分析工具将测试结果上传到ALM系统。
5. 根据结果判断测试用例是否通过：若未检测到违反MISRA或AUTOSAR指南的情况，则测试用例通过；若检测到一个或多个违反情况，则测试用例失败。
6. 上传的结果中可包含扫描的软件版本、扫描的软件部分、检测到的具体指南违规情况以及包含违规的软件部分等详细信息，帮助软件开发人员更好地了解问题并进行解决。

2.2 软件成分分析

软件成分分析用于检测开源软件中已知的关键漏洞。集成软件成分分析工具与ALM系统的步骤如下：
1. 从ALM系统的测试用例中读取关于开源软件已知关键漏洞测试的信息。
2. 根据测试用例信息配置策略，例如要求开源软件不应包含任何已知关键漏洞。
3. 准备好策略配置文件后，启动软件成分分析工具进行扫描。
4. 扫描完成后，将测试结果上传到ALM系统。
5. 根据结果判断测试用例是否通过：若未检测到已知关键漏洞，则测试用例通过；若检测到一个或多个关键已知漏洞，则测试用例失败。
6. 上传的结果中可包含扫描的软件版本、扫描的软件部分、检测到的具体已知关键漏洞以及包含漏洞的开源软件组件等详细信息。

下面是静态应用安全测试与ALM系统集成的mermaid流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(从ALM系统读取测试用例信息):::process
    B --> C{测试类型}:::decision
    C -->|静态代码分析| D(准备MISRA或AUTOSAR配置文件):::process
    C -->|软件成分分析| E(配置策略文件):::process
    D --> F(启动静态代码分析工具):::process
    E --> G(启动软件成分分析工具):::process
    F --> H(扫描完成):::process
    G --> H
    H --> I(上传测试结果到ALM系统):::process
    I --> J{测试用例是否通过?}:::decision
    J -->|是| K(标记测试用例通过):::process
    J -->|否| L(标记测试用例失败，提供详细信息):::process
    K --> M([结束]):::startend
    L --> M

3. 动态应用安全测试与ALM系统集成

3.1 动态测试的前提条件

一些应用安全测试方法需要以动态方式进行，要求目标软件在被测系统（SUT）上运行，例如漏洞扫描和模糊测试。在进行任何动态测试之前，需要考虑将目标软件构建并刷入SUT的过程，并且进行功能测试以确保目标软件正常工作。因此，实现持续应用安全测试自动化的前提是构建、刷入SUT和功能测试步骤能够自动化。这些步骤可能因目标软件和目标系统而异。

3.2 漏洞扫描

与ALM系统集成漏洞扫描工具的步骤如下：
1. 从ALM系统的测试用例中读取关于目标系统已知服务关键漏洞测试的信息。
2. 根据测试用例信息准备配置文件，例如指定目标IP地址、目标端口、扫描模式和要使用的漏洞数据库。
3. 使用配置文件启动漏洞扫描工具进行扫描。
4. 扫描完成后，将测试结果上传到ALM系统。
5. 根据结果判断测试用例是否通过：若未检测到关键漏洞，则测试用例通过；若检测到一个或多个关键漏洞，则测试用例失败。
6. 上传的结果中可包含扫描的软件版本、扫描的目标系统端口或服务、检测到的具体关键漏洞以及包含漏洞的服务等详细信息。

3.3 模糊测试

模糊测试的集成步骤如下：
1. 从ALM系统的测试用例中读取需要进行模糊测试的接口或协议信息。
2. 根据测试用例信息准备配置文件或测试计划，例如指定目标地址、要模糊测试的协议、模糊测试用例数量和模糊消息中的异常类型等。
3. 使用配置文件或测试计划启动模糊测试工具进行测试。
4. 测试完成后，将测试结果上传到ALM系统。
5. 根据结果判断测试用例是否通过：若没有失败的模糊测试用例，则测试用例通过；若检测到一个或多个失败的模糊测试用例，则测试用例失败。
6. 上传的结果中可包含测试的软件版本、进行模糊测试的目标系统协议或接口、执行的模糊测试用例数量以及失败的模糊测试用例等详细信息。

3.4 动态测试的挑战

在进行动态应用安全测试时，组织还需要考虑一些额外的挑战：
- 时间问题 ：在通过Wi-Fi和蓝牙等进行漏洞扫描或模糊测试时，需要考虑测试环境的时间问题。
- 外部输入和监控 ：某些情况下，SUT可能需要外部输入才能正常工作，并且需要额外的监控功能来检测动态测试期间SUT上发生的异常。
- 处理失败的测试用例 ：SUT可能因漏洞扫描或模糊消息而停止工作，需要重新启动或恢复到可测试状态。不同的SUT和安全应用测试方法处理失败测试用例的方式可能不同。
- 手动输入 ：在某些情况下，动态测试可能需要手动输入到SUT来控制目标应用程序或对SUT进行电源循环。

下面是动态应用安全测试与ALM系统集成的mermaid流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(构建目标软件):::process
    B --> C(将软件刷入SUT):::process
    C --> D(进行功能测试):::process
    D --> E{功能测试是否通过?}:::decision
    E -->|是| F(从ALM系统读取测试用例信息):::process
    E -->|否| G(修复问题，重新开始):::process
    G --> B
    F --> H{测试类型}:::decision
    H -->|漏洞扫描| I(准备漏洞扫描配置文件):::process
    H -->|模糊测试| J(准备模糊测试配置文件或测试计划):::process
    I --> K(启动漏洞扫描工具):::process
    J --> L(启动模糊测试工具):::process
    K --> M(扫描/测试完成):::process
    L --> M
    M --> N(上传测试结果到ALM系统):::process
    N --> O{测试用例是否通过?}:::decision
    O -->|是| P(标记测试用例通过):::process
    O -->|否| Q(标记测试用例失败，提供详细信息):::process
    P --> R([结束]):::startend
    Q --> R

4. 其他工具与ALM系统的集成

除了应用安全测试工具，组织还可以考虑将软件开发周期中使用的其他工具和系统与ALM系统集成。例如，将Jira等缺陷跟踪系统与ALM系统集成。这样，静态代码分析工具可以根据扫描目标源代码的结果自动创建相关的Jira工单，然后可以从ALM系统管理这些工单，了解有多少工单仍处于开放状态、多少已经解决等。通过这种方式，可以实现从需求到测试用例，再到静态代码分析工具的实际结果，最后到基于测试结果创建的具体Jira工单的可追溯性。

同时，利用ALM系统中的测试覆盖功能，组织可以根据应用安全测试工具的实际测试结果，了解哪些安全需求已经得到满足。通过观察Jira工单的关闭和开放情况，可以跟踪满足特定需求的进度，这有助于规划、调度以及需求可追溯性管理。

5. 集成的注意事项

在将应用安全测试工具与ALM系统集成并实现安全测试自动化时，必须考虑控制和沟通不同工具所需的API和方法，以实现简单直接的集成。可能会遇到一些情况，例如组织使用具有有限API的遗留系统或工具，或者存在复杂的测试环境，需要进一步考虑如何集成这些工具。此外，还可能存在组织方面的挑战，例如不同的团队和流程负责需求管理和测试，以及系统和工具的所有者不同。

总之，将应用安全测试工具集成到ALM系统中，实现自动化和可追溯性，对于汽车行业组织有效开发和测试软件、验证相关安全需求的满足情况具有重要意义。随着汽车行业网络安全标准和法规的不断发展，对安全软件开发的要求越来越高，这种集成将变得越来越重要。

6. 集成带来的优势与价值

6.1 需求可追溯性的实现

将应用安全测试工具集成到ALM系统后，能够实现从安全需求到测试用例，再到实际测试结果的完整可追溯性。具体表现如下：
- 清晰的需求跟踪 ：可以轻松地将每个安全需求与对应的测试用例关联起来，并且能够查看该需求是否通过测试用例得到了验证。例如，当一个安全需求要求软件的某个模块不能存在特定的漏洞时，通过集成的系统可以直接查看针对该需求的测试用例是否执行成功，以及测试结果是否符合要求。
- 提供证据支持 ：实际的测试结果可以作为满足安全需求的有力证据。在面对行业标准和法规的审核时，能够快速准确地提供相关的测试数据，证明软件的安全性符合要求。比如在满足ISO/SAE 21434和UNECE WP.29 Cybersecurity等标准时，可追溯的测试结果能起到关键作用。

6.2 提高开发和测试效率

自动化测试流程 ：集成实现了测试流程的自动化，减少了人工干预的时间和精力。原本需要手动执行的测试步骤，现在可以通过ALM系统自动触发应用安全测试工具进行测试。例如，在软件代码更新后，系统可以自动启动静态代码分析工具对代码进行扫描，大大提高了测试的及时性。
及时发现和解决问题 ：测试结果能够及时反馈到ALM系统中，开发人员可以迅速了解软件中存在的安全问题，并进行修复。同时，通过对测试结果的分析，还可以发现一些潜在的问题，提前进行预防和处理。

6.3 更好的项目管理和规划

整体进度把控 ：通过ALM系统可以全面了解项目的安全测试进度，包括哪些测试用例已经执行、哪些还未执行，以及测试结果的统计情况。例如，可以清晰地看到有多少测试用例通过、多少失败，从而对项目的整体安全状况有一个直观的认识。
资源合理分配 ：根据测试结果和项目进度，合理分配开发和测试资源。对于存在较多安全问题的模块，可以投入更多的资源进行修复和测试；对于安全状况良好的模块，可以适当减少资源投入。

7. 实际案例分析

为了更好地说明将应用安全测试工具集成到ALM系统的实际效果，下面以一个汽车软件开发项目为例进行分析。

7.1 项目背景

该项目是开发一款汽车的车载信息娱乐系统，涉及到大量的软件代码和复杂的功能模块。为了确保系统的安全性，需要对软件进行全面的安全测试，并且要满足相关的行业标准和法规要求。

7.2 集成方案实施

选择合适的工具 ：选择了静态代码分析工具、软件成分分析工具、漏洞扫描工具和模糊测试工具，并将它们集成到ALM系统中。
配置测试流程 ：根据项目的安全需求，在ALM系统中配置了相应的测试用例和测试计划。例如，针对静态代码分析，配置了MISRA和AUTOSAR检查规则；针对软件成分分析，设置了检测开源软件关键漏洞的策略。
自动化触发 ：利用自动化服务器，在软件代码更新后自动触发相应的测试工具进行测试。例如，当开发人员提交新的代码到代码库时，自动化服务器会自动启动静态代码分析工具对代码进行扫描。

7.3 实施效果

发现大量安全问题 ：在项目开发过程中，通过集成的测试工具发现了许多潜在的安全问题。例如，静态代码分析工具检测到代码中存在一些违反MISRA和AUTOSAR规则的情况，软件成分分析工具发现了开源软件中存在的关键漏洞。
提高开发效率 ：由于测试流程的自动化，开发人员可以及时得到测试结果，快速修复问题，大大缩短了开发周期。同时，通过对测试结果的分析，开发人员可以总结经验教训，避免在后续的开发中出现类似的问题。
满足法规要求 ：在项目交付时，能够提供完整的测试报告和可追溯的测试结果，证明系统的安全性满足了ISO/SAE 21434和UNECE WP.29 Cybersecurity等行业标准和法规的要求。

下面是该项目集成实施的mermaid流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([项目开始]):::startend --> B(选择应用安全测试工具):::process
    B --> C(集成到ALM系统):::process
    C --> D(配置测试用例和计划):::process
    D --> E(开发人员提交代码):::process
    E --> F(自动化服务器触发测试):::process
    F --> G{测试是否通过?}:::decision
    G -->|是| H(继续开发):::process
    G -->|否| I(开发人员修复问题):::process
    I --> E
    H --> J(项目交付):::process
    J --> K([项目结束]):::startend

8. 未来发展趋势

随着汽车行业的不断发展和网络安全形势的日益严峻，将应用安全测试工具集成到ALM系统的技术也将不断发展和完善。以下是一些可能的未来发展趋势：

8.1 更智能化的测试工具

自动学习和优化 ：测试工具将具备自动学习的能力，能够根据历史测试数据和结果，自动优化测试策略和方法。例如，静态代码分析工具可以学习开发人员的编码习惯，自动调整检查规则，提高检测的准确性。
智能漏洞预测 ：利用人工智能和机器学习技术，测试工具可以预测软件中可能存在的漏洞，提前进行防范和处理。例如，通过对大量软件漏洞数据的分析，预测某个模块可能存在的安全风险。