
The CRA readiness report (CRA_READINESS.md): an honest readiness-aid header, an at-a-glance count, and the SBOM (SPDX) section.
What one click gives you
- SBOM from your real build. A machine-readable software bill of materials (SPDX), the CRA’s named artifact, generated from your actual build with the vendor-native tools.
- Secure-by-design posture against your build’s actual configuration: secure boot, signed updates, debug-port lock, secure pairing, secure storage and more, each with the plain-English requirement and the fix, ranked so you tackle the biggest gap first.
- Bring a CVE, and close it. Hand it a CVE from a vendor advisory: it confirms the affected component is really in your build (a literal SBOM lookup), links the advisory, then helps you bump the version, rebuild, and regenerate the SBOM.
- Fix in the loop, not just flag. It helps you wire the top fix (a secure bootloader, for example), rebuild, and re-verify, without leaving the agent.
- Version advisories for your detected SDK (links to review, never an automatic verdict).
compliance/ folder (report + machine-readable JSON + SBOM).
Run it
1
Open your project, or none at all
Run it on your own nRF or ESP firmware, or try it on a bundled sample with nothing open.
2
Pick CRA SBOM & Fix
From the home workflow cards, choose CRA SBOM & Fix. The agent builds the SBOM, reads your real config, and drafts the readiness report.
3
Read the report, then close the top gap
Open
compliance/CRA_READINESS.md. The posture gaps are ranked, so start at the top: wire the fix, rebuild, and re-verify in the same loop.What it is not
- Not a conformity assessment or certification. It never asserts “compliant” or “conformant”. Only a notified body or your formal assessment establishes that.
- Not a vulnerability scanner. The CVE flow confirms a component you name is present in your build and helps you patch it. It does not search for unknown CVEs.
- Not legal advice. It surfaces evidence and the requirement in plain English; the interpretation is yours.

