Drop device category field and fix integration issues

Removed device-category from the CDDL schema, addressed review comments,
and fixed test failures. Updated docs and examples to match.

Signed-off-by: Alex Tzonkov <4975715+attzonko@users.noreply.github.com>

Author: attzonko

Documentation/corim_profile/OCP-SAFE-CoRIM-Extension-Profile-Specification.md

@@ -68,24 +68,27 @@
                                 }
                             }
                           ],
-                          / 5: device-category /          5: 0,  / 0: storage, 1: network, 2: gpu, 3: cpu, 4: apu, 5: bmc /
-                          / 6: issues /                   6: [
+                          / 5: issues /                   5: [
                                / issue-entry / {
-                                / 0: title /         0: "Memory corruption when reading record from SPI flash",
-                                / 1: cvss-score /    1: "7.9",
-                                / 2: cvss-vector /   2: "AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:L",
-                                / 3: cwe /           3: "CWE-111",
-                                / 4: description /   4: "Due to insufficient input validation in the firmware, a local attacker who tampers with a configuration structure in SPI flash, can cause stack-based memory corruption.",
-                                / 5: cvss-version /  5: "3.1"
+                                / 0: title /              0: "Memory corruption when reading record from SPI flash",
+                                / 1: description /        1: "Due to insufficient input validation in the firmware, a local attacker who tampers with a configuration structure in SPI flash, can cause stack-based memory corruption.",
+                                / 2: assessment /  2: {
+                                  / 0: cvss-score /   0: "7.9",
+                                  / 1: cvss-vector / 1: "AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:L",
+                                  / 2: cvss-version / 2: "3.1"
+                                },
+                                / 3: cwe /                3: "CWE-111"
                             },
                               / issue-entry / {
-                                / 0: title /         0: "Debug commands enable arbitrary memory read/write",
-                                / 1: cvss-score /    1: "8.7",
-                                / 2: cvss-vector /   2: "AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L",
-                                / 3: cwe /           3: "CWE-222",
-                                / 4: description /   4: "The firmware exposes debug command handlers that enable host-side drivers to read and write arbitrary regions of the device's SRAM.",
-                                / 5: cvss-version /  5: "3.1",
-                                / 6: cve /           6: "CVE-2014-10000"
+                                / 0: title /              0: "Debug commands enable arbitrary memory read/write",
+                                / 1: description /        1: "The firmware exposes debug command handlers that enable host-side drivers to read and write arbitrary regions of the device's SRAM.",
+                                / 2: assessment /  2: {
+                                  / 0: cvss-score /   0: "8.7",
+                                  / 1: cvss-vector / 1: "AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L",
+                                  / 2: cvss-version / 2: "3.1"
+                                },
+                                / 3: cwe /                3: "CWE-222",
+                                / 4: cve /                4: "CVE-2014-10000"
                             }                            
                           ]
                         }                        

Documentation/corim_profile/examples/ocp-safe-sfr-fw-example.diag

@@ -10,23 +10,28 @@ ocp-safe-sfr-map = {
   &(report-version: 1) => tstr
   &(completion-date: 2) => time
   &(scope-number: 3) => integer
-  &(fw-identifiers: 4) => [ + fw-identifier ]
-  ? &(device-category: 5) => $device-category
-  ? &(issues: 6) => [ + issue-entry ]
+  ? &(fw-identifiers: 4) => [ + fw-identifier ]
+  ? &(issues: 5) => [ + issue-entry ]
   * $$ocp-safe-sfr-map-ext
 }
 
 issue-entry = {
   &(title: 0) => tstr
-  &(cvss-score: 1) => tstr
-  &(cvss-vector: 2) => tstr
-  &(cwe: 3) => tstr
-  &(description: 4) => tstr
-  ? &(cvss-version: 5) => tstr
-  ? &(cve: 6) => tstr
+  &(description: 1) => tstr
+  &(assessment: 2) => $assessment
+  ?&(cwe: 3) => tstr
+  ?&(cve: 4) => tstr
   * $$ocp-safe-issue-entry-ext
 }
 
