New LabVIEW Secure Development Framework Guide Available for Review

[SumRunner]

Many organizations are being asked to demonstrate that their software is developed using secure development practices. While there is a growing body of guidance for text-based software languages, there has been less discussion about what secure development looks like for LabVIEW teams.

To help address that gap, a group of LabVIEW experts collaborated on the first version of the LabVIEW Secure Development Framework Guide. The document adapts guidance from the NIST Secure Software Development Framework (SSDF) to the unique workflows and tools commonly used by LabVIEW development teams.

Our goal is simple: provide practical recommendations that help teams improve security, satisfy customer expectations, and prepare for evolving regulatory requirements. Now that this is written, we'll be taking this message to the LabVIEW community in upcoming conferences and presentations. 

I'd like feedback from this community:

• What parts of the guide are most valuable?
• What recommendations seem difficult to apply in practice?
• What important topics are missing?
• What should we improve in the next revision?

The guide has been submitted for publication on the NI security website, but community members here get the first look.

[Oli_Wachno]

First of all: thanks for putting this together, this is an excellent base.

Some thoughts from my side

Oli_Wachno_0-1787726066536.png

Don't know, how feasible this is regarding OSS, yet in a later section, it says

Oli_Wachno_1-1787726206212.png

Which clarifies what to expect.

Oli_Wachno_2-1787726302103.png

Wouldn't it be cool to mention, that Requirement Fields already have been existing in TestStand (for ages)?

Oli_Wachno_3-1787726402546.png

When will there be one for TestStand?

Especially regarding secrets management in TestStand... I guess we all know a pretty simple way to get privileged access.

Oli_Wachno_4-1787726625714.png

Where can we get this information for NI Software running on our computers and being integrated in our products? NI Service Locator and such?

Oli_Wachno_5-1787726893613.png

I would absolutely love to see a best practices document defining policies and possible settings for NIPM and VIPM to define certain version combinations (freeze). 

Loosely related to this document:  https://forums.ni.com/t5/LabVIEW/Importance-of-Installing-Security-Updates/m-p/4484321#M1325143
I see some degree of resistance to apply updates to existing software. And I can understand it as such as they might come with NIPM updates being enforced on the user for no obvious security related reason but for the sake of the update. IMHO NI itself is violating the modularity approach which is mentioned in this document with something like that.
To state it clearly: I don't expect NI to support software versions for longer than the 5 year minimum period, but during this time, users should not be forced to upgrade NIPM to install a security fixes that don't apply to NIPM.