Operating systems should be recognized as specializations of software #632

ajnelson-nist · 2024-09-13T15:29:27Z

Background

observable:OperatingSystem is currently a direct subclass of observable:ObservableObject, with no relationship to observable:Software.

Issue 596 proposes a restructuring of classes pertaining to software, including making OperatingSystem a direct subclass of Software.

Issue 626 implements a constraint on describing operating systems with observable:cpeid, that is reliant on OperatingSystem being a subclass of Software as is consistent with the CPE model (i.e., in NISTIR 7695).

To the proposer's understanding, there is no operating system that is not, at least in part, software.

This proposal is almost a fast-track change to change the parent class of OperatingSystem to Software; however, while reviewing data for demonstration, some property movements between Facets became apparent.

Requirements

Requirement 583-2

This requirement is ported from Issue 596, and is a reduction of a requirement ported from Issue 583:

Ability to characterize different types of software objects
At a minimum this should include Software, and OperatingSystem.

Requirement 1

To prevent data placement confusion and synchronization issues, OperatingSystemFacet and SoftwareFacet must share no properties. Any shared properties should be placed only in SoftwareFacet.

Currently, they both have the properties observable:manufacurer and observable:version.

(This requirement is in addition to Issues 583 and 596, and was realized when sketching example data.)

Risk / Benefit analysis

Benefits

This proposal progresses software restructuring that is not blocked waiting on feedback.

Risks

This change will exercise a part of Facets that might appear less than intuitive to users, though nothing will have changed about Facet design with this proposal. To describe an operating system with software characteristics, the properties will go in a SoftwareFacet attached to the OperatingSystem. Structurally, this is because while OperatingSystem would subclass Software, OperatingSystemFacet and SoftwareFacet remain independent classes.
While this proposal will remove some properties from observable:OperatingSystemFacet, UCO's current design practice of declining rdfs:domain and generally not using "Domain-reviewing" shapes (e.g. with sh:targetSubjectsOf and sh:targetObjectsOf) mean in UCO 2.0.0, it will not be an error to keep using observable:manufacturer or observable:version on observable:OperatingSystemFacet. Further, following current practice, users will be more free to use those properties on observable:OperatingSystemFacet, because SHACL usage is currently only defined in property shapes attached to classes. It will be possible for a user to record "observable:version": 1 as an integer, and UCO's SHACL will not flag it as an error. Adddressing this requires a global revision of UCO's property-review practice to follow what was done in only a few cases (e.g., types:repeatsKey for Issue 602, and core:objectStatus for Issue 549). This will need to be discussed separately, as there might need to be considerations for generated documentation.
1. If the properties should be disallowed from observable:OperatingSystemFacet, specific shapes can be added for UCO 2.0.0 that flag their usage as an error. This would be a special-case handling of only two properties.
2. Being able to provide migration guidance in UCO 1.4.0 before UCO 2.0.0 potentially mitigates this risk without needing to address the underlying UCO design matters.

Competencies demonstrated

Competency 1

A workstation has an instance of an operating system from Example OS Company.

{
    "@context": {
        "core": "https://ontology.unifiedcyberontology.org/uco/core/",
        "identity": "https://ontology.unifiedcyberontology.org/uco/identity/",
        "kb": "http://example.org/kb/",
        "observable": "https://ontology.unifiedcyberontology.org/uco/observable/",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },
    "@graph": [
        {
            "@id": "kb:Organization-4ea8a5bf-60ea-43ba-9ba6-f852ce8f8b54",
            "@type": "identity:Organization",
            "core:name": "Example OS Company"
        },
        {
            "@id": "kb:OperatingSystem-427dd103-2553-4ccc-ad57-1df4e88b174d",
            "@type": "observable:OperatingSystem",
            "core:description": "The Example Operating System instance deployed on workstation B-203-22",
            "core:hasFacet": [
                {
                    "@id": "kb:SoftwareFacet-1bde46c5-4648-493c-b9dc-56477191d5c6",
                    "@type": "observable:SoftwareFacet",
                    "observable:cpeid": "cpe:2.3:o:exampleosco:exampleos:40:*:*:*:*:*:*:*",
                    "observable:language": "en-us",
                    "observable:manufacturer": {
                        "@id": "kb:Organization-4ea8a5bf-60ea-43ba-9ba6-f852ce8f8b54"
                    },
                    "observable:version": "40"
                },
                {
                    "@id": "kb:OperatingSystemFacet-35047ef2-ffd6-45e8-8b3c-2e8e4bfe7c2b",
                    "@type": "observable:OperatingSystemFacet",
                    "observable:bitness": "64",
                    "observable:installDate": {
                        "@type": "xsd:dateTime",
                        "@value": "2024-09-13T09:00:00-04:00"
                    }
                }
            ]
        }
    ]
}

