Repository navigation
Improve intended behavior in SECURITY.md to avoid security advisories being submitted for functionality that is by design - #3455
richturner wants to merge 6 commits into
Conversation
Webhook actions and agent protocols connect to user-configured addresses by design. Several reports have treated this as SSRF, so state the intended behaviour, where egress restriction belongs and what remains in scope.
richturner
changed the title
wborn
left a comment
wborn
left a comment
There was a problem hiding this comment.
This is an initial AI-assisted review.
The new section provides useful clarification about intentionally unrestricted outbound connectivity and deployment-level network controls. This aligns with OpenRemote's integration capabilities and helps distinguish expected functionality from genuine security vulnerabilities.
The notification delivery and acknowledgement section should describe its intended authorization boundaries more precisely. The implementation only permits anonymous updates for notifications targeting publicly readable assets, and the security policy should explicitly preserve reports involving unauthorized notification state modifications, including those occurring within the same realm.
wborn
left a comment
wborn
left a comment
There was a problem hiding this comment.
Could the intended security behavior of Groovy rules and the read:logs role also be described here?
For example:
- Groovy: Scripts are not sandboxed and can access the filesystem and network with the Manager's privileges. Creating or modifying them is therefore restricted to superusers, regardless of the
write:rulesrole. - Logs: The
read:logsrole provides access to Manager-wide logs, including logs from other realms, rather than being restricted to the user's realm.
It would also be good to document these security boundaries in openremote/documentation, where they currently appear to be missing.
…ty policy Address review feedback: describe the anonymous notification update boundary precisely, document Groovy rules and read:logs as intended behavior, keep the related violations in scope and use US spelling.
richturner
changed the title
490460a to
4652890
Compare
|
Description
Adds a "Behavior That Is Intended" section to
SECURITY.md, which GitHub links from the vulnerability report form.Webhook actions and agent protocols connect to whatever address they are configured with, internal addresses included, and we keep receiving reports that treat this as SSRF. The section states that this is intended, that restricting egress belongs to the deployment, and which cases remain in scope: reaching these features without the required role or from another realm, exposing a response or secret to someone who could not read it otherwise, and bypassing an operator-configured destination restriction.
It sits before "What To Include" so reporters see it before they write a report.
Checklist