Software Fault Pattern Metamodel Avatar
  1. OMG Specification

Software Fault Pattern Metamodel — Closed Issues

  • Acronym: SFPM
  • Issues Count: 19
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SFPM_-12 Update examples of SFP xmi SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-15 Fix machine-readable files SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-25 Sharing common section among multiple SFP SFPM 1.0b1 SFPM 1.0b2 Closed; No Change closed
SFPM_-16 Fix SFP XSD schema SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-6 Clarify the distinction between "DNA" and "signature" SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-1 Clarify terminology between "weakness"/"vulnerability" and "fault" SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-2 Clarify the relationship between the SFP metamodel and the SFP catalog SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-14 Clarify the use of "taxonomy of injuries" SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-5 Clarify the value of generating sample code from SFP SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-8 Clarify the use of term "Canonical" vs "Exemplary" SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-7 Provide justification for the non-normative "readable" notation for SFPs SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-11 Introduce enumeration literal for CWE::status SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-10 Clarify preface text SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-9 Clarify the use of SBVR for defining SFPs SFPM 1.0b1 SFPM 1.0b2 Closed; No Change closed
SFPM_-13 Make elements of variation tree ordered SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-23 Fix owner of Cluster SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-24 Fix owners of CWESection SFPM 1.0b1 SFPM 1.0b2 Resolved closed
SFPM_-4 Clarify conformance statement SFPM 1.0b1 SFPM 1.0b2 Closed; No Change closed
SFPM_-3 Clarify relationship between SFP and CWE catalog SFPM 1.0b1 SFPM 1.0b2 Closed; No Change closed

Issues Descriptions

Update examples of SFP xmi

  • Key: SFPM_-12
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:54 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    Update sfpm schema location in example 1

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

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Fix machine-readable files

  • Key: SFPM_-15
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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”
  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:58 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    Fix the model, replace the figures

    Fix the model, replace the figures

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Sharing common section among multiple SFP

  • Key: SFPM_-25
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SFPM 1.0b1 — Wed, 16 Feb 2022 14:38 GMT
  • Disposition: Closed; No Change — SFPM 1.0b2
  • Disposition Summary:

    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).

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Fix SFP XSD schema

  • Key: SFPM_-16
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:59 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    Fix the XSD schema

    Fix the XSD schema

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify the distinction between "DNA" and "signature"

  • Key: SFPM_-6
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

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

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:36 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    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.
  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify terminology between "weakness"/"vulnerability" and "fault"

  • Key: SFPM_-1
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:26 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    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.

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify the relationship between the SFP metamodel and the SFP catalog

  • Key: SFPM_-2
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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?

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:29 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    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.

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify the use of "taxonomy of injuries"

  • Key: SFPM_-14
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:56 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    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.

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify the value of generating sample code from SFP

  • Key: SFPM_-5
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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?

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:35 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    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.

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify the use of term "Canonical" vs "Exemplary"

  • Key: SFPM_-8
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:42 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    Change "exemplary" to "canonical"

    To avoid possible confusion - focus on "canonical".

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Provide justification for the non-normative "readable" notation for SFPs

  • Key: SFPM_-7
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:40 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    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.

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Introduce enumeration literal for CWE::status

  • Key: SFPM_-11
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

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

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:48 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    upgrade informal string attribute into an enumeration

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

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify preface text

  • Key: SFPM_-10
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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”.

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:46 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    *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.

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify the use of SBVR for defining SFPs

  • Key: SFPM_-9
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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?

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:43 GMT
  • Disposition: Closed; No Change — SFPM 1.0b2
  • Disposition Summary:

    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.

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Make elements of variation tree ordered

  • Key: SFPM_-13
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:55 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

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

    update model: make association from VariationSection to Variation

    {ordered}, and 0..1 at the VariationSection end to accommodate the fact that a Variation can be also owned by another Variation.
    Make association between Variation and Variatiion {ordered}

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

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Fix owner of Cluster

  • Key: SFPM_-23
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SFPM 1.0b1 — Wed, 16 Feb 2022 14:36 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    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

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Fix owners of CWESection

  • Key: SFPM_-24
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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.

  • Reported: SFPM 1.0b1 — Wed, 16 Feb 2022 14:37 GMT
  • Disposition: Resolved — SFPM 1.0b2
  • Disposition Summary:

    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

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify conformance statement

  • Key: SFPM_-4
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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”

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:34 GMT
  • Disposition: Closed; No Change — SFPM 1.0b2
  • Disposition Summary:

    *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.

  • Updated: Tue, 9 Jan 2024 22:27 GMT

Clarify relationship between SFP and CWE catalog

  • Key: SFPM_-3
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    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?

  • Reported: SFPM 1.0b1 — Tue, 15 Feb 2022 04:31 GMT
  • Disposition: Closed; No Change — SFPM 1.0b2
  • Disposition Summary:

    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.

  • Updated: Tue, 9 Jan 2024 22:27 GMT