Affected source
Identify the affected commit, tag, file or artifact.
Menu
OPENRGD SECURITY
Report vulnerabilities without turning disclosure into additional risk.
The canonical repository contains a draft standard and a non-actuating alpha toolchain. Security reporting therefore covers source, tooling, integrity and supply-chain issues while keeping physical-runtime responsibility explicit.
CITATION RECORD
MATURITYSECURITY POLICY SUMMARY
LAST VERIFIED27 Sep 2026
SOURCE VERSIONSECURITY.md · current main lineage
EVIDENCE BOUNDARYPublic web summary of the repository security policy; SECURITY.md remains authoritative and OpenRGD does not certify physical robot safety.
Use a private GitHub security advisory when available.
If private vulnerability reporting is unavailable, open only a minimal public issue containing [SECURITY CONTACT REQUEST] and ask for a private disclosure channel. Do not include proof-of-concept code, secrets, device addresses or exploitation details.
PRIVATE REPORT
Provide enough evidence to reproduce and bound the issue.
Impact
Describe impact, preconditions and the smallest useful reproduction evidence.
Physical scope
State whether hardware, middleware or an external Body Adapter is involved.
Mitigation
Include any known safe mitigation or containment path.
Disclosure risk
Flag whether public details could create immediate physical or operational risk.
Data minimization
Do not include secrets, personal data or unnecessary private reasoning transcripts.
PHYSICAL SAFETY
Actuation vulnerabilities belong to the responsible runtime or adapter too.
When a report involves physical actuation, the responsible embodied-runtime or Body Adapter implementation must also receive the report once identified. The canonical OpenRGD repository cannot authorize hardware execution or certify a robot as safe.
SAFE REPRODUCTION
Prefer simulation, fixtures and fail-closed tests.
Suspected actuation vulnerabilities should not be reproduced on live hardware unless the system is isolated, independently supervised and physical testing is necessary to establish the issue.
SUPPLY CHAIN
Integrity metadata is security-relevant, but a digest is not authorship.
Source-tree hashes
Unexpected changes to canonical integrity commitments should be reported.
Release tags
Unexpected movement, replacement or inconsistent release identity is security-relevant.
CI workflows
Changes that alter validation, release or provenance behavior deserve scrutiny.
Generated artifacts
Unexpected checksums or generated outputs may indicate a broken or compromised pipeline.
Dependencies
Dependency-resolution changes can alter the trusted execution path.
Signing metadata
Signing and provenance claims must remain distinguishable from plain content hashes.
PUBLIC DISCLOSURE
Publish the record when disclosure no longer increases risk.
The canonical policy calls for a public advisory or issue after a safe fix or mitigation is available, or when coordinated disclosure is no longer possible. Public records should distinguish confirmed facts, affected versions and unresolved risk.
SOURCE OF TRUTH