Competency Question 1.1

What is the query and result for finding the version of this operating system, specifying the specific Facet needed?

Result 1.1

SPARQL query:

SELECT ?lVersion
WHERE {
	?nOperatingSystem
		a observable:OperatingSystem ;
		core:hasFacet ?nFacet ;
		.
	?nFacet
		a observable:SoftwareFacet ;
		observable:version ?lVersion ;
		.
}

Result:

lVersion
`40`

Competency Question 1.2

Alternatively, how can the version of the operating system be found, without regard for what Facet is housing it?

Result 1.2

SPARQL query:

SELECT ?lVersion
WHERE {
	?nOperatingSystem
		a observable:OperatingSystem ;
		core:hasFacet / observable:version ?lVersion ;
		.
}

Result:

lVersion
`40`

This is one motivation for removing observable:version from what would become a redundant placement in OperatingSystemFacet.

Solution suggestion

For UCO 1.4.0, implement the following warnings for backwards compatiblity:

Add a warning-shape to observable:OperatingSystem, that its instances must also be typed as observable:Software. This is as was done with moving observable:AlternateDataStream in Issue 590.
Add new property shapes for observable:version and observable:manufacturer to observable:OperatingSystemFacet, setting only the constraint that they have a maximum-use count of 0, with a severity of sh:Warning.

For UCO 2.0.0:

Change the parent class of observable:OperatingSystem to observable:Software.
Remove the class warning shape put in place for UCO 1.4.0.
Remove all property shapes for observable:version and observable:manufacturer from observable:OperatingSystemFacet; OR, remove the two properties' shapes that were in UCO 1.3.0, and upgrade the severity for the properties' warning shapes to sh:Violation (the SHACL default).

Coordination

The text was updated successfully, but these errors were encountered:

A follow-on patch will regenerate Make-managed files. References: * #632 Signed-off-by: Alex Nelson <[email protected]>

References: * #632 Signed-off-by: Alex Nelson <[email protected]>

packet-rat · 2024-09-13T16:19:27Z

?The Machine” opined and: In the context of emerging SBOM (Software Bill of Materials) information models, "Operating System" and "Software" are indeed treated with specific hierarchical relationships. 1. Software: This is the broad category that encompasses all forms of computer programs, including applications, utilities, and operating systems. It generally refers to any set of instructions that direct a computer to perform specific tasks. 2. Operating System (OS): An operating system is a specific type of software that manages computer hardware and software resources and provides common services for computer programs. Hierarchical Relationship In most SBOM information models, the "Operating System" is considered a subclass of "Software." This means: · Software is the parent class that includes all types of software. · Operating System is a specialized category within the broader class of Software. Example Representation Here’s a simplified representation of the hierarchical relationship: Software │ ├── Application Software │ ├── Word Processor │ ├── Web Browser │ └── Email Client │ ├── System Software │ ├── Operating System │ │ ├── Windows │ │ ├── Linux │ │ └── macOS │ ├── Device Drivers │ └── Utility Programs SBOM Standards and Models Standards such as SPDX (Software Package Data Exchange) and CycloneDX offer frameworks for defining and managing SBOMs. These standards help ensure that the relationship between "Operating System" and "Software" is clearly defined and consistently represented. · SPDX: The SPDX specification provides a structured way to describe the components and dependencies of software, including operating systems as part of the overall software ecosystem. · CycloneDX: CycloneDX is another SBOM standard that supports detailed descriptions of software components, including operating systems as specific entries within the broader software category. Importance in SBOM Understanding the relationship between operating systems and other software components is crucial for: · Security: Identifying vulnerabilities and managing patches effectively. · Compliance: Ensuring adherence to licensing and regulatory requirements. · Dependency Management: Recognizing how different software components interact and depend on one another. In conclusion, within SBOM information models, the "Operating System" is indeed treated as a direct subclass of "Software," reflecting its role as a fundamental type of system software within the broader software category. [A blue circle with text Description automatically generated] Patrick Maroney | Principal – Cybersecurity | AT&T Services, Inc. Threat Analytics e: ***@***.******@***.***> | p: 732.615.5287 [Image] From: Alex Nelson ***@***.***> Date: Friday, September 13, 2024 at 11:30 AM To: ucoProject/UCO ***@***.***> Cc: Subscribed ***@***.***> Subject: [ucoProject/UCO] Operating systems should be recognized as specializations of software (Issue #632) Background observable: OperatingSystem is currently a direct subclass of observbable: ObservableObject, with no relationship to observable: Software. Issue 596 proposes a restructuring of classes pertaining to software, including making OperatingSystem Background observable:OperatingSystem is currently a direct subclass of observbable:ObservableObject, with no relationship to observable:Software. Issue 596<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/596__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHiFfcglw$> proposes a restructuring of classes pertaining to software, including making OperatingSystem a direct subclass of Software. Issue 626<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/626__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHYlIVsTA$> implements a constraint on describing operating systems with observable:cpeid, that is reliant on OperatingSystem being a subclass of Software as is consistent with the CPE model (i.e., in NISTIR 7695<https://urldefense.com/v3/__https:/nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHH8Bdg0Q$>). To the proposer's understanding, there is no operating system that is not, at least in part, software. This proposal is almost a fast-track change to change the parent class of OperatingSystem to Software; however, while reviewing data for demonstration, some property movements between Facets became apparent. Requirements Requirement 583-2 This requirement is ported from Issue 596, and is a reduction of a requirement ported from Issue 583<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/583__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHKEBG-NI$>: Ability to characterize different types of software objects At a minimum this should include Software, and OperatingSystem. Requirement 1 To prevent data placement confusion and synchronization issues, OperatingSystemFacet and SoftwareFacet must share no properties. Any shared properties should be placed only in SoftwareFacet. Currently, they both have the properties observable:manufacurer and observable:version. (This requirement is in addition to Issues 583 and 596, and was realized when sketching example data.) Risk / Benefit analysis Benefits * This proposal progresses software restructuring that is not blocked waiting on feedback. Risks 1. This change will exercise a part of Facets that might appear less than intuitive to users, though nothing will have changed about Facet design with this proposal. To describe an operating system with software characteristics, the properties will go in a SoftwareFacet attached to the OperatingSystem. Structurally, this is because while OperatingSystem would subclass Software, OperatingSystemFacet and SoftwareFacet remain independent classes. 2. While this proposal will remove some properties from observable:OperatingSystemFacet, UCO's current design practice of declining rdfs:domain and generally not using "Domain-reviewing" shapes (e.g. with sh:targetSubjectsOf and sh:targetObjectsOf) mean in UCO 2.0.0, it will not be an error to keep using observable:manufacturer or observable:version on observable:OperatingSystemFacet. Further, following current practice, users will be more free to use those properties on observable:OperatingSystemFacet, because SHACL usage is currently only defined in property shapes attached to classes. It will be possible for a user to record "observable:version": 1 as an integer, and UCO's SHACL will not flag it as an error. Adddressing this requires a global revision of UCO's property-review practice to follow what was done in only a few cases (e.g., types:repeatsKey<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/pull/607/files*diff-8b2786612dfe2bd9e7391e3e5483adc00670659e8a0c61682f57224f45e45d17R364-R368__;Iw!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHdnswLjg$> for Issue 602, and core:objectStatus<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/pull/631/files*diff-36fbd057dbb7e09c10fa272a10fe2ce47e0a6dc859b39b56cd1466e7578c1b9dR732-R736__;Iw!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacH6NKxGAE$> for Issue 549). This will need to be discussed separately, as there might need to be considerations for generated documentation. * If the properties should be disallowed from observable:OperatingSystemFacet, specific shapes can be added for UCO 2.0.0 that flag their usage as an error. This would be a special-case handling of only two properties. * Being able to provide migration guidance in UCO 1.4.0 before UCO 2.0.0 potentially mitigates this risk without needing to address the underlying UCO design matters. Competencies demonstrated Competency 1 A workstation has an instance of an operating system from Example OS Company. { ***@***.***": { "core": "https://ontology.unifiedcyberontology.org/uco/core/<https://urldefense.com/v3/__https:/ontology.unifiedcyberontology.org/uco/core/__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHfChLmA0$>", "identity": "https://ontology.unifiedcyberontology.org/uco/identity/<https://urldefense.com/v3/__https:/ontology.unifiedcyberontology.org/uco/identity/__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHexRTjZU$>", "kb": "http://example.org/kb/<https://urldefense.com/v3/__http:/example.org/kb/__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHsICJI4I$>", "observable": "https://ontology.unifiedcyberontology.org/uco/observable/<https://urldefense.com/v3/__https:/ontology.unifiedcyberontology.org/uco/observable/__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHq9HKIgU$>", "xsd": "http://www.w3.org/2001/XMLSchema#<https://urldefense.com/v3/__http:/www.w3.org/2001/XMLSchema*__;Iw!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacH5g9EO7E$>" }, ***@***.***": [ { ***@***.***": "kb:Organization-4ea8a5bf-60ea-43ba-9ba6-f852ce8f8b54", ***@***.***": "identity:Organization", "core:name": "Example OS Company" }, { ***@***.***": "kb:OperatingSystem-427dd103-2553-4ccc-ad57-1df4e88b174d", ***@***.***": "observable:OperatingSystem", "core:description": "The Example Operating System instance deployed on workstation B-203-22", "core:hasFacet": [ { ***@***.***": "kb:SoftwareFacet-1bde46c5-4648-493c-b9dc-56477191d5c6", ***@***.***": "observable:SoftwareFacet", "observable:cpeid": "cpe:2.3:o:exampleosco:exampleos:40:*:*:*:*:*:*:*", "observable:language": "en-us", "observable:manufacturer": { ***@***.***": "kb:Organization-4ea8a5bf-60ea-43ba-9ba6-f852ce8f8b54" }, "observable:version": "40" }, { ***@***.***": "kb:OperatingSystemFacet-35047ef2-ffd6-45e8-8b3c-2e8e4bfe7c2b", ***@***.***": "observable:OperatingSystemFacet", "observable:bitness": "64", "observable:installDate": { ***@***.***": "xsd:dateTime", ***@***.***": "2024-09-13T09:00:00-04:00" } } ] } ] } Competency Question 1.1 What is the query and result for finding the version of this operating system, specifying the specific Facet needed? Result 1.1 SPARQL query: SELECT ?lVersion WHERE { ?nOperatingSystem a observable:OperatingSystem ; core:hasFacet ?nFacet ; . ?nFacet a observable:SoftwareFacet ; observable:version ?lVersion ; . } Result: lVersion 40 Competency Question 1.2 Alternatively, how can the version of the operating system be found, without regard for what Facet is housing it? Result 1.2 SPARQL query: SELECT ?lVersion WHERE { ?nOperatingSystem a observable:OperatingSystem ; core:hasFacet / observable:version ?lVersion ; . } Result: lVersion 40 This is one motivation for removing observable:version from what would become a redundant placement in OperatingSystemFacet. Solution suggestion For UCO 1.4.0, implement the following warnings for backwards compatiblity: * Add a warning-shape to observable:OperatingSystem, that its instances must also be typed as observable:Software. This is as was done with moving observable:AlternateDataStream in Issue 590<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/590__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHf7h_agM$>. * Add new property shapes for observable:version and observable:manufacturer to observable:OperatingSystemFacet, setting only the constraint that they have a maximum-use count of 0, with a severity of sh:Warning. For UCO 2.0.0: * Change the parent class of observable:OperatingSystem to observable:Software. * Remove the class warning shape put in place for UCO 1.4.0. * Remove all property shapes for observable:version and observable:manufacturer from observable:OperatingSystemFacet; OR, remove the two properties' shapes that were in UCO 1.3.0, and upgrade the severity for the properties' warning shapes to sh:Violation (the SHACL default). — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/ucoProject/UCO/issues/632__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacHXhvxp5I$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AAYSFYKDNLDPJPDORIFOKVDZWMAG3AVCNFSM6AAAAABOFTLMJCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUZDKMJRGE2DIMQ__;!!BhdT!h3NXex0b94Qqzi-w1vmigwCYOAdbnyFSwIiocQUquuZt9E1GzgBr5CRpd1r6Tw3JmtzIkOkn-ArgeE1xvacH6ogRPDg$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

…-common property placement A follow-on patch will regenerate Make-managed files. References: * #632 Signed-off-by: Alex Nelson <[email protected]>

References: * #632 Signed-off-by: Alex Nelson <[email protected]>

No effects were observed on Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

…d relationships and provenance A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

…d relationships A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

No effects were observed on Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist · 2024-10-17T02:10:05Z

PRs #633 and #636 provide the implementations for UCO 1.4.0 and 2.0.0. (PR 636 currently has a noisy Git diff, but after #635 is merged it should simplify.)

All of the CASE example repositories needed updates to move manufacturer and version properties into SoftwareFacets. This frequently induced creating OperatingSystem objects and tying ObservableRelationships, because the housing OperatingSystemFacets were often on Device objects, and it seemed problematic to put a SoftwareFacet directly onto a Device object. Those interested in the total patch-effects should see the "remediation" links on PRs 633 or 636.

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

sbarnum · 2024-10-24T03:42:48Z

This looks good to me

ajnelson-nist added the Change Proposal label Sep 13, 2024

ajnelson-nist added this to the UCO 1.4.0 milestone Sep 13, 2024

ajnelson-nist added a commit that referenced this issue Sep 13, 2024

Prepare OperatingSystem to become a subclass of Software

62ebeab

A follow-on patch will regenerate Make-managed files. References: * #632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist linked a pull request Sep 13, 2024 that will close this issue

Issue 632: Prepare OperatingSystem to become a subclass of Software #633

Open

13 tasks

ajnelson-nist added a commit that referenced this issue Sep 13, 2024

Regenerate Make-managed files

40b285a

References: * #632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist mentioned this issue Sep 13, 2024

cpeid should constrain values through CPE version and "Part" component of Well-Formed Name #626

Open

17 tasks

ajnelson-nist linked a pull request Oct 16, 2024 that will close this issue

Issue 632: Change OperatingSystem parent class to Software #636

Draft

14 tasks

ajnelson-nist added a commit that referenced this issue Oct 16, 2024

Regenerate Make-managed files

ca5ef43

References: * #632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Oct 16, 2024

Bump UCO to current state of unstable

8c55711

No effects were observed on Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Oct 16, 2024

Bump UCO to current state of unstable-2.0.0

6dabc0d

No effects were observed on Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Oct 16, 2024

Bump unstable pointers

ff32f1d

A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Oct 16, 2024

Regenerate Make-managed files

d45c080

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Oct 16, 2024

Regenerate Make-managed files

3799583

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Oct 17, 2024

Bump unstable pointers

06e6586

A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Oct 17, 2024

Regenerate Make-managed files

57e2fbc

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Oct 17, 2024

Regenerate Make-managed files

fb8600c

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/CASE-Corpora that referenced this issue Oct 17, 2024

Regenerate Make-managed files

4c92580

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

ajnelson-nist added a commit to casework/CASE-Corpora that referenced this issue Oct 17, 2024

Bump unstable pointers

b58a425

No effects were observed on Make-managed files. References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

This was referenced Oct 17, 2024

Bump prerelease pointers casework/casework.github.io#303

Merged

UCO Issue 632: Migrate software properties of operating systems into new objects; add relationships casework/CASE-Examples#151

Merged

ajnelson-nist added a commit to ajnelson-nist/CASE-Examples-QC that referenced this issue Oct 21, 2024

Bump pointers and regenerate Make-managed files

2e84bad

References: * ucoProject/UCO#632 Signed-off-by: Alex Nelson <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Operating systems should be recognized as specializations of software #632

Operating systems should be recognized as specializations of software #632

ajnelson-nist commented Sep 13, 2024 •

edited

Loading

packet-rat commented Sep 13, 2024 via email

ajnelson-nist commented Oct 17, 2024

sbarnum commented Oct 24, 2024

Operating systems should be recognized as specializations of software #632

Operating systems should be recognized as specializations of software #632

Comments

ajnelson-nist commented Sep 13, 2024 • edited Loading

Background

Requirements

Requirement 583-2

Requirement 1

Risk / Benefit analysis

Benefits

Risks

Competencies demonstrated

Competency 1

Competency Question 1.1

Result 1.1

Competency Question 1.2

Result 1.2

Solution suggestion

Coordination

packet-rat commented Sep 13, 2024 via email

ajnelson-nist commented Oct 17, 2024

sbarnum commented Oct 24, 2024

ajnelson-nist commented Sep 13, 2024 •

edited

Loading