ni.com is currently undergoing scheduled maintenance.
Some services may be unavailable at this time. Please contact us for help or try again later.
軟體應用程式的安全機制必須採用正式方法，才能在整個開發生命週期中加入安全的思維模式。此軟體開發生命週期 (SDLC) 在開發開始前便著手準備團隊、為軟體開發建立保護措施、在軟體設計中遵循最佳安全實務，以及在發行後支援軟體。此篇技術文章為 NI LabVIEW 團隊提供相關建議，協助在其專案中採用納入安全軟體開發架構的正式 SDLC。
軟體開發生命週期 (SDLC) 是一種正式或非正式的方法，適用於設計、建立與維護軟體 (包括內建於硬體中的程式碼)。
無論是否有正式記錄，每個軟體團隊都有開發流程。預期的安全開發可在整個流程中增加活動，以減少漏洞、提升維護功能，並降低修正安全問題的成本。漏洞不僅包含編碼故障所造成的錯誤，也包含安全設定、不正確的信任假設以及過時的風險分析所造成的弱點。
在 SDLC 中越早處理安全性，最終達到相同安全程度所需的投入心力與成本就越少。這項稱為左移的原則，無論採用何種 SDLC 模型都至關重要。左移原則適用於任何程式設計環境，包括 LabVIEW—這是一種可用於開發安全應用程式的安全程式設計環境。完整應用的安全性大部分取決於開發團隊採用的 SDLC。
有關 SDLC 與法遵的重要須知：多數法規計畫，例如，歐洲網路韌性法案 (CRA)、美國網路安全成熟度模型認證 (CMMC)、英國國防網路認證 (DCC) 等，都要求提供證據證明系統是依循本 SDLC 所述的安全實務設計，但這些計畫要求的內容遠不僅是 SDLC。如需詳細資料，請參閱這些計畫的說明文件。
本指南主要以 NIST Special Publication 800-218 安全軟體開發架構 (SSDF) 中定義的原則與實務為基礎，該架構為開發安全軟體提供技術中和的架構，且廣為公認，可支援美國政府軟體的安全需求。各項 SSDF 實務均已針對 LabVIEW 開發團隊的需求加以解讀與應用，並著重於在測試、量測、自動化與工程環境中的實際執行。
本文件中的建議也與其他既有的安全開發架構與業界最佳實務進行比較，包括 JKI Security Suite 與 Microsoft Security Development Lifecycle (SDL)，以確保與備受肯定的軟體安全性、風險管理與軟體供應鏈保護方法保持一致。其目標是為 LabVIEW 組織提供實用的規劃藍圖，以便將網路安全整合至其開發流程中，同時產生客戶、監管機構與政府採購計畫越來越需要的資料與可追蹤性。
NIST 800-218 所描述的流程涵蓋以下四個軟體開發領域：
本文以這些主題指導 LabVIEW SSDF 的開發作業。
在開始開發前，請務必採取措施來協助您的團隊採用安全開發原則、完成必要的教育訓練，並建立能支援安全開發的流程與工具。此階段包含花時間達成下列目標：
這些需求對任何軟體開發團隊而言都是通用條件，但必須採取一些步驟才能針對測試團隊與 LabVIEW 團隊進行調整。
許多測試團隊與其公司的安全團隊相互隔離。與他們協調建立信任關係，讓他們了解您認真對待安全。與安全團隊會議，了解他們對開發程式碼的需求。向他們展示您的專案與測試領域，並引導他們了解您的流程。了解測試實驗室運作方式並了解您所面臨的限制，對他們有幫助。相較於其他 IT 系統，您的挑戰將與眾不同，如果安全團隊了解這些差異，即可助您一臂之力。
您也必須了解安全團隊的顧慮。當您了解他們必須遵循哪些計畫時，便能將安全指令追溯至相關需求，並能更妥善地達成原始計畫的目的。
需求追蹤是讓團隊準備好交付安全程式碼的重要環節。相較於儲存需求，良好的追蹤流程可以確保這些需求的可追蹤性。您的團隊應該能夠追蹤整個生命週期的需求：
需求定義 → 設計 → 實作 → 測試 → 瑕疵修復 → 發行
這種可追蹤性可作為客戶稽核、安全聲明 (如 CRA)、評估 (如 CMMC) 或供應商安全審查時的證據。
GitHub Issues + Projects + Milestones 是大多數小型團隊最常見的需求追蹤方式。其他追蹤選項包括 GitLab (含免費與付費層級)、Azure DevOps、JIRA，以及其他專業軟體開發工具。這些工具能支援您建立問題，並追蹤問題是否解決。
在所選工具內，系統地追蹤安全需求。每項需求都應符合下列條件：
確認需求追蹤工具之後，請記錄您的流程，將這些工具納入開發階段。在整個系統生命週期中，使用流程追蹤需求與問題。您的流程可能包含下列步驟：
規劃讓您的程式碼採用模組化設計。這項步驟對於 LabVIEW 特別有幫助，因為您可以測試個別模組。當您規劃模組化架構時，也可規劃開發單元測試。這些做法可提升程式碼品質，並提供更快速的方法，在進行更新後驗證程式碼，即使系統已部署亦然。
第三方測試工具能發揮額外價值；例如 JKI 的 Caraya 與 LUnit 產品可擴充 LabVIEW 團隊的軟體測試作業。
定義檢查與核准分包作業、第三方軟體與開放原始碼元件的流程。您的流程應包含檢查常見漏洞與暴露 (CVE) 等公開資料庫，以便找出您所使用元件中的已知漏洞。
若您使用開放原始碼元件，您有責任在應用程式中使用該程式碼之前掃描漏洞。
定義團隊中的特定角色，包括安全性特定角色。確認每個角色的職責與權限。至少應將具有授權的存取權限角色 (管理員) 與使用者角色 (開發人員與操作人員) 分開定義。
建立適用於這些角色的安全訓練。將教育訓練分配給團隊成員，並追蹤訓練完成情形。這些記錄可做為憑証檢視的證據。
考慮使用線上提供的 NI 安全教育訓練：測試系統整合的安全考量課程。
ISC2 等業界認證方案提供低價位入門級憑證。這些計畫對測試團隊的價值，在於提供與安全團隊溝通時共通的語言。
定義 SDLC 之後，請向公司領導團隊呈現並取得正式支援。此計畫至少應由核准安全預算的層級核准，以展現他們對計畫的承諾。
身為組織，您可以找出可能會遇到的資料類型，並建立標籤系統。您應考慮下列資料類型：
擁有明確的資料管理與標籤系統，即可適當保護資料，並對每個資料分類套用適當的限制。在開始系統開發前於組織層級定義此這些分類，可將適當控制措施套用至正確的風險領域，進而節省時間。透過對應現有的企業與 IT 標籤系統，即可簡化系統之間的資料共用方式。
確認您需要標準化的軟體與驅動程式版本與設定，以確保安全性。針對 LabVIEW，請辨別用於開發的版本。針對安裝作業建立安全設定。您可以依循 LabVIEW 安全設定指南進行。如需其他安全設定指南，請見 ni.com/security。
為了提高可稽核性並快速設定新系統，請將開發與建置機器的設定方式自動化。建立基準安裝，並依該安裝建立映像檔。
建立於整個開發過程中用於進行安全檢查的工具。您需要使用靜態應用安全測試 (SAST) 工具來分析原始碼，而不需執行程式以找出潛在的安全漏洞。針對 LabVIEW 圖形化程式碼，建議使用專為提供 LabVIEW 程式碼靜態分析而設計的 JKI Security Suite。或者，您也可以手動執行靜態程式碼分析，尋找安全問題。
SAST 工具是分析程式碼漏洞的重要安全工具之一。動態應用安全性測試 (DAST) 工具也很重要，可在測試期間掃描執行中的程式碼。軟體組合分析 (SCA) 可找出開放原始碼函式庫、第三方套件與軟體元件的使用情形，並掃描這些元件的已知漏洞與授權問題。
還有許多其他類型的工具可用於掃描程式碼中的安全問題。專案適用的工具取決於您的工具集、專案的特性，以及所使用的程式碼類型。在安全開發生命週期的這個階段，重要的是研究並確認團隊將使用的工具。
安全開發需要儲存原始碼 (包含多個版本)，以便團隊可以在發生程式碼故障時回復至舊版。為讓組織做好安全開發的準備，請建立程式碼儲存區，用於儲存程式碼、簽出程式碼以供開發，以及維護原始碼的版本控制。
在程式碼儲存區中進行分支，有助於平行開發並穩定發佈。定義您將在組織中使用的分支類型。下列分支類型為標準類型，但可依您的需求調整：
使用提供合適安全控制功能的儲存區。確保儲存區可保留完整的提交檔案記錄，以及可追蹤的變更。
確保用於開發程式碼的電腦遵循基本的網路安全政策。這些基本控制措施包括密碼保護、惡意程式碼保護，以及其他基本的網路安全衛生措施。關於這些基本控制措施的範例，請見 https://www.acquisition.gov/far/52.204-21。
為了確保可追蹤性，需記錄用來開發系統的電腦設定。應記錄的設定包括下列範例：
多數安全計畫皆須證明您的團隊遵循 SSDF 所訂立的措施。建立儲存區以追蹤證據，並在系統開發與部署期間持續更新。系統應追蹤下列項目：
許多團隊執行這類安全活動但無法證明已經進行過這類活動。合規團隊會想要同時了解：您的團隊是否有正確的流程，以及您是否遵循這些流程。將這些文件集中會極大簡化稽核與合規性檢視作業。
組織準備好安全地開發程式碼後，下一個工作就是保護軟體。此步驟可確保團隊在開發與發佈期間，保護程式碼安全。
無論使用哪一種程式設計語言，在開發流程中都必須保護軟體。由於 LabVIEW 團隊採用專業的工作流程工具進行軟體開發，這些團隊也必須採用安全的開發流程與工具。
使用先前階段所指定的安全程式碼儲存庫，儲存與管理您的程式碼。良好的儲存區不僅能管理原始碼。同時也包含需求、使用說明、建置指令碼、測試成品與發行記錄。由於儲存區包含大量的程式碼與支援，因此使用安全儲存區非常重要；如果儲存區遭到入侵，您的軟體就會受到入侵。
在儲存區中，您的主要分支是必須受到保護的重要資產。您的團隊應定義並遵循保護程式碼的相關政策。這些政策可能包含下列範例：
儲存區也應提供可追蹤性，從需求產生階段、開發階段到產品發佈階段，一應俱全。部分儲存庫允許對提交記錄簽署 (例如 Git)。
儲存區應記錄軟體變更，以提供稽核追蹤。變更内容、變更人、變更原因、核准人，以及發行時間此外，版本映像檔應該會備份至安全封存區，即使儲存區遭到入侵，也能檢索程式碼。
SBOM 提供用於開發程式碼的軟體與元件清單。在建置流程中產生 SBOM，可確保您擁有程式碼所使用元件的記錄，進而簡化辨識與修補漏洞的流程。
從 LabVIEW 2026 Q3 開始，您可在應用建置流程中產生 SBOM。如需詳細資訊，請參閱為獨立應用程式產生軟體材料清單。
程式碼簽署機制可協助使用者確認軟體是由已知組織生產、發佈後尚未修改，且已通過核准發佈。在 LabVIEW 應用中，應將程式碼簽署套用至可執行檔、安裝程式、部署組合、DLL、驅動程式與更新組合。
您可以在建置流程中按照下列指示簽署應用程式。您也可以使用 Microsoft 的 SignTool.exe 簽署軟體，就像簽署任何應用程式或檔案一樣。
應用程式經常需要密碼、API 金鑰、憑證、權杖、加密金鑰、資料庫認證資訊及服務帳戶認證資訊等秘密資訊。這些秘密資訊可供存取系統與資料，並且必須在整個軟體生命週期内受到保護。
切勿將密碼、API 金鑰、憑證或加密金鑰以硬式編碼方式直接寫入原始碼、設定檔、建置指令碼或測試公用程式。硬式編碼的秘密資訊難以輪替，可能被複製到儲存庫中，且可能透過原始碼審查、備份或對已部署應用程式進行反向工程而外洩。
盡可能使用安全的作業系統或受硬體保護的儲存機制來儲存秘密資訊。安全或受保護儲存機制範例包括下列選項：
在授予秘密資訊存取權限時，應使用最少權限原則。只有需要存取某項秘密資訊的使用者、系統與服務，才應能取得該秘密資訊。管理員憑證與使用者憑證應分開，而且應盡可能避免共用帳號。
應依組織政策定期更換密碼、憑證、API 金鑰與加密金鑰。建立流程，用以定義秘密資訊的產生方式、儲存位置、可存取秘密資訊的人員，以及秘密外洩時如何撤銷。
測試系統經常使用實際的網路連線、資料庫、雲端服務與儀器。測試團隊在測試期間需要存取這些系統。盡可能使用專屬的測試憑證，而非量產憑證。分隔測試環境可降低在開發與驗證活動期間暴露營運系統的風險。
此階段著重於安全地設計、實作、測試及驗證軟體。為了有效執行這項工作，團隊必須評估預期軟體使用風險與需求，並針對這些風險進行設計。最佳實務包含盡可能重複使用已知安全元件、在開發階段進行測試，以及掃描開發程式碼以找出漏洞。團隊應規劃安全使用方式，包括採用安全預設設定。
測試與量測應用所面臨的安全挑戰，與一般軟體應用不同。LabVIEW 團隊具備條件了解這些挑戰，並開發能防禦針對其應用程式之攻擊的軟體。LabVIEW 提供許多固有的安全防護措施，但團隊必須考慮可能的攻擊並準備防禦措施。
OWASP (Open Worldwide Application Security Project) 是一個非營利機構，提供免費的工具、指南與標準，協助使用者建立安全的軟體。OWASP 提供社群驅動的威脅建模指南；其模型提供一系列結構化步驟，可協助您界定工作範圍、判定威脅、判定因應與緩解措施，以及評估工作成果。
對測試團隊而言，這一切始於一場討論，以了解所開發系統的預定用途及可能面臨的威脅。當中應包含首席開發人員、測試架構工程師、系統工程師、產品所有者、網路安全代表與營運人員。
OWASP 方法包含威脅清單，包括偽造、竄改、否認、資訊洩露、阻斷服務及權限提升 (STRIDE)。竄STRIDE 威脅類別可引導團隊考量各種類型的威脅。
測試團隊應根據自身在腦力激盪工作階段中的經驗，具體了解各種威脅對測試環境中的系統會造成什麼樣的影響：
若將這些測試特定風險，與傳統的網路威脅一併納入考量，將有助於針對測試系統找出合適的防禦策略。威脅建模的輸出應該是排定優先順序的風險，以及降低這些風險所需的安全需求。這些需求會成為下一節所說明的系統設計與開發活動的相關輸入。定期進行威脅審查，可協助團隊找出新興或與逐漸浮現的威脅，並涵蓋檢視先前威脅未發現的問題。
威脅建模可辨別系統風險。下一步是將這些風險轉換為可衡量的安全需求，並可在整個生命週期中實作、測試及追蹤這些需求。安全需求應與功能需求同樣嚴謹。
安全需求定義系統必須提供的安全控制或行為。良好的安全需求應具體、可衡量、可測試且可追蹤。下表列出一些範例。
安全需求應指派專屬識別符，並透過適用於功能需求的相同需求管理工具進行追蹤。
明確定義的安全需求，應能在整個開發生命週期中追蹤。可追蹤性可證明已發現的風險已因應，並在客戶稽核、供應商安全評估與監管審查期間提供寶貴的證據。
測試與量測系統具有在企業軟體專案中經常被忽略的安全需求。開發安全需求時，請使用標準安全類別，同時也請考量下列資料：
由於不準確的量測與損毀的測試結果可能會帶來嚴重的業務後果，因此，完整性的安全需求通常與機密性的需求一樣重要。
模組化程式碼可將功能與受控介面的明確定義元件隔離，進而減少瑕疵與漏洞造成的影響。在良好的模組化設計中，每個模組只會暴露其他模組所需的功能。如此可減少進入點，並降低遭到誤用的機會。模組化程式碼的優點，在於更易於測試，因此更容易套用程式碼更新并进行驗證。
建立模組化程式碼時，請将最小權限原則纳入考量。模組应该僅具有執行其功能所需的權限。舉例來說，儀器通訊功能不需要存取資料庫，因為資料庫由不同的模組負責處理。避免將資料庫控制代碼傳遞至儀器通訊模組。
在不同模組之間傳遞資料時，評估通訊的可信度。若適用，請先確認來源，再接收來自其他元件的資料。
模組化程式碼應該可以簡化安全審查作業。您可以審查每個模組，而不是在每次審查時審查整組程式碼。程式碼審查人員不需要了解整組程式碼，也能協助提升單一元件的安全性。
程式碼模組也能簡化程式碼的重複使用。已安全開發並通過測試的模組，可放心地重複用於其他應用程式，確信其能依預期運作。
建立一組最佳實務並遵循這些實務。您的程式碼審查作業應確認是否符合這些實務。雖然完整審查最佳實務超出本文件範圍，但至少應包含下列領域：
使用備受肯定的 LabVIEW 單元測試架構 (NI Unit Test Framework、JKI Caraya 或 LUnit)。這些工具可讓開發人員定義輸入與輸出，並驗證程式碼是否正常運作。如此一來，不需執行整個應用程式即可簡化程式碼驗證作業。
單元測試可保護敏感功能，例如控制昂貴的設備，因為可以隔離測試模組。單元測試應精心設計為能重複執行，且理想情況下會整合至連續整合 (CI) 系統中，以確保在程式碼變更時自動執行。
定期安全審查是建立安全意識開發文化的重要一環。審查可協助團隊建立安全實務、相互學習，並加強安全流程。安全審查作業在開發前即開始—審查計畫的架構與方法。接著在整個開發流程中，應繼續進行審查，以確保程式碼的開發安全無虞。審查頻率應依開發規模而定；審查應足夠頻繁，以便在大量後續開發之前修正問題。每次合併需求、提取需求或其他重要程式碼整合活動時，都應進行審查。針對大型專案可能適合安排額外的審查。
只要團隊完成清單中的審查作業，安全性審查作業就能大幅提升效能。這些檢查清單應由組織建立，並根據威脅與風險分析，在每個專案開始時客制化。
除了手動審查程式碼之外，還可執行自動程式碼審查。若您使用持續整合與持續交付/部署 (CI/CD) 流程，請在收件流程中納入安全掃描，以便在每次程式碼簽入時均會進行掃描。設定額外的掃描工具，每天或每週執行，以便在任何新增的安全漏洞成為程式碼的永久性部分之前找出問題。使用靜態分析、單元測試與其他安全掃描工具，以納入各種審查類型。
在可能的情況下，請使用最新版本的開發軟體驅動程式。幾乎每天都會發現新的安全威脅，而開發人員會將安全修正程式納入修補程式與新軟體版本中。若無法使用最新版本，請使用仍可獲得廠商安全更新、且在系統生命週期內將持續獲得更新的軟體。
使用廠商提供的設定指南，設定您的工具以確保安全。
在發行產品前，請根據專案開始時確定的威脅與風險進行測試。此清單可能包含下列測試：
由於 LabVIEW 是一種圖形化程式設計語言，因此有些傳統的安全工具無法測試 LabVIEW 程式碼。JKI Security Suite 等工具提供專為 LabVIEW 開發人員設計的安全性為主的靜態分析功能，可掃描 LabVIEW 程式碼，並且根據圖形化程式設計語言的特定安全考量來調整。
除非開發團隊能證明已審查威脅模型、解決重大漏洞、執行且通過單元測試、執行靜態分析、產生 SBOM、進行程式碼審查，以及簽署發行組合，否則不應核准發行。強制執行正式的發行閘門流程，能讓管理階層有一個決策點，可據以審查是否已遵循流程及軟體是否安全。
開發安全軟體只是流程的一部分。若安全應用程式的部署不正確，或在安裝及設定期間移除安全控制措施，便可能變得脆弱。因此，部署流程應被視為安全軟體開發生命週期的一部分，並在軟體發佈給使用者之前定義程序、審查與驗證活動。
安全預設設定
應使用安全預設設定部署應用程式。使用者通常會假設預設設定代表建議的設定。任何預設停用的安全敏感選項，都可能在系統的整個生命週期中維持停用。
安全預設值可能包含下列範例：
使用者應須有意識地弱化安全設定，而非手動啟用安全保護措施。
生產強化
在發佈前，移除開發期間有用但會在生產環境中造成不必要風險的開發成品與功能。根據下列條件審查應用：
生產系統只能暴露系統運作所需的功能。
帳號與權限管理
檢視系統所需的權限，並將其指派給合適的角色。除非有確認的作業需求，否則系統不應授予管理員權限。服務帳戶應僅設定為具有執行其預定功能所需的權限。考慮以角色為基礎的權限時，請考量：
若系統儲存敏感資訊，請確認存取控制元件是否適當保護該類資訊。
網路安全設定
在部署前記錄所有必要的網路通訊。針對系統進行的每個連線，考量：
資料跨越網路邊界時，必須受到保護。針對每一次資料傳輸，採取下列預防措施：
測試系統通常會同時連接至企業網路、製造網路、雲端服務與儀器。了解並記錄這些信任的邊界是一項重要的部署活動。
秘密資訊與憑證管理
應用通常需要密碼、API 金鑰、憑證、權杖或加密金鑰。處理這些秘密代碼時，請注意不要：
使用下列其中一種工具或技術：
記錄建立、儲存、旋轉、備份與撤銷秘密資訊的方式。按照此流程進行。
記錄與稽核
應用程式應記錄重要的作業與安全性相關活動。所記錄的事件包含下列範例：
確認日誌未記錄任何秘密資訊，例如密碼、個人資訊或機密資訊，因為日誌可能會被非預定對象查看。
記錄有助於排除故障、調查事件，以及證明是否符合客戶與法規要求。
在可能的情況下整合應用記錄與 Windows 事件檢視器或 Linux Syslog 等平台記錄機制，以簡化監控、事件調查與合規報告。評估將記錄傳送至安全伺服器是否能提高保護程度與可存取性。
保護稽核記錄不受未經授權的存取與修改，並定義保留記錄的時間長度。
版本核准
在發佈軟體之前，先執行最終的安全審查，以確認應用是否符合團隊的發佈需求。此最終審查內容包含：
發佈流程應該會產生證據，以證明這些活動已完成。為了維持完整性，這些證據記錄在發佈後應受到保護，以免遭到竄改。
程式碼簽署與封裝完整性
使用者應能確認發布的軟體來自預期組織，且自發佈後一直未經修改。
程式碼簽署應套用至下列所有軟體類型：
程式碼簽署不會阻止軟體修改，但可有效偵測未經授權的修改，並確保軟體來源是預期發佈商。
部署驗證
安裝完成後，確認已部署的系統在預定環境中安全運作。驗證活動應確認下列功能：
每次進行重大設定變更時，都應執行安全驗證。
部署證明
維護記錄，以證明已根據定義流程執行部署作業。這些記錄包含下列範例：
在客戶稽核、供應商評估、法規審查與內部安全調查期間，這些記錄能提供寶貴的可追蹤性。
軟體漏洞是軟體設計、實作、設定或作業流程中的弱點、瑕疵或缺陷，可能遭利用而危及系統或其資料的機密性、完整性或可用性。團隊所開發的程式碼或其中一個用於軟體的元件，都有可能出現漏洞。由於漏洞會為惡意行為者提供破壞系統的途徑，因此務必修復這些漏洞，並將修復部署至受影響的系統。
測試產業在因應漏洞方面面臨了長久的挑戰。許多測試專案都會透過單次前期撥款模式獲得資助，並未為系統的後續維護編列經費。這表示測試團隊沒有用於更新系統的資源，甚至無法提供安全更新。這與維持系統更新的安全需求直接衝突。
其中一項重大挑戰，就是進行更新所需的驗證量。即使軟體和硬體工具並無成本，更新可能也會耗費大量成本來驗證系統在更新後是否正常運作。
隨著安全產業的變化，測試產業也必須著手改變，妥善規劃整個生命週期的測試系統，並提供資助。測試團隊可採取幾項步驟，改用完整的生命週期管理方案，包括：
我們會透過 ni.com/security 通知 NI 產品 (包括 LabVIEW、驅動程式與其他軟體) 中的漏洞。修補程式也會透過常見漏洞與暴露 (CVE) 系統回報。這些修補程式可能會修復 NI 工程師開發的軟體程式碼或我們使用的元件中的漏洞。您可以前往 ni.com/security 註冊新的修補程式通知。
SBOM 也可用來自動掃描軟體。如果您是使用 LabVIEW 應用程式產生 SBOM，可以設定掃描軟體，以檢查 CVE 資料庫是否有報告問題並通知您。目前有多種軟體組合分析 (SCA) 工具可掃描 SBOM，並將其與 CVE 資料庫進行比對。
如果您的最終使用者發現有漏洞，可以直接回報這個漏洞給您。如果問題發生在 NI 軟體內部，請上網至 ni.com/security 回報問題。
重視漏洞報告至關重要。如果您的使用者回報了問題，或是您軟體堆疊中報告了漏洞，請分析漏洞，以判定其影響程度以及遭利用的可能性。這些問題會受到漏洞的性質、以及您使用受影響之軟體元件的方式的影響。如果判定遭利用的威脅非常嚴重，則需要更新軟體並向最終使用者發出修補程式。
某些法規 (例如歐洲網路安全韌性法案 (CRA)) 規定您必須提供 5 年以上的安全修補程式。某些合約可能指定更長或更短的支援承諾。在初步專案提案中規劃此等級的支援，以便在完成專案後避免意外發生。
作為漏洞修復流程的一部分，進行漏洞根本原因分析，以改善開發流程並在未來專案中消除類似問題。
安全軟體開發並非專案結束時所執行的獨立活動。這是一組整合在系統生命週期中的做法。只要採用本指南所述的原則，LabVIEW 團隊就能減少漏洞、改善維護功能、簡化合規措施，並更有效地保護所託付的系統與資料。安全是一個持續演進的流程，您的團隊也會隨著時間逐漸成熟。立即著手建立可重複且永續的流程，以在產品生命週期內持續提升安全性。
| 威脅 | 安全要求 |
|---|---|
| 未經授權修改測試結果 | 僅限具有合適角色的認證使用者修改已儲存的測試結果。 |
| 攔截網路流量 | 應用程式與外部系統之間的所有通訊皆應使用加密協定。 |
| 校準資料損毀 | 校準資料應受保護，避免遭受未經授權的修改，且所有變更皆應記錄。 |
| 未經授權的設備控制 | 管理或危險設備作業必須由已驗證且已獲授權的使用者執行。 |