From AB review by Pete Rivett, March 17, 2020

9.1.1.1 also refers to common sections shared amongst multiple SFPs – however the metamodel does not seem to allow that.

Common sections define some logically shared content, but they have a fixed position in the model

Common sections define some logically shared content, but they have a fixed position in the model (owned only by an SFPCatalog).

From AB review by Pete Rivett, March 17, 2020:

The XSD has a bad URI for spmf and XMI; and a proprieraty location for the XMI namespace import.

Fix the XSD schema

Fix the XSD schema

From AB review by Pete Rivett, March 17, 2020:
The clean UML file provided sysa/20-02-06 is an appropriate file for MOF 2.4+ so should be the normative file for the metamodel. As such it validates well apart from the following issues:

• the top level element should be uml:Package (not uml:Model) and the URI root www.omg.org not www.kdmanalytics.com
• there are over a hundred unnamed properties and associations (strictly speaking required for EMOF)
• many visibilities of “private”

Fix the model, replace the figures

Fix the model, replace the figures

From AB review by Pete Rivet, March 17, 2020:
"Example 1 uses XMI 2.0 (even older than the metamodel XMI) and kdmanalytics.com.
The elements have no xmi:types which is mandatory for any XMI element. In some cases they instead have xsi:types."
Comments by NM: see page 43.

Update sfpm schema location in example 1

These issues have been already addressed in beta-1. Only need to update the sfpm schema location.

From AB review by Pete Rivett, March 17, 2020:

And each CWESection to owned both by a Cluster and a SFP which breaks the rule of having only one composite owner. Again the composite ends should both be 0..1.

Update ownership of CWESection in the model and update figure 2

update ownership of CWESection by SFP and Cluster to 0..1
replace figure 2

From AB review by Pete Rivett on March 17, 2020
Figure 2: the metamodel requires each Cluster to be owned by exactly 1 Cluster, which would never allow a root – the composite end should be 0..1.

update owners of Cluster in the model, replace fig 2

update ownership of cluster by SFPCatalog and another Cluster to 0..1
replace figure 2, page 16

From AB review by Pete Rivett, March 17, 2020:
9.1.3.2 describes a taxonomy of Injuries but the metamodel provides for no structure at all

Remove reference to taxonomy of injuries

While it is possible to formalize taxonomy of injuries as described in the SFP spec, it is surplus to the requirements of the SFPM. SFP treats injuries as a flat enumeration.

From AB review by Pete Rivett, March 17, 2020:
9.1.2.3 says that “Variations in the variation tree are considered ordered” but this is not represented in the metamodel using an ordered property.

Update model, make Variation ordered and change owned end to 0..1

update model: make association from VariationSection to Variation

and 0..1 at the owner end to accommodate the fact that a Variation can be also owned by another Variation.

From AB review by Pete Rivett, Mach 17, 2020:
Would be better for CWE::status should be an enumeration rather than a string.

upgrade informal string attribute into an enumeration

update model, add enumeration class Status. Replace figure 2. Add descriptive text.

From AB review by Pete Rivett, March 17, 2020:
The preface has several assertions that should be justified by references: “the community”, “it has been observed” “all existing classifications resist automation”.

*reword sentence *

reword the sentence, emphasize informal nature of the existing descriptions of weaknesses.
References to specific classifications are not important for the purposes of describing the SFP. The references are available thru CWE.

From AB Review by Pete Rivett, March 17, 2020:
I don’t understand the purpose of replicating chunks of SBVR (in 9.4, 9.5), or even why vocabularies would be needed for Software Patterns. If they’re structural in nature why the need to link them to a conceptual model? It should at most be an optional compliance point.

The use of SBVR seems an odd choice for something that is intended to be first order logic and executable (mentioned elsewhere), since SBVR is neither of those, and it would be necessary to define a subset. Why not use ODM?

no need to further clarify

SBVR is a relevant OMG specification that includes the subset needed for the purposes of SFP. The normative reference to SBVR is made so that semantic formulation elements are not re-defined in this specification.

From AB review by Pete Rivett, March 17, 2020:
The spec uses “Canonical” as a synonym for “Exemplary” or as a sample which is the opposite of its normal use which is for something authoritative or official.

Change "exemplary" to "canonical"

To avoid possible confusion - focus on "canonical".

From AB review by Pete Rivett, March 17, 2020:
The spec in Appendix A seems to introduce its own Human Usable Textual Notation, ignoring the (admittedly dated) OMG standard. And with no description or justification.
Reference should be made to the CFG syntax used.
Though the readable text spec is non-normative it is made use of extensively in the normative sections.

use reference to the EBNF in W3C specification of xml

The "readable SFP language" uses EBNF from the W3C specification of XML. The document is already in normative references.

From AB review by Pete Rivett, March 17, 2020:
The similar analogs “DNA” and “signature” are used to describe quite different things.

Improve terminology related to invariants, signature, profile, dna

The goal of SFP approach is not to examine faults as some abstract objects, but instead to examine computations that exhibit certain "faults"; to reveal the invariants of such computations, and to provide a framework for describing and cataloguing "faults" in terms of these invariants.
Invariants of computations determine certain characteristic elements of computations and common "patterns" in the flow of participating computations. Invariants also describe certain logical relations between the characteristic elements of computations.
Thus is is natural to refer to these invariants as "signatures", or DNA.
However the terms "signature" and "DNA" are used in several different contexts. The language of the specification can be further clarified by identifying these usages and eliminating some of them, while using synonyms in others.

• "signature" of a CWE as defined by a unique set of variations to SFP parameters. This usage can be simply removed
• set of referenced context elements as a "signature" of SFP itself. This can be replaced with a term "profile"
• "signature" of a segment in terms of its variables. This usage can be preserved.
• DNA of a computation (not the same as the "invariant"). This can be changed of a "structural invariant". The term "invariant" can be defined as "a property of all objects in a collection or a family". We can distinguish between a "logical invariant" which is a certain condition that is true for all objects in a family, and a "structural invariant", which is a certain part that all objects in the family have.
  Specification also uses a related term "behavior slice". To clarify the terminology, the term "computation" and "computational slice" can be used.

From AB review by Pete Rivett, March 17, 2020:
I don’t see the value of being able to generate sample code from the Catalog – why not just insert existing code?

Add supporting text clarifying the synthesis perspective of SFP application

CWE already provides few illustrative examples of weaknesses in selected languages. This is important for human consumption. However, such examples cannot be considered as a useful part of machine-consumable knowledge. They need to be parsed, they do not identify the core parts of the "fault" ( not often precise enough to do using the language syntax); they do not provide guidance on true positive/false positive; they are very limited in the code and data complexity and in their language coverage. The industry of code analysis tools requires millions of systematic test cases with appropriate metadata.

From AB review by Pete Rivett, March 17, 2020:
Conformance is very unclear. A few times the spec documents “three supporting capabilities” (e.g. in 9.3.1) but these don’t appear under Conformance. That section 9.3.1 also describes 2 purposes: certification (of software) and synthesis. And 3 further capabilities.
And then the end of 9.3.3. refers to another “interface to the external capabilities”

*Compliance statement is intended to be broad *

The goal of the SFPM is to support the development of the SFP Catalog. The compliance statement should not restrict any potential uses of the content.

From AB review by Pete Rivett on March 17, 2020:
The spec several times mentions “Software Fault Pattern Catalog” and seems to commit OMG to maintaining one. Indeed 9.1.1.1 refers to delivering content related to a single SFP “to the OMG for it to be validated and added to the OMG SFP Catalog”. Who would be responsible for this? How is it reviewed and “validated”? More generally how is the catalog accessed (by human and/or machine) and searched?

Remove reference to OMG SFP Catalog

The goal of the SFP programme is to develop the SFP Catalog. SFPM (the SFP metamodel) is the specification of the content in the SFP Catalog.

From AB review by Pete Rivett March 17 2020:
there is a further confusion between “weakness”/”vulnerability” and “fault”.
It seems to me they are different – a plain fault (aka bug) resulting in the software not acting according to its spec is not necessarily an exploitable weakness.
It seems to me the spec is all about weaknesses, not faults (bugs). That also ties in with the language around CWE which this spec is based on. Use of “fault” should be avoided.

Define "software fault"

Define "software fault" as a formally described fault (cause of failures, esp cybersecurity failures) that can be identified/defined in software alone.

From AB review by Pete Rivett, March 17 2020:
9.1.1.4 states that the objective of SFP is to resolve problems with the CWE catalog maintained by Mitre. This does not seem a community way of working: why not report problems and get them fixed at source?

no need to further clarify

SFP has been developed in close collaboration with CWE developers. CWE has published the SFP viewpoint. The ability to reference CWE in an integral part of development process for SFP. There is a need to reference gaps, and note inconsistencies as part of the SFP effort, because of the mapping to CWEs. This is all a snapshot in time, CWE can change, e.g. decide to address some of these issues, etc. The proposed mechanism is not the means to communicate with Mitre, but rather the means to organize the SFP mapping to CWE.