Critical Security Update
To help protect your systems, customers using NI driver software 2026 Q2 or earlier should visit ni.com/ni-pal-update and follow the recommended actions.
确保软件应用程序的安全性需要一种正式方法，以便在整个开发生命周期中融入安全思维。软件开发生命周期(SDLC)在开发开始前即开始，包括团队准备、为软件开发设置保护、遵循软件设计的最佳安全实践以及软件发布后的支持。本文为NI LabVIEW团队提供在项目中采用包含安全软件开发框架的正式SDLC的建议。
软件开发生命周期(SDLC)是用于设计、创建和维护软件（包括内置于硬件的代码）的正式或非正式方法。
每个软件团队均有其开发流程，无论是否附有正式文档。有意识的安全开发在整个过程中增加了相关活动，以减少漏洞、提高可维护性，并降低修复安全问题的成本。漏洞不仅包括编码缺陷造成的问题，还包括安全配置设置、错误的信任假设和过时的风险分析造成的问题。
在SDLC中越早解决安全问题，最终达到相同安全级别所需的工作量和成本就越少。无论使用何种SDLC模型，该原则（称为左移）都至关重要。左移原则适用于任何编程环境，包括LabVIEW－一个可用于开发安全应用程序的安全编程环境。已完成的应用程序的安全性在很大程度上取决于开发团队采用的SDLC。
关于SDLC和合规性的重要说明：大多数监管项目（例如，欧洲《网络韧性法案》(CRA)、美国网络安全成熟度模型认证(CMMC)、英国国防网络认证(DCC)等）都要求提供证据，表明系统设计遵循了类似本SDLC中的安全惯例，但这类监管项目的要求远不止一套SDLC。详细信息见这些项目的文档。
该指南主要基于NIST特别出版物800－218，安全软件开发框架(SSDF)中定义的原则和实践。SSDF为开发安全软件提供了与具体技术无关的框架，并且公认可满足美国政府软件安全相关要求。每个SSDF实践都针对LabVIEW开发团队的需求进行了解释和应用，重点是在测试、测量、自动化和工程环境中的实际实现。
本文档中提出的建议还与JKI Security Suite和微软安全开发生命周期(SDL)等其他已确立的安全开发框架和行业最佳实践进行了比较，以确保与经验证的软件安全、风险管理和软件供应链保护方法保持一致。目标是为LabVIEW组织提供将网络安全纳入其开发流程的实用路线图，同时生成客户、监管机构和政府采集项目日益需要的证据和可追溯性。
NIST 800-218中描述的过程包括以下四个软件开发方面：
在本文中，我们使用这些主题来指导LabVIEW SSDF的开发。
在开始开发之前，必须采取措施来帮助团队采用安全开发原则、完成必要的培训以及建立支持安全开发的流程和工具。该阶段需要时间来实现以下目标：
这些要求对于任何软件开发团队都是通用的，但需要调整一些步骤，以适应测试团队和LabVIEW团队。
许多测试团队与公司内部的安全团队处于隔绝状态。应与他们协调合作，建立互信关系，让他们知道你们非常重视安全问题。与您的安全团队会面，了解他们对已开发代码的要求。向他们展示项目和测试方面，并为其介绍相应流程。了解测试实验室的工作方式和面临的限制对他们很有帮助。您面临的挑战与其他IT系统不同，如果安全团队了解这些差异，将会有所帮助。
您还必须了解安全团队的关注点。了解他们必须满足哪些项目要求后，您可以将安全要求追溯至具体需求，从而更好地满足原项目的初衷。
需求跟踪是团队为交付安全代码的准备过程的重要部分。良好的跟踪流程不仅提供了存储需求的功能，还提供了这些需求的可追溯性。您的团队应能够在整个生命周期内跟踪需求：
需求定义→设计→实施→测试→缺陷修正→发布
这种可追溯性在客户审核、安全声明（如CRA）、评估（如CMMC）或供应商安全审查期间用作证据。
“GitHub问题 + 项目 + 里程碑”是大多数小型团队最常见的需求跟踪方法。其他跟踪选项包括GitLab（免费和付费）、Azure DevOps、JIRA和其他专业软件开发工具。这些工具有助于创建问题并跟踪问题直至解决问题。
在所选工具中，系统地跟踪安全需求。每项需求均应满足下列标准：
确定需求跟踪工具后，请记录流程，以便在开发中使用这些工具。在系统的整个生命周期内，使用该流程进行需求跟踪和问题跟踪。该流程可能包括以下步骤：
计划将代码模块化。该步骤在LabVIEW中尤其有用，因为用户可测试单个模块。规划模块化架构时，也应计划开发单元测试。这样可提高代码质量，并在进行更新后（甚至在系统部署后）提供验证代码的更快方法。
第三方测试工具提供了额外的价值，例如，JKI的Caraya和LUnit产品为LabVIEW团队扩展了软件测试功能。
定义检查和批准分包工作、第三方软件和开源组件的流程。流程应包括检查常见漏洞和暴露(CVE)等公共数据库，以识别所用组件中的已知漏洞。
如使用开源组件，在应用程序中使用代码前需扫描漏洞。
定义团队中的特定角色，包括安全特定角色。确定每个角色的职责和访问权限。至少应定义具有特权访问的角色（管理员），与用户角色（开发人员和操作员）分离开来。
创建适用于这些角色的安全培训。将培训分配给团队成员并跟踪培训完成情况。这些记录将作为认证审查的证据。
请考虑使用在线NI安全培训：《测试系统集成的安全注意事项》课程。
ISC2等行业认证项目提供低成本的入门级认证。这些项目对测试团队的价值在于为与安全团队通信提供通用语言。
定义SDLC后，将其提交给公司领导层，并获取他们的正式支持。该项目应至少获得负责审批安全预算的层级批准，以表明其对该项目的承诺。
组织应识别可能遇到的数据类型并创建标签系统。应考虑下列数据类型：
拥有清晰的数据管理和标签系统将使您能够妥善保护数据，对每个数据分类应用正确的限制。在开始系统开发之前由组织定义这些内容，可通过将适用的控制措施应用于正确的风险领域来节省时间。映射到现有的公司和IT标签系统将简化系统之间共享数据的方式。
确定要进行标准化安全保护的软件和驱动程序版本及配置。对于LabVIEW，请确定用于开发的版本。建立安全配置，以便安装。可参考LabVIEW安全配置指南。请访问ni.com/security，查看其他安全配置指南。
为实现可审计性并快速设置新系统，请自动化开发和构建机器的设置方式。建立基准安装并从该安装创建镜像。
创建用于整个开发过程中安全检查的工具。您需要一个静态应用程序安全测试(SAST)工具来分析源代码，而无需执行程序来查找潜在的安全漏洞。对于LabVIEW图形化代码，我们推荐使用JKI Security Suite，该套件专门设计用于对LabVIEW代码进行静态分析。或者手动执行静态代码分析，查找安全问题。
SAST工具是分析代码漏洞的重要安全工具。动态应用程序安全测试(DAST)工具也很重要，用于在测试期间扫描运行代码。软件组件分析(SCA)可识别开源库、第三方程序包和软件组件的使用，并扫描这些组件的已知漏洞和许可证问题。
有许多其他类型的工具可用于扫描代码以发现安全问题。适合项目的工具取决于您的工具集、项目的性质和使用的代码类型。在安全开发生命周期的此阶段，研究和确定团队将使用的工具非常重要。
安全开发要求以多个版本存储源代码，以便团队在代码出现问题时可以还原至旧版本。作为组织进行安全开发准备工作的一部分，应建立一个代码存储库，用于存储代码、签出用于开发的代码并维护源代码的版本控制。
在代码存储库中进行分支有利于并行开发和稳定发布。定义要在组织中使用的分支类型。这些分支类型为标准类型，但可根据需求进行调整：
请使用提供正确安全控制的存储库。确保存储库保留完整的提交文件和更改历史记录，以维持可追溯性。
确保用于开发代码的计算机遵循基本的网络安全策略。这些基本控制措施包括密码保护、恶意代码防护和其他基本网络卫生措施。关于这些基本控制，请访问https://www.acquisition.gov/far/52.204-21。
为确保可追溯性，请记录用于开发系统的计算机的配置设置。要捕捉的配置设置包括以下范例：
大多数安全项目都需要团队遵循SSDF中既定惯例的证据。建立存储库以跟踪证据，并在系统的开发和部署过程中不断对其进行更新。系统应跟踪下列项：
许多团队会执行这些安全活动，但无法证明他们执行了这些活动。合规团队希望同时看到：团队已制定流程，并且遵循这些流程。将这些文件放在同一位置将大大简化审计和合规性审查。
当组织做好安全开发代码的准备后，下一个任务是保护软件。此步骤可确保团队在开发和发布过程中保障代码安全。
在开发过程中保护软件对于任何软件都至关重要，无论使用何种编程语言。LabVIEW团队采用专业的软件开发工作流程工具时，这些团队也必须采用安全的开发流程和工具。
使用上一阶段中确定的安全代码存储库来存储和管理代码。出色的存储库不仅用于管理源代码。还应包含需求、文档、构建脚本、测试工件和发布历史记录。由于存储库包含大量代码和支持，因此使用安全的存储库非常重要－如果存储库受损，软件也会受损。
在存储库中，主分支是必须保护的关键资产。您的团队应定义并遵守代码保护策略。这些策略可能包括以下范例：
存储库还应提供从需求生成到开发再到产品发布的可追溯性。某些存储库允许对提交进行签名（例如，Git）。
存储库应通过保留软件更改记录来提供审计跟踪。更改内容、更改操作人员、更改原因、批准人员以及发布时间。此外，发布镜像应备份到安全归档中，以便即使存储库受损仍可检索代码。
SBOM提供了用于代码开发的软件和组件列表。在构建过程中生成SBOM，可确保您记录代码中使用的组件，从而简化识别和修复漏洞的过程。
从LabVIEW 2026 Q3开始，可在应用程序构建过程中生成SBOM。详细信息请参阅生成独立应用程序的软件物料清单。
代码签名为用户提供了一种机制，用于验证软件是否由已知组织生产、自发布以来是否未被修改以及是否已被批准发布。在LabVIEW应用程序中，代码签名应应用于可执行文件、安装程序、部署包、DLL、驱动程序和更新包。
按照下列说明，可在构建过程中对应用程序进行签名。也可使用微软的SignTool.exe对软件进行签名，与签名任何应用程序或文件相同。
应用程序通常需要密码、API密钥、证书、令牌、加密密钥、数据库凭证和服务帐户凭证等密钥。这些密钥提供对系统和数据的访问权限，必须在软件生命周期内受到保护。
请勿将硬编码密码、API密钥、证书或加密密钥直接写入源代码、配置文件、构建脚本或测试工具。硬编码密钥很难轮换，可能会被复制到存储库中，并且可能会通过源代码检查、备份或已部署应用程序的逆向工程而暴露。
尽可能使用安全的操作系统或受硬件保护的存储来存储密钥。安全或受保护的存储包括下列选项：
授权密钥访问时，应用最小权限原则。只有需要访问密钥的用户、系统和服务才能获取密钥。管理凭证应与用户凭证分离，并应尽可能避免共享帐户。
密码、证书、API密钥和加密密钥应根据组织策略定期更换。建立流程以定义密钥的生成方式、存储位置、可访问密钥的人员以及撤销已泄露密钥的方式。
测试系统经常使用真实的网络连接、数据库、云服务和仪器。测试团队需要在测试期间访问这些系统。尽可能使用专用的测试凭证而不是生产凭证。独立的测试环境可降低在开发和验证活动期间暴露运营系统的风险。
该阶段的重点是安全地设计、实施、测试和验证软件。为有效完成此任务，团队必须评估预期软件用途的风险和要求，并针对这些风险进行设计。最佳实践包括尽可能重用已知的安全组件、在开发过程中进行测试以及扫描开发代码中的漏洞。团队制定安全使用计划，包括使用默认安全设置。
测试和测量应用程序面临着不同于一般软件应用程序的安全挑战。LabVIEW团队应理解这些挑战并开发软件，防止应用程序受到攻击。LabVIEW提供许多固有的安全保护，但团队必须考虑可能的攻击并做好防御准备。
OWASP（开放式Web应用安全项目）是一个非营利基金会，提供免费工具、指南和标准来帮助人们构建安全的软件。OWASP提供了社区驱动的威胁建模指南；其模型提供了一系列结构化步骤，用于界定工作范围、确定威胁、制定对策和缓解措施以及评估工作。
对于测试团队来说，首先通过对话了解开发系统的预期用途和威胁。会话应涉及首席开发人员、测试架构师、系统工程师、产品所有者、网络安全代表和操作人员。
OWASP方法包含威胁列表，涵盖欺骗、篡改、抵赖、信息泄露、拒绝服务和权限提升(STRIDE)。STRIDE威胁类别可帮助团队考虑所有类型的威胁。
测试团队应借鉴他们在头脑风暴中的经验，具体研究威胁在测试环境中将如何影响系统：
将这些测试特有的风险添加到更传统的网络威胁中，将有助于确定适合测试系统的防御策略。威胁建模的输出应为一组按优先级排序的风险，以及降低这些风险所需的安全需求。这些需求将成为下文中系统设计和开发活动的输入。定期威胁检查可帮助团队识别随时间变化的新的和正在出现的威胁，并可以检查之前的威胁未捕捉到的问题。
威胁建模可识别系统的风险。下一步是将这些风险转换为可衡量的安全需求，以便在整个生命周期内实施、测试和跟踪。安全需求与功能需求同等严格。
安全需求定义了系统必须提供的安全控制或行为。良好的安全需求应具体、可测量、可测试且可追溯。下表列出了一些范例。
安全需求应分配有唯一标识符，并通过与功能需求相同的需求管理工具进行跟踪。
定义明确的安全需求应在整个开发生命周期内保持可追溯性。可追溯性表明已解决已识别的风险，并在客户审计、供应商安全评估和合规性审查期间提供宝贵的证据。
测试和测量系统的安全需求通常在企业软件项目中遭到忽视。在开发安全需求时，应使用标准安全类别，同时考虑以下数据：
由于不准确的测量和遭到损坏的测试结果可能会产生严重的业务后果，因此完整性相关的安全需求通常与保密需求同样重要。
模块化代码通过将功能隔离到具有受控接口且定义明确的组件中来限制缺陷和漏洞的影响。在良好的模块化设计中，每个模块仅开放其他模块所需的功能。这提供了更少的入口点，并减少了滥用的机会。模块化代码还具有易于测试的优点，因此更容易应用和验证代码更新。
创建模块化代码时，请考虑最低权限原则。模块只应具有执行功能所需的权限。例如，仪器通信功能无需访问数据库，因为数据库由不同的模块处理。避免将数据库句柄传递至仪器通信模块。
数据在模块间传递时，请评估通信的信任度。如适用，接受其他组件的数据前应验证源。
模块化代码应使安全检查更加容易。可以逐一审查每个模块，而不必在每次审查时都审查整个代码集。代码检查人员无需了解整个代码集即可提高单个组件的安全性。
代码模块还简化了代码重用。经过安全开发和测试的模块可重复使用到其他应用程序中，用户可确信其按预期工作。
建立一套最佳实践并遵循这些实践。代码检查应验证这些实践的合规性。虽然本文内容并不包含全面审查最佳实践，但至少应涉及这些领域：
使用公认的LabVIEW单元测试框架（NI单元测试框架、JKI Caraya或LUnit）。这些工具支持开发人员定义输入和输出，并验证代码是否正常运行。此操作无需运行整个应用程序，简化了代码验证。
单元测试可保护敏感功能（如控制昂贵的设备），因为模块可独立测试。单元测试应设计为可重复执行，并在理想情况下集成到连续集成(CI)系统中，以确保它们在代码更改时自动运行。
频繁的安全审查是建立注重安全的开发文化的重要组成部分。审查为团队提供了建立安全实践、相互学习和加强安全流程的方法。安全审查在开发前就开始进行了—审查已规划的架构和方法。然后，应在整个开发流程中继续进行审查，以确保安全开发代码。频率应根据开发规模确定；审查应足够频繁，以便在进行下游重大开发之前纠正问题。应在执行每个合并请求、拉取请求或其他重要的代码集成事件时进行审查。对于大型项目，可能额外需要定期审查。
当团队根据检查清单逐项进行审查时，安全审查的效果会大大提升。这些检查清单应由组织制定，并在每个项目开始时根据威胁和风险分析进行自定义。
除手动代码审查外，还可执行自动化代码检查。如使用持续集成和持续交付/部署(CI/CD)流程，请将安全扫描添加至接收流程中，以便在每次代码签入时扫描代码。设置其他扫描工具，每天或每周运行一次，以便在新引入的安全缺陷成为代码永久组成部分之前捕捉到它们。使用静态分析、单元测试和其他安全扫描工具，以便包含多种审查类型。
尽可能使用最新版本的开发软件驱动程序。几乎每天都会发现新的安全威胁，开发人员会将安全修复程序构建到补丁和新的软件版本中。如无法使用最新版本，请使用仍接收供应商安全更新的软件，这些更新将在系统生命周期内收到。
使用供应商提供的配置指南配置工具以确保安全。
发布产品之前，请根据项目开始时发现的威胁和风险进行测试。该列表可能包括以下测试：
由于LabVIEW是一种图形化编程语言，某些传统安全工具无法测试LabVIEW代码。JKI Security Suite等工具为LabVIEW开发人员提供了以安全为重点的静态分析功能，用于扫描LabVIEW代码并针对图形化编程语言的特定安全问题进行调整。
除非开发团队能够证明已完成威胁模型检查、关键漏洞解决、单元测试应用并通过、静态分析、SBOM生成、代码检查并签署了发布包，否则不应批准发布。实施正式的发布门禁流程可使管理层据此确认流程合规且软件安全。
开发安全软件只是流程的一部分。如应用程序部署不正确，或在安装和配置过程中移除了安全控件，安全应用程序可能会受到攻击。因此，应将部署过程视为安全软件开发生命周期的一部分，在软件发布给用户之前，制定明确的流程、审查和验证活动。
安全默认配置
应使用安全默认设置部署应用程序。用户通常认为默认设置就是推荐配置。默认情况下，禁用的任何安全敏感选项在系统生命周期内可能会一直保持禁用状态。
安全默认设置包括以下范例：
应要求用户有意识地削弱安全设置，而不是手动启用安全保护。
生产环境加固
在发布之前，请移除在开发过程中有用但在生产环境中造成不必要风险的开发成果和功能。检查应用程序是否符合下列标准：
生产系统应仅开放运行系统所需的功能。
帐户和权限管理
查看系统所需的权限，并将其分配给相应的角色。系统不应授予管理员权限，除非有明确的操作需要。服务帐户应仅配置执行预期功能所需的权限。对于基于角色的权限，请考虑：
如果系统存储敏感信息，请验证访问控制是否适当地保护了相应信息。
网络安全配置
部署前记录所有必需的网络通信。对于系统的每个连接，请考虑：
数据跨越网络边界时，必须保护数据。对于每次数据传输，请采取以下预防措施：
测试系统通常同时连接至企业网络、制造网络、云服务和仪器。理解和记录这些信任边界是一项重要的部署活动。
密钥和凭据管理
应用程序通常需要密码、API密钥、证书、令牌或加密密钥。处理这些密钥令牌时，请注意避免：
请使用下列工具或技术之一：
记录密钥的创建、存储、轮换、备份和撤销方式。请遵循此流程。
记录和审计
应用程序应记录重要的操作和安全相关事件。要记录的事件包括以下范例：
确认日志不记录任何密钥，例如密码、个人信息或机密信息，因为非预期受众可能会查看日志。
日志有助于故障排查、调查事件并证明符合客户需求和法规要求。
在可能的情况下，将应用程序日志与Windows事件查看器或Linux系统日志等平台记录机制集成，以简化监控、事件调查和合规性报告。评估发送日志至安全服务器是否有助于保护和访问。
防止审计日志在未经授权的情况下被访问和修改，并定义日志的保留时间。
发布批准
发布软件之前，请执行最终的安全检查，以验证应用程序是否符合团队的发布需求。作为最终审查的一部分，包括：
发布流程应提供证据，表明这些活动已经完成。这些证据记录在发布后应受到保护，以免被篡改，保持完整性。
代码签名和程序包完整性
用户应能够验证发布的软件是否来自预期的组织，并且自发布以来是否未进行过修改。
代码签名应应用于以下所有软件类型：
代码签名不会阻止软件修改，但可以有力地检测未经授权的修改，并保证软件来自预期的发布者。
部署验证
安装后，验证已部署的系统在预期环境中安全运行。验证活动应确认下列功能：
每当发生重大配置更改时，应执行安全验证。
部署证据
保存记录，以证明已根据定义的流程执行部署。这些记录包括以下范例：
这些记录在客户审计、供应商评估、法规审查和内部安全调查期间提供了宝贵的可追溯性。
软件漏洞是指软件设计、实施、配置或运行过程中存在的弱点、瑕疵或缺陷，可被利用来破坏系统或其数据的机密性、完整性或可用性。漏洞可能存在于团队开发的代码或软件使用的组件中。由于漏洞为恶意操作者提供了破坏系统的途径，因此修复这些漏洞并将其部署到受影响的系统非常重要。
测试行业在应对漏洞方面面存在历史性挑战。许多测试项目通过单一的前期供资模式供资，并没有针对系统持续维护的供资。这意味着测试团队没有资源更新系统，甚至无法提供安全更新。这与保持系统更新的安全需求直接冲突。
一个重大挑战是更新所需的验证量。即使软件和硬件工具无需成本，更新后的系统是否按预期运行，其验证工作也可能耗费高昂。
随着安全行业发生变化，测试行业也必须开始转型，以便在测试系统的整个生命周期内更好地进行规划并提供资金。测试团队可采取一些步骤来转向全生命周期管理方法，其中包括：
我们在ni.com/security上公布了NI产品中的漏洞，包括LabVIEW、驱动程序和其他软件。补丁也通过常见漏洞和暴露(CVE)系统加以报告。这些补丁可能修复NI工程师开发的软件代码或组件中的漏洞。访问ni.com/security注册并获取新补丁的相关通知。
SBOM也可用于自动扫描软件。如通过LabVIEW应用程序生成SBOM，可设置扫描软件检查CVE数据库中报告的问题并通知用户。有多种软件组件分析(SCA)工具可扫描SBOM并将其与CVE数据库匹配。
如最终用户发现漏洞，可直接向您报告。如问题在NI软件内部，请访问ni.com/security进行报告。
必须认真对待漏洞报告。如果用户报告问题，或软件堆栈中报告漏洞，请分析该漏洞以确定其被利用的影响和可能性。这些问题受漏洞性质以及用户使用受影响软件组件的方式的影响。如果确定存在重大攻击威胁，则需要更新软件并向最终用户发布补丁。
某些法规（例如，欧洲网络弹性法案(CRA)）要求您提供长达五年或更长时间的安全补丁。有些合同可能规定更长或更短的支持承诺。在初始项目建议书中规划此级别的支持，以避免交付项目后出现意外情况。
作为漏洞修复流程的一部分，对漏洞执行根本原因分析，以改进开发流程，从而在未来项目中消除类似问题。
安全软件开发不是在项目结束时执行的单独活动。它是一组集成在系统生命周期中的实践。通过采用本指南中介绍的原则，LabVIEW团队可以减少漏洞、提高可维护性、简化合规性工作流程并更好地保护委托给他们的系统和数据。安全是一个持续性过程，您的团队将随着时间的推移而成熟。立即开始建立可重复、可持续的流程，在产品生命周期内不断提高安全性。
| 威胁 | 安全要求 |
|---|---|
| 未授权修改测试结果 | 仅允许具有相应角色的身份验证用户修改存储的测试结果。 |
| 拦截网络流量 | 应用程序与外部系统之间的所有通信均应使用加密协议。 |
| 校准数据损坏 | 校准数据应防止在未经授权的情况下被修改，并记录所有更改。 |
| 未经授权的设备控制 | 操作行政或危险设备时，必须由经过身份验证且获得授权的用户进行操作。 |