Skip to content

Integrate SOLID #89

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ericeilertson merged 3 commits into from
May 19, 2026
Merged

Integrate SOLID #89

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
cf6f0d6
Integrate SOLID
nickhummel May 12, 2026
3a04bed
Update python scripts with SOLID
nickhummel May 19, 2026
aedd01c
Make SOLID version optional in python
nickhummel May 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
169 changes: 5 additions & 164 deletions Documentation/corim_profile/OCP-SAFE-CoRIM-Extension-Profile-Specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -140,6 +140,7 @@ ocp-safe-sfr-map = {
&(scope-number: 3) => integer
? &(fw-identifiers: 4) => [ + fw-identifier ]
? &(issues: 5) => [ + issue-entry ]
? &(solid-version: 6) => tstr
* $$ocp-safe-sfr-map-ext
}
```
Expand All @@ -162,7 +163,8 @@ ocp-safe-sfr-map = {
| Field | Key | Type | Description |
|-------|-----|------|-------------|
| fw-identifiers | 4 | array | Array of firmware identifier objects |
| issues | 6 | array | Array of security issues identified during review |
| issues | 5 | array | Array of security issues identified during review |
| solid-version | 6 | tstr | Version of the SOLID requirements checked against |

### Firmware Identifiers

Expand Down Expand Up @@ -307,172 +309,11 @@ To ensure broad interoperability:

### Profile CDDL

```cddl
; Auditor CoRIM – Corim which embeds the SFR fields
; OCP SAFE SFR CoRIM Profile OID: 1.3.6.1.4.1.42623.1.1

$$measurement-values-map-extension //= (
&(ocp-safe-sfr: -1) => ocp-safe-sfr-map ; Private extension for OCP SAFE SFR
)

ocp-safe-sfr-map = {
&(review-framework-version: 0) => tstr
&(report-version: 1) => tstr
&(completion-date: 2) => time
&(scope-number: 3) => integer
? &(fw-identifiers: 4) => [ + fw-identifier ]
? &(issues: 5) => [ + issue-entry ]
* $$ocp-safe-sfr-map-ext
}

issue-entry = {
&(title: 0) => 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
? &(repo-tag: 2) => tstr
? &(src-manifest: 3) => src-manifest
}>

manifest-entry = {
&(filename: 0) => tstr
&(file-hash: 1) => digests-type
}

