Replies: 3 comments 2 replies
-
Suggestions from TSC on 06/14
|
Beta Was this translation helpful? Give feedback.
-
It'd be good to get the actual process here. Suppose a Critical comes in, what does Sig-security actually do? Emails? Documents? Issues? Then how doe sig-security get it to be fixed? Or is that the end of the responsibility of sig-security? If so, by what mechanism is it actually fixed? If there's no (even dotted) line of action between report, expectation and fix, its unlikely to be actually fixed. |
Beta Was this translation helpful? Give feedback.
-
@lawsonamzn We have a response RFC that needs to be actioned by the SIG: https://github.com/o3de/sig-security/blob/main/rfcs/rfc-sec-20220316-1.md As is SIG/Security runs campaigns, sets expectations, but we cannot fix any and all security issues in O3DE. We will escalate with TSC where needed to ensure issues are fixed by SIGs that own code. |
Beta Was this translation helpful? Give feedback.
-
This is an attempt to define the Service Level Agreement (SLA)/Expectations for triaging and fixing security issues for O3DE. These SLAs are proposed as guidance to SIGs so they can prioritize resources appropriately. When SLAs are breached SIG-Security will followup with SIGs to set new ETAs. The expectation is that in future we could setup automated reporting to highlight issues at risk.
WD == Working days (defining as O3DE "business" days)
SLAs are designed to be "generous" to SIGs and acknowledge they do not have dedicated resources but volunteers. But we also want to place security at the heart of O3DE processes.
These are SLAs for disclosed public security issues, private issues should be covered by our embargo time process. We have a default max embargo time to fix of 90 days, for private issues. However embargo time is negotiated with the reporter.
Expectations for timeline:
Beta Was this translation helpful? Give feedback.
All reactions