[Improvement] SMK13 - Add program objectives

[shanecoughlan]

SMK13: 3.1.3: Awareness: Participants are supposed to be aware of "Relevant Program objectives" - does the Program have objectives? They're not formally called out anywhere.

[shanecoughlan]

Discussed during OpenChain Germany Work Group meeting 2022-11-16, and some ideas below.

Possibly address via addition of "and objectives" to 3.1.4 (but that is after 3.1.3, so can we do better), but needs further discussion.

3.1.4 - Program Scope

A Program should have defined guiding principles, scope and objectives that match the risk management policy of the entire organization. It should be clear whether the Program applies to a product line, a department, or the entire organization. It should also be understood that this scope may change over time and metrics may be used to assess its ongoing effectiveness.

[Dr-wood]

I might think that instead of a generic term like program it might be better to call it a Security Assurance Program to more tightly tie it to the work? Just a thought kicker... A Security Assurance Program should have defined guiding principles that engender trust in your developed software with scope and objectives that match the risk management policy of the entire organization. It should be clear whether the Software Assurance Program applies to a specific software product line, or the entire organizations software products. It should also be understood that this scope may change over time and metrics may be used to assess its ongoing effectiveness.

[stephenkilbaneadi]

Somewhat off-topic for this issue, but I think it's better to keep with "Program"; it's a capitalised, defined term (see 2.10), and keeps the license-compliance and security-assurance specs more closely aligned. IMO, we should keep the language as common, but no more so. :-)

[stephenkilbaneadi]

Back on topic: as part of this, add ", objectives" to 2.10?

2.10 - Program

The set of policies, processes, objectives and personnel that comprise an organization’s security assurance activities.

[stephenkilbaneadi]

Alternative option: rather than trying to define what the Program's objectives should be here, we could remove the bullet point from 3.1.3 that's causing this ambiguity. Or we could just close this and keep the ambiguity.

[heliocastro]

Keeping any ambiguity is not good in any case. But the 2.10 would actually add more ambiguity, as every organisation will have their own assessment over the activities. And this somehow can differ in a large quantity from each other.

[Dr-wood]

A Program should have defined guiding principles and scope that match the risk management policy of the entire organization. It should be clear whether the Program applies to a: product line, a department, or the entire organization. It should also be understood that this scope may change over time and metrics should be established to assess the Programs ongoing effectiveness. To create an effective Program you should understand how you will accomplish the following objectives:

• understand structural and technical threats to the Supplied Software;
• track Known Vulnerabilities when discovered;
• verify that identified risks have been addressed before release of Supplied Software;
• report Known Vulnerabilities to the customer upon release of the software when warranted;
• conduct continuous Security Testing for all Supplied Software both prior to and following release;
• report newly discovered Vulnerabilities following release of the Supplied Software;
• report identified risks to third parties as appropriate.