src-manifest = {
&(manifest-digest: 0) => digests-type
&(manifest: 1) => [ + manifest-entry ]
}
```
[This file](./ocp-safe-sfr-profile.cddl) contains the formal definition.

### Example CoRIM with SFR Extension

The following example demonstrates a complete CoRIM structure containing OCP S.A.F.E. SFR security review findings:

```cbor-diag
/ tagged-corim-map / 501({
/ corim.id (0) /
0: "acme-trap-audit-2025-08-03",
/ corim.profile (3) /
3: 111(h'060A2B0601040182F4170101'), / OID 1.3.6.1.4.1.42623.1.1 for OCP SAFE SFR profile /
/ corim.entities (5) /
5: [
/ audit-entity / {
/ entity-name (0) / 0: "My Pentest Corporation",
/ role (2) / 2: [ 1 ] / manifest-creator /
}
],
/ corim.tags / 1 : [
/ concise-mid-tag / 506( <<
/ concise-mid-tag / {
/ comid.tag-identity / 1 : {
/ comid.tag-id / 0 : "acme-trap-review-comid-001"
},
/ comid.triples / 4 : {
/ conditional-endorsement-triples / 10 : [
[ / conditional-endorsement-triple-record /
[ / conditions array /
[ / *** stateful-environment-record *** /
/ environment-map / {
/ comid.class / 0 : {
/ comid.vendor / 1 : "ACME Inc.",
/ comid.model / 2 : "ACME RoadRunner Trap"
}
},
[ / claims-list /
/ *** measurement-map *** / {
/ comid.mval / 1 : {
/ comid.digests / 2 : [ [
/ hash-alg-id / -43, / sha384 /
/ hash-value / h'52047e070cddf496a7f77bf6a47792797e8ee90a149bb7555d08c5f93c5ca7ea46a63a7c99edaa1659e8afadfb9c6114'
],
[
/ hash-alg-id / -44, / sha512 /
/ hash-value / h'12a5b961a5eb7e548ed436fe7b5848d428bff908cb6ffcb47ec3ac1e2a43e0b8d1ff047d387fb0a940dc7b8b0014acf344364c43ab4de624dcd15f98bee552a5'
]
]
}
}
]
]
], /*** end stateful-environment-records ***/
[ /*** endorsements ***/
[ /*** endorsed-triple-record ***/
/ environment-map / {
/ class / 0 : {
/ vendor / 1 : "ACME Inc.",
/ model / 2 : "ACME RoadRunner Trap"
}
},
[ / endorsement #1/
/ measurement-map / {
/ comid.mval / 1 : { / measurement-values-map /
/ ocp-safe-sfr / -1 : {
/ 0: review-framework-version / 0: "1.1",
/ 1: report-version / 1: "1.2",
/ 2: completion-date / 2: 1(1687651200),
/ 3: scope-number / 3: 1,
/ 4: fw-identifiers / 4: [
/fw-identifier / {
/ 0: fw-version / 0: {
/ 0: version / 0: "1.2.3",
/ 1: version-scheme / 1: "semver"
}
}
],
/ 5: issues / 6: [
/ issue-entry / {
/ 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: 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"
}
]
}
}
}
]
]
]
]
]
}
}
>> )
]
}
)
```
[This example file](./examples/ocp-safe-sfr-fw-example.diag) demonstrates a complete CoRIM structure containing OCP S.A.F.E. SFR security review findings.

## References

Expand Down
3 changes: 2 additions & 1 deletion Documentation/corim_profile/examples/ocp-safe-sfr-fw-example.diag
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,7 +90,8 @@
/ 3: cwe / 3: "CWE-222",
/ 4: cve / 4: "CVE-2014-10000"
}
]
],
/ 6: solid-version / 6: "1.0",
}
}
}
Expand Down
1 change: 1 addition & 0 deletions Documentation/corim_profile/ocp-safe-sfr-profile.cddl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@ ocp-safe-sfr-map = {
&(scope-number: 3) => integer
? &(fw-identifiers: 4) => [ + fw-identifier ]
? &(issues: 5) => [ + issue-entry ]
? &(solid-version: 6) => tstr
* $$ocp-safe-sfr-map-ext
}

Expand Down
94 changes: 5 additions & 89 deletions Documentation/framework.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,7 +142,7 @@ The conditions under which these reviews take place, are of two main types:
At a high level, the process flows through the following sequence of steps:

1. DV selects an SRP from the list of [approved providers](./security_review_providers.md).
2. DV and SRP prepare a scope for the security review according to the [Security Review Scope](#security-review-scope) information provided below and in the supplementary [review areas](./review_areas.md).
2. DV and SRP prepare a scope specific to the security review according to the general [Review Scope](./review_scope.md).
3. SRP performs the security review.
4. DV addresses any findings from the SRP.
5. SRP reviews the changes and issues the final reports.
Expand All @@ -167,93 +167,15 @@ The key objectives of this framework are:
* Through iterative refinement of review areas, testing scopes, and reporting requirements, progressively advance the
security posture of hardware and firmware components across the supply chain.

## Security Review Scope

The following sections describe at a high level the areas that should be in scope for any security audit performed under
this framework.
They are intended as starting points for DVs and SRPs when undertaking a device or firmware security assessment. Under
the framework, it is required for every production version of device firmware to have undergone the assessment. A more
detailed
description of the scopes is provided in the [review areas](./review_areas.md) document.

* **Threat Model** \
The SRP should assess the DV’s documented threat models and perform a gap analysis, ensuring they are adequately
covered by the observed hardware and firmware implementation. If the DV cannot provide a threat model, then the SRP
should create one as part of the assessment scope. The threat model document should include the following details, and
be aligned with the in-scope and out-of-scope threats described by
the [Common Security Threats](https://www.opencompute.org/documents/common-security-threats-notes-1-pdf)
document:
* **Security Objectives**: The high-level security objectives or key
risks exposed by the firmware. Examples of such objectives may include the strict requirement that the secure boot
or firmware anti-rollback features must not be subverted or bypassed by an attacker.
* **Adversarial Model**: A listing of all threat actors along with their
motivation and capabilities. Examples may include a simple opportunistic hardware adversary, or advanced
persistent threats that are able to keep the device under antagonistic conditions for an extended duration.
* **Attack Surface Enumeration**: A listing of all remote, local and
physical attack surfaces exposed by the device. Examples may include mailbox or IPC interfaces exposed via MMIO, a
command shell exposed via a serial interface, inter-chip buses which transmit sensitive data, or external
non-volatile storage media.
* **Critical Assets**: A listing of all security-impacting assets within
the firmware, and the corresponding Confidentiality, Integrity and Availability requirements for each. Examples of
critical assets may include secret keys, the fuse configuration, or any configuration data residing in external flash.

The SAFE program defines 3 security review scopes. These scopes increase with complexity of attacks in the threat model.
It is expected that devices will have reviews done with different review scopes. For example, a CPU may have a scope 3
review of the root of trust due to the need for glitch protection when using a long-term device private key. This CPU
may use a scope 2 review for the application cores.

* **Scope 1 Code and Architecture Assessment**
* **Source Code Review** \
The SRP should perform a whitebox security review of the device’s ROM and mutable firmware source code for
identification of vulnerabilities and lapses in industry best practices. Issues uncovered during the review should
be fixed by the DV and subsequently verified as fixed by the SRP. The review scope should include:
* Analysis of the firmware loading and verification procedures to ensure that a secure boot implementation is
present and cannot be circumvented. All critical assets that impact the device’s security must be
cryptographically signed. The
OCP [Secure Boot](https://www.opencompute.org/documents/secure-boot-2-pdf)
document should be used for guidance.
* Discovery of hard-coded credentials, seeds, private keys, or symmetric secrets.
* Identifying temporal and spatial memory safety issues that arise due to improper input validation or race
conditions that may occur along the attack surfaces that were identified in the threat model.
* Discovery of remnant debug handlers on production builds
* Analysis of the cryptographic constructions employed by the firmware when protecting the confidentiality or
integrity of any critical assets.
* Improper handling of cryptographic material, e.g. keys, counters, nonces, seeds.
* Trust-boundary violations between privilege levels or across components, such as confused deputy problems or
insufficient privilege separation between a firmware’s user and supervisor modes.
* Identify outdated third-party libraries which are associated with publicly known CVEs.
* Evaluation of exploit mitigation technologies such as: Address space randomization, stack canaries, data
execution prevention, NULL page mapping, guard pages, and so on.
* **Sensitive Functionality Review** \
The SRP should review the firmware source code and should describe the presence and scope of all
security-sensitive or commonly “restricted” functionality. This review can be used by consumers to measure risk
and to configure deployment or isolation controls. The review scope should include:
* TCG DICE implementation.
* SPDM implementation.
* Remote firmware update, manageability, or command and control functionality.
* Manufacturing, debug, diagnostics, testing and logging capabilities.
* Unauthenticated APIs.
* Safe generation and handling of all cryptographic material.
* Encryption capability controls (disk encryption, erase, rotation).
* Secure boot key rotation capabilities.
* **Scope 2 - Focusing on Trust boundaries:** Includes all of the areas of Scope 1 above, with deeper review focus of the following areas:
* Trusted execution environment assessment
* Handling of trust boundaries
* Attestation and non-repudiation across boundaries
* Authenticated and encrypted IO, e.g., PCIe-IDE, TDISP, or vendor proprietary
* **Scope 3 - Resilience to physical attacks**
* Critical components and operations are designed to securely handle glitch attacks in a documented way
* Crypto blocks are designed to be resistant to side channel analysis.

## OCP Report Deliverables

This framework stipulates that the following be delivered to the OCP SAFE program for publication in the appropriate
public [GitHub](https://github.com/opencomputeproject/OCP-Security-SAFE) repositories after the review (and remediation and re-testing)
has concluded:

* **Scope Document** \
DV and SRP should jointly negotiate the scope of the review, based on the
[review areas](#security-review-scope). As alluded to above, the areas are neither exhaustive nor complete, therefore
DV and SRP should jointly negotiate the scope of the review, based on the general
[Review Scope](./review_scope.md). As alluded to above, the areas are neither exhaustive nor complete, therefore
the DV is encouraged to socialize the Scope with the OCP Security WG, either through its regular calls, or on its
mailing list. The scope itself can be any number of documents, as long as the concatenation of them is provided to the OCP Security
WG. Aside from level of assessment effort, no part of the DV/SRP statement of work, NDAs, etc. needs to be published.
Expand All @@ -262,7 +184,7 @@ has concluded:
in the signed SFR (after remediation and retesting). This document will summarize the audit scope, and uniquely identify
the vendor, device and firmware version by means of a firmware hash. This report will enumerate all vulnerabilities
with a CVSS score and a brief summary. The short-form report specification can be found in
[Appendix B](#appendix-b-machine-readable-short-form-report-format). To claim OCP SAFE endorsement for a
[here](./corim_profile/ocp-safe-sfr-profile.cddl). To claim OCP SAFE endorsement for a
product-firmware combination this report must be published to the OCP GitHub repository. This signed SFR is delivered
to the DV for publication.
* **GitHub Pull Request Submission**\
Expand All @@ -278,8 +200,7 @@ has concluded:
the submission may choose to additionally include the human-readable SFR documents.
* **SRP Public Key Pull Request Path**\
The public signing key of each SRP is published to the location SRP_certificates/$SRP. These are to be published and maintained by
the SRP, and may be revoked by the TAC (see [Disqualification](#Disqualification) above).

the SRP, and may be revoked by the TAC (see [SRP Approval Process](./srp_approval_process.md)).

In addition to the short-form report, the SRP should deliver to the DV a detailed report. This report will likely be
protected by NDA and will not be published. The DV should address the findings in the report. The DV is encouraged to
Expand Down Expand Up @@ -313,8 +234,3 @@ Several SRP sample reports can be found in [Appendix A](#appendix-a-example-repo
and other [public reports](https://www.nccgroup.com/us/research-blog/?category=18157#hub)
* NCC's first review of [Caliptra](https://chipsalliance.github.io/Caliptra/) can be
found [here](https://github.com/chipsalliance/Caliptra/blob/main/doc/NCC_Group_Microsoft_MSFT283_Report_2023-10-13_v1.2.pdf)

# Appendix B: Machine Readable Short-Form Report Format

A reference implementation of the library to produce and verify short form reports is available
in [this repo](https://github.com/opencomputeproject/OCP-Security-SAFE).
Loading
Loading