Feedback wanted: AssureLoop v0.3 hardware-alpha

[tendervault]

AssureLoop v0.3 hardware-alpha is now published.

Website: https://assureloop.dev/
Release: https://github.com/tendervault/assureloop/releases/tag/v0.3.0-hardware-alpha

This release demonstrates a local Zephyr + MCUboot release assurance workflow on one physical board: ST NUCLEO-H563ZI.

Current proof points include:

• signed image evidence
• SBOM and release manifest generation
• evidence bundle and update package verification
• MCUboot boot validation
• hardware update swap / rollback / confirm behavior
• tampered update rejection
• downgrade update rejection

Important boundaries:

• not a new OS
• not production OTA
• not production secure boot
• not a safety or cybersecurity certification claim
• currently validated on one board only

I’m looking for feedback from embedded firmware, Zephyr, MCUboot, product security, release engineering, and industrial IoT people.

Questions:

1. Is this kind of release evidence useful in real firmware workflows?
2. What evidence do you currently collect before shipping firmware?
3. Are SBOMs, signed images, release manifests, and update package verification part of your current process?
4. What would make this more useful?
5. What would stop a team from adopting something like AssureLoop?

Critical feedback is welcome.