+$assessment /= cvss
+
+cvss = {
+  &(score: 0) => tstr
+  &(vector: 1) => tstr
+  &(version: 2) => tstr
+}
+
 fw-identifier = non-empty<{
   ? &(fw-version: 0) => version-map
   ? &(fw-file-digests: 1) => digests-type
@@ -42,18 +47,4 @@ manifest-entry = {
 src-manifest = {
   &(manifest-digest: 0) => digests-type 
   &(manifest: 1) => [ + manifest-entry ]
-}
-
-$device-category /= storage
-$device-category /= network
-$device-category /= gpu
-$device-category /= cpu
-$device-category /= apu
-$device-category /= bmc
-
-storage = 0
-network = 1
-gpu = 2
-cpu = 3
-apu = 4
-bmc = 5
+}

Documentation/corim_profile/ocp-safe-sfr-profile.cddl

@@ -58,8 +58,7 @@ The most important section for auditors shows the actual security review finding
    🔸 Field 2: Completion Date
    🔸 Field 3: Scope Number
    🔸 Field 4: Firmware Identifiers
-   🔸 Field 5: Device Category
-   🔸 Field 6: Issues - List of security issues found
+   🔸 Field 5: Issues - List of security issues found
 ```
 
 ### 4. Security Issues Detail
@@ -90,7 +89,6 @@ When reviewing a CoRIM file, verify the following:
 - [ ] SFR extension (-1) is present in measurement values
 - [ ] All required SFR fields are present (0-6)
 - [ ] Completion date is properly encoded with CBOR timestamp tag
-- [ ] Device category is a valid integer (0-5)
 - [ ] Framework version matches expected value
 
 ### ✅ Security Issues Validation
@@ -132,17 +130,6 @@ When reviewing a CoRIM file, verify the following:
 ```
 **Solution**: Check that all mandatory CoRIM fields are included during generation.
 
-## Device Category Reference
-
-The tool automatically translates device category numbers:
-
-- **0**: CPU (Central Processing Unit)
-- **1**: GPU (Graphics Processing Unit)
-- **2**: BMC (Baseboard Management Controller)
-- **3**: NIC (Network Interface Controller)
-- **4**: Storage (Storage devices)
-- **5**: Other (Other device types)
-
 ## CBOR Tag Reference
 
 Common CBOR tags you'll see in the output:

shortform_report-main/AUDITOR_GUIDE.md

@@ -67,9 +67,6 @@
     4096,  # RSA 512
 )
 
-# CoRIM specific constants
-DEVICE_CATEGORIES = {"storage": 0, "network": 1, "gpu": 2, "cpu": 3, "apu": 4, "bmc": 5}
-
 # CBOR tags for CoRIM
 CORIM_TAG = 501
 COMID_TAG = 506
@@ -162,8 +159,9 @@ def add_device(
 
         vendor:    The name of the vendor that manufactured the device.
         product:   The name of the device. Usually a model name or number.
-        category:  The type of device that was audited. Usually a short string
-                     such as: 'storage', 'network', 'gpu', 'cpu', 'apu', or 'bmc'.
+        category:  [LEGACY] The type of device (e.g., 'storage', 'network', 'gpu').
+                   This field is included for backward compatibility with the JSON schema
+                   but is NOT included in CoRIM output as it's not part of the CDDL spec.
         repo_tag:  The Git repository tag associated with the audit. Useful when
                      evaluating ROMs for which we cannot easily calculate or
                      verify the hash.
@@ -339,14 +337,6 @@ def _convert_to_corim_structure(self) -> Dict[str, Any]:
 
         fw_identifiers.append(fw_id)
 
-        # Convert device category to integer
-        category_str = self.report["device"]["category"].lower()
-        device_category = None
-        for cat, val in DEVICE_CATEGORIES.items():
-            if cat in category_str:
-                device_category = val
-                break
-
         # Convert issues
         corim_issues = []
         for issue in self.report["audit"]["issues"]:
@@ -378,11 +368,8 @@ def _convert_to_corim_structure(self) -> Dict[str, Any]:
             4: fw_identifiers,  # fw-identifiers
         }
 
-        if device_category is not None:
-            sfr_map[5] = device_category  # device-category
-
         if corim_issues:
-            sfr_map[6] = corim_issues  # issues
+            sfr_map[5] = corim_issues  # issues
 
         return sfr_map
 

shortform_report-main/OcpReportLib.py

@@ -81,7 +81,6 @@ What follows is an example JSON payload for a hypothetical review of a typical b
     "device": {
         "vendor": "ACME Inc",
         "product": "Roadrunner Trap",
-        "category": "storage",
         "repo_tag": "release_v1_2_3",
         "fw_version": "1.2.3",
         "fw_hash_sha2_384": "0xcd484defa77e8c3e4a8dd73926e32365ea0dbd01e4eff017f211d4629cfcd8e4890dd66ab1bded9be865cd1c849800d4",
@@ -123,7 +122,6 @@ This second example is an example JSON payload for a small SDK source code packa
     "device": {
         "vendor": "ACME Inc",
         "product": "Roadrunner Trap",
-        "category": "storage",
         "repo_tag": "release_v1_2_3",
         "fw_version": "1.2.3",
         "fw_hash_sha2_384": "848aff556097fc1eaf08253abd00af0aad0c317c3490e88bef09348658ce6e14829815fca075d9e03fcf236a47ff91dc",
@@ -192,7 +190,6 @@ A collection of fields that describe the vendor, device, and firmware version th
 
 * `vendor`: The name of the vendor that manufactured the device or firmware being tested.
 * `product`: The name of the device. Usually a model name of number.
-* `category`: The type of device that was audited. Usually a short string such as: `storage`, `network`, `gpu`, `cpu`, `apu`, or `bmc`.
 * `repo_tag`: If applicable, the report can include the repository tag for the code that was audited. This may also be useful for ROM audits where the OCP Member is unable to verify the firmware hash.
 * `fw_version`: The version of the firmware image that is attested by the signed short-form report. In most cases this will be the firmware version compiled by the vendor after the security audit completes, which contains fixes for all vulnerabilities that were found during the audit.
 * `fw_hash_sha2_384`: A hex-encoded string containing the SHA2-384 hash of the firmware image. If the `manifest` field is present, it is a hash of that field instead.

shortform_report-main/README.md

@@ -0,0 +1,177 @@
+# Human-Readable CBOR CoRIM Inspector
+
+## Overview
+
+This directory contains tools for generating and inspecting CBOR-encoded CoRIM (CBOR Object Representation of Information Model) files in a human-readable format. These tools are specifically designed for security auditors and reviewers who need to visually verify the contents of binary CBOR files.
+
+## Files in This Package
+
+### Core Tools
+
+- **`cbor_human_inspector.py`** - Main human-readable CBOR inspector tool
+- **`test_human_inspector.py`** - Test script that generates sample CoRIM and demonstrates the inspector
+- **`AUDITOR_GUIDE.md`** - Comprehensive guide for auditors on how to use these tools
+
+### Supporting Files
+
+- **`OcpReportLib.py`** - Library for generating Security Review Reports in CoRIM format
+- **`tests/final_validation_summary.py`** - Comprehensive CDDL compliance validation
+- **`tests/cbor_structure_analyzer.py`** - Technical CBOR structure analysis
+
+## Quick Start
+
+### 1. Generate and Inspect a Test CoRIM
+
+```bash
+# Generate a sample CoRIM file and inspect it
+python test_human_inspector.py
+```
+
+This will:
+- Create a sample security review report
+- Convert it to CoRIM format
+- Encode it as CBOR
+- Display a human-readable analysis
+
+### 2. Inspect an Existing CoRIM File
+
+```bash
+# Basic inspection
+python cbor_human_inspector.py your_corim_file.cbor
+
+# Include raw CBOR data
+python cbor_human_inspector.py your_corim_file.cbor --show-raw
+```
+
+## Key Features
+
+### 🔍 Human-Readable Analysis
+- Converts binary CBOR to clear, structured text
+- Explains the purpose of each field
+- Shows field names instead of just numbers
+- Provides context for CBOR tags and data types
+
+### ✅ Validation Indicators
+- Visual checkmarks (✅) for correct structures
+- Warning symbols (❌) for issues or missing data
+- Clear explanations of what each validation means
+
+### 📊 Detailed Content Display
+- Security issues with CVSS scores, CWE identifiers, and descriptions
+- Firmware information including hashes and versions
+- Timestamp formatting and validation
+
+### 🎯 Auditor-Focused Output
+- Structured for systematic review
+- Highlights critical security information
+- Provides validation checklists
+- Supports audit trail documentation
+
+## Example Output
+
+```
+================================================================================
+  CBOR CoRIM Human-Readable Inspector
+================================================================================
+📊 Total CBOR size: 1286 bytes
+🔍 Analysis timestamp: 2025-01-15 14:30:22
+
+------------------------------------------------------------
+  Top-Level Structure Analysis
+------------------------------------------------------------
+✅ CBOR Tag Found: 501 (CoRIM (CBOR Object Representation of Information Model))
+✅ This is a valid CoRIM structure
+✅ CoRIM contains 4 top-level fields
+
+🔸 Field 3: Profile - Identifies the CoRIM profile being used
+   ✅ Proper OID tag (111)
+   🆔 Profile: 1.3.6.1.4.1.42623.1.1 (OCP SAFE SFR Profile)
+
+🔐 SFR Extension (-1) Found!
+   📋 SFR Data contains 7 fields:
+   
+   🔸 Field 6: Issues - List of security issues found during review
+      🚨 3 security issue(s) found:
+      
+      🔴 Issue #1:
+         Title: Buffer Overflow in Firmware Parser
+         CVSS Score: 9.1
+         CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
+         CWE: CWE-787
+         Description: A critical buffer overflow vulnerability...
+         CVE: CVE-2025-0123
+```
+
+## Use Cases
+
+### For Security Auditors
+- **Verify CoRIM Structure**: Ensure all required fields are present and correctly formatted
+- **Review Security Issues**: Examine reported vulnerabilities in detail
+- **Validate Compliance**: Check that CoRIMs follow OCP SAFE SFR profile specifications
+- **Create Audit Reports**: Generate human-readable documentation for audit trails
+
+### For Security Review Providers
+- **Quality Assurance**: Verify that generated CoRIMs contain expected data
+- **Debugging**: Identify issues in CoRIM generation processes
+- **Client Communication**: Provide clear explanations of CoRIM contents
+
+### For Framework Developers
+- **Testing**: Validate CoRIM generation and encoding
+- **Debugging**: Analyze CBOR structure issues
+- **Documentation**: Create examples and demonstrations
+
+## Integration with OCP SAFE Framework
+
+This tool is specifically designed for the OCP Security SAFE (Security Assurance Framework for Ecosystems) and supports:
+
+- **OCP SAFE SFR Profile**: OID 1.3.6.1.4.1.42623.1.1
+- **Private Extension (-1)**: For OCP SAFE SFR data
+- **CDDL Schema Compliance**: Validates against the OCP SAFE SFR CDDL profile
+- **Security Review Reports**: Structured security assessment data
+
+## Technical Details
+
+### Supported CBOR Features
+- CBOR tags (timestamps, OIDs, CoRIM, COMID)
+- Nested CBOR structures
+- Binary data formatting
+- Dictionary and array structures
+
+### Validation Capabilities
+- Required field presence checking
+- Data type validation
+- CBOR tag verification
+- OID format validation
+- Timestamp encoding verification
+
+### Output Formats
+- Structured text with Unicode symbols
+- Hierarchical indentation
+- Color-coded status indicators (when terminal supports it)
+- Raw CBOR hex dump (optional)
+
+## Dependencies
+
+- `cbor2` - CBOR encoding/decoding
+- `datetime` - Timestamp handling
+- Standard Python libraries
+
+## Error Handling
+
+The tool provides clear error messages for common issues:
+- Invalid CBOR files
+- Missing required fields
+- Incorrect data types
+- Malformed structures
+
+## Contributing
+
+When extending this tool:
+1. Maintain the human-readable focus
+2. Add clear explanations for new fields
+3. Include validation logic for new structures
+4. Update the auditor guide with new features
+
+## License
+
+This tool is part of the OCP Security SAFE framework and follows the same licensing terms.