Security Vulnerability Management Process for SONiC Community #1654
Conversation
zhangyanzhao
requested review from
liat-grozovik,
adyeung,
eddieruan-alibaba,
balajib-cisco,
bhagatgit,
lguohan and
jeff-yin
|
TSC members, can you please help to review and approve this PR? Thanks. |
|
Looks good to me. |
|
Is there a template to report SONiC security issues? |
| We appreciate security researchers and SONiC users that report vulnerabilities to the SONiC Open Source Community. All reports will be investigated thoroughly by the SONiC security committee. | ||
| ## 2.Vulnerability Disclosure | ||
| Once a mitigation/fix is reviewed and approved by SONiC security committee, the vulnerability disclosure process starts. | ||
| Mitigation/fix for public known vulnerabilities will be released right away once approved by SONiC security committee. Fix/mitigation for non-public vulnerabilities should also come out as soon as possible, but we may postpone them if the reporter or an affected party request so. However, the delay should be no more than 90 days from when a mitigation/fix is ready. The SONiC security committee should create a template for disclosing vulnerability. |
There was a problem hiding this comment.
Depends on the severity, 90 days may be too long for critical CVE, committee should come up with a timeline for each severity
There was a problem hiding this comment.
issues open by security researcher are usually more time sensitive since tey want to publish their findings, so such issue need to prioritized. also need to understand if 90 day is acceptable in such cases ( it may be far shorter like 0/60 days)
There was a problem hiding this comment.
issues in open code packages is different than sonic code issues, so i think we need to handle that differently
first such issues may have being fixed in later versions
i think we need to set a policy to work with open code
- we need to score any open code package - based on security / frequency of fix / known issues ..
- new open code can only used if "security" score is better that a predefine level
- as part of sonic release need to update to last stable any open code with security issues
There was a problem hiding this comment.
regrading security issues with hw , i believe it should be handled by odm , with the exception of kernel related fixed that apply to Debian
There was a problem hiding this comment.
one additional note is that on optional feature possible mitigation an be to disable the functionality
There was a problem hiding this comment.
Depends on the severity, 90 days may be too long for critical CVE, committee should come up with a timeline for each severity
The 90 days is the longest waiting time from when a mitigation/fix is ready to provide enough buffer to patch their system whoever is concerned. Committee can further refine that timeline based on severity.
There was a problem hiding this comment.
issues in open code packages is different than sonic code issues, so i think we need to handle that differently first such issues may have being fixed in later versions i think we need to set a policy to work with open code
- we need to score any open code package - based on security / frequency of fix / known issues ..
- new open code can only used if "security" score is better that a predefine level
- as part of sonic release need to update to last stable any open code with security issues
@marvellgit can you please elaborate a bit on "open code packages"? I do not quite understand your comments.
There was a problem hiding this comment.
like frr or other linux project we use in sonic
Security template will be defined later by security committee. The 90 days is the duration from date when mitigation is identified to vul expose date, overall, we expect the reported issues to be mitigated as soon as possible. |
Security committee can define a template if they want. The 90 days is the longest waiting time from when a mitigation/fix is ready, we expect the vulnerability is mitigated as soon as possible. |
|
@adyeung @balajib-cisco @eddieruan-alibaba can you please help to approve this PR if you are ok with the updated content? Thanks. |
This document outlines SONiC vulnerability reporting and management process.