[Starlingx-discuss] CVE Support and Scanning
Team, A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below: https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_Policy Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday. Regards, Ken Y
On 2/4/19 10:48 AM, Young, Ken wrote:
Team,
A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below:
https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_Policy
Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday.
Can we try to avoid slideware in the Wiki please, ultimately wiki should be editable. Sau!
Regards,
Ken Y
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Mon, Feb 4, 2019 at 12:49 PM Young, Ken <Ken.Young@windriver.com> wrote:
Team,
A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below:
https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_Policy
Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday.
Question on the last slide you propose a formula as Criticality >= 7 What standard are you plan to use? CVSS v3.0 or v2.0 For example, taking this MariaDB https://nvd.nist.gov/vuln/detail/CVE-2017-15365 Base Score: 8.8 HIGH in V3 and 6.5 MEDIUM in V2 My recommendation will be to use the highest one despite if the score came from V2 or V3 However, I think we should specify that somewhere One more question, when you said critical issues are fixed if corrections are available upstream it means that ( taking the previous example ) if MariaDB provides a Patch, is merged in master and released in the latest release, like in the previous example : https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7e753699787f... But CentOS has not taken it yet, are we OK to apply this patch in STX until CentOS apply in incoming future? Regards Victor R
Regards,
Ken Y
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Victor wrote:
One more question, when you said critical issues are fixed if corrections are available upstream it means that ( taking the previous example ) if MariaDB provides a Patch, is merged in master and released in the latest release, like in the previous example : https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7e753699787f...
But CentOS has not taken it yet, are we OK to apply this patch in STX until CentOS apply in incoming future?
If we are picking up a component from a distro (like CentOS), I think the policy should be that we pick up the change from the distro. If we're picking up a component directly from its upstream, we pick up the fix from the upstream. So I think the answer is "it depends". brucej -----Original Message----- From: Victor Rodriguez [mailto:vm.rod25@gmail.com] Sent: Monday, February 4, 2019 11:27 AM To: Young, Ken <Ken.Young@windriver.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] CVE Support and Scanning On Mon, Feb 4, 2019 at 12:49 PM Young, Ken <Ken.Young@windriver.com> wrote:
Team,
A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below:
https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_Policy
Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday.
Question on the last slide you propose a formula as Criticality >= 7 What standard are you plan to use? CVSS v3.0 or v2.0 For example, taking this MariaDB https://nvd.nist.gov/vuln/detail/CVE-2017-15365 Base Score: 8.8 HIGH in V3 and 6.5 MEDIUM in V2 My recommendation will be to use the highest one despite if the score came from V2 or V3 However, I think we should specify that somewhere One more question, when you said critical issues are fixed if corrections are available upstream it means that ( taking the previous example ) if MariaDB provides a Patch, is merged in master and released in the latest release, like in the previous example : https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7e753699787f... But CentOS has not taken it yet, are we OK to apply this patch in STX until CentOS apply in incoming future? Regards Victor R
Regards,
Ken Y
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi Victor,
My recommendation will be to use the highest one despite if the score came from V2 or V3
The two sets of metrics are not comparable. StarlingX policy should refer to either CVSS v2 or v3.
One more question, when you said critical issues are fixed if corrections are available upstream it means that...
The text of one of the slides has written "StarlingX depends on the upstream OS community to fix CVEs". Is this reference to upstream you intend? In that text 'OS community' would refer to CentOS community rather than the example MariaDB community. M On Mon, 2019-02-04 at 13:26 -0600, Victor Rodriguez wrote:
On Mon, Feb 4, 2019 at 12:49 PM Young, Ken <Ken.Young@windriver.com> wrote:
Team,
A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below:
https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_Poli cy
Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday.
Question on the last slide you propose a formula as
Criticality >= 7
What standard are you plan to use? CVSS v3.0 or v2.0
For example, taking this MariaDB
https://nvd.nist.gov/vuln/detail/CVE-2017-15365
Base Score: 8.8 HIGH in V3 and 6.5 MEDIUM in V2
My recommendation will be to use the highest one despite if the score came from V2 or V3 However, I think we should specify that somewhere
One more question, when you said critical issues are fixed if corrections are available upstream it means that ( taking the previous example ) if MariaDB provides a Patch, is merged in master and released in the latest release, like in the previous example : https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7e753 699787fdf46e
But CentOS has not taken it yet, are we OK to apply this patch in STX until CentOS apply in incoming future?
Regards
Victor R
Regards,
Ken Y
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Mon, Feb 4, 2019 at 2:25 PM Michel Thebeau <michel.thebeau@windriver.com> wrote:
Hi Victor,
My recommendation will be to use the highest one despite if the score came from V2 or V3
The two sets of metrics are not comparable. StarlingX policy should refer to either CVSS v2 or v3.
But slide in the wiki say : Criticality >= 7 , if V2 = 5 adn V3 =8 shoudl that CVE be consider as Criticality >= 7 ? My observation is that we shoudl specify Criticality >= 7 ( for either V2 or V3 )
One more question, when you said critical issues are fixed if corrections are available upstream it means that...
The text of one of the slides has written "StarlingX depends on the upstream OS community to fix CVEs". Is this reference to upstream you intend? In that text 'OS community' would refer to CentOS community rather than the example MariaDB community.
Ok, thanks for the clarification. I think that there might be some special cases where we might prompt to apply a CVE patch before CentOS, but that might have to be desided in the security meeeting when they analyze the CVEs
M
On Mon, 2019-02-04 at 13:26 -0600, Victor Rodriguez wrote:
On Mon, Feb 4, 2019 at 12:49 PM Young, Ken <Ken.Young@windriver.com> wrote:
Team,
A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below:
https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_Poli cy
Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday.
Question on the last slide you propose a formula as
Criticality >= 7
What standard are you plan to use? CVSS v3.0 or v2.0
For example, taking this MariaDB
https://nvd.nist.gov/vuln/detail/CVE-2017-15365
Base Score: 8.8 HIGH in V3 and 6.5 MEDIUM in V2
My recommendation will be to use the highest one despite if the score came from V2 or V3 However, I think we should specify that somewhere
One more question, when you said critical issues are fixed if corrections are available upstream it means that ( taking the previous example ) if MariaDB provides a Patch, is merged in master and released in the latest release, like in the previous example : https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7e753 699787fdf46e
But CentOS has not taken it yet, are we OK to apply this patch in STX until CentOS apply in incoming future?
Regards
Victor R
Regards,
Ken Y
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Mon, 2019-02-04 at 14:41 -0600, Victor Rodriguez wrote:
On Mon, Feb 4, 2019 at 2:25 PM Michel Thebeau <michel.thebeau@windriver.com> wrote:
Hi Victor,
My recommendation will be to use the highest one despite if the score came from V2 or V3
The two sets of metrics are not comparable. StarlingX policy should refer to either CVSS v2 or v3.
But slide in the wiki say : Criticality >= 7 , if V2 = 5 adn V3 =8 shoudl that CVE be consider as Criticality >= 7 ? My observation is that we shoudl specify Criticality >= 7 ( for either V2 or V3 )
I believe that Ken has a particular metric in mind, which was not documented. The value of '7' is specific to the metric not documentated. There is a hint in the document that the value '7' is for 'critical' CVEs issues. ... refer to this document: https://nvd.nist.gov/vuln-metrics/cvss '7' is the boundary for the highest rating of CVSS v2. Where as CVSS v3 lists critical as >9.0
One more question, when you said critical issues are fixed if corrections are available upstream it means that...
The text of one of the slides has written "StarlingX depends on the upstream OS community to fix CVEs". Is this reference to upstream you intend? In that text 'OS community' would refer to CentOS community rather than the example MariaDB community.
Ok, thanks for the clarification. I think that there might be some special cases where we might prompt to apply a CVE patch before CentOS, but that might have to be desided in the security meeeting when they analyze the CVEs
I expect that it is unlikely a team in StarlingX will match the proficiency of the teams behind CentOS. But I agree that the StarlingX community will discuss these things. M
M
On Mon, 2019-02-04 at 13:26 -0600, Victor Rodriguez wrote:
On Mon, Feb 4, 2019 at 12:49 PM Young, Ken <Ken.Young@windriver.c om> wrote:
Team,
A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below:
https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_ Poli cy
Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday.
Question on the last slide you propose a formula as
Criticality >= 7
What standard are you plan to use? CVSS v3.0 or v2.0
For example, taking this MariaDB
https://nvd.nist.gov/vuln/detail/CVE-2017-15365
Base Score: 8.8 HIGH in V3 and 6.5 MEDIUM in V2
My recommendation will be to use the highest one despite if the score came from V2 or V3 However, I think we should specify that somewhere
One more question, when you said critical issues are fixed if corrections are available upstream it means that ( taking the previous example ) if MariaDB provides a Patch, is merged in master and released in the latest release, like in the previous example : https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7 e753 699787fdf46e
But CentOS has not taken it yet, are we OK to apply this patch in STX until CentOS apply in incoming future?
Regards
Victor R
Regards,
Ken Y
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-di scus s
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-disc uss
On Mon, Feb 4, 2019 at 3:01 PM Michel Thebeau <michel.thebeau@windriver.com> wrote:
On Mon, 2019-02-04 at 14:41 -0600, Victor Rodriguez wrote:
On Mon, Feb 4, 2019 at 2:25 PM Michel Thebeau <michel.thebeau@windriver.com> wrote:
Hi Victor,
My recommendation will be to use the highest one despite if the score came from V2 or V3
The two sets of metrics are not comparable. StarlingX policy should refer to either CVSS v2 or v3.
But slide in the wiki say : Criticality >= 7 , if V2 = 5 adn V3 =8 shoudl that CVE be consider as Criticality >= 7 ? My observation is that we shoudl specify Criticality >= 7 ( for either V2 or V3 )
I believe that Ken has a particular metric in mind, which was not documented. The value of '7' is specific to the metric not documentated. There is a hint in the document that the value '7' is for 'critical' CVEs issues.
... refer to this document: https://nvd.nist.gov/vuln-metrics/cvss
'7' is the boundary for the highest rating of CVSS v2. Where as CVSS v3 lists critical as >9.0
Ok , then Based on NVD Vulnerability Severity Ratings 7 is ok for both V2 or V3 We cond then said in the wiki that if CVE critilarity is >= High ...
One more question, when you said critical issues are fixed if corrections are available upstream it means that...
The text of one of the slides has written "StarlingX depends on the upstream OS community to fix CVEs". Is this reference to upstream you intend? In that text 'OS community' would refer to CentOS community rather than the example MariaDB community.
Ok, thanks for the clarification. I think that there might be some special cases where we might prompt to apply a CVE patch before CentOS, but that might have to be desided in the security meeeting when they analyze the CVEs
I expect that it is unlikely a team in StarlingX will match the proficiency of the teams behind CentOS. But I agree that the StarlingX community will discuss these things.
I have seen cases before, as CVE mantianer of an OS for some time there were times were the severity of the CVE make us really urgent to update the package and release a new version of the OS, our mindset was security first. As an open comunity I woudl like to hear more feedabck from multiple users and developers Regards Victor
M
M
On Mon, 2019-02-04 at 13:26 -0600, Victor Rodriguez wrote:
On Mon, Feb 4, 2019 at 12:49 PM Young, Ken <Ken.Young@windriver.c om> wrote:
Team,
A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below:
https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_ Poli cy
Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday.
Question on the last slide you propose a formula as
Criticality >= 7
What standard are you plan to use? CVSS v3.0 or v2.0
For example, taking this MariaDB
https://nvd.nist.gov/vuln/detail/CVE-2017-15365
Base Score: 8.8 HIGH in V3 and 6.5 MEDIUM in V2
My recommendation will be to use the highest one despite if the score came from V2 or V3 However, I think we should specify that somewhere
One more question, when you said critical issues are fixed if corrections are available upstream it means that ( taking the previous example ) if MariaDB provides a Patch, is merged in master and released in the latest release, like in the previous example : https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7 e753 699787fdf46e
But CentOS has not taken it yet, are we OK to apply this patch in STX until CentOS apply in incoming future?
Regards
Victor R
Regards,
Ken Y
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-di scus s
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-disc uss
See inline. On 2019-02-04, 2:26 PM, "Victor Rodriguez" <vm.rod25@gmail.com> wrote: On Mon, Feb 4, 2019 at 12:49 PM Young, Ken <Ken.Young@windriver.com> wrote: > > Team, > > > > A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below: > > > > https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_Policy > > > > Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday. Question on the last slide you propose a formula as Criticality >= 7 What standard are you plan to use? CVSS v3.0 or v2.0 I am suggesting we start with v2. I need to look into v3 a little more. For example, taking this MariaDB https://nvd.nist.gov/vuln/detail/CVE-2017-15365 Base Score: 8.8 HIGH in V3 and 6.5 MEDIUM in V2 My recommendation will be to use the highest one despite if the score came from V2 or V3 However, I think we should specify that somewhere Agreed. One more question, when you said critical issues are fixed if corrections are available upstream it means that ( taking the previous example ) if MariaDB provides a Patch, is merged in master and released in the latest release, like in the previous example : https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7e753699787f... But CentOS has not taken it yet, are we OK to apply this patch in STX until CentOS apply in incoming future? We will wait for CentOS. We are in the process of patch elimination. I do not to carry more. Regards Victor R > > > Regards, > > Ken Y > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss@lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Mon, Feb 4, 2019 at 4:24 PM Young, Ken <Ken.Young@windriver.com> wrote:
See inline.
On 2019-02-04, 2:26 PM, "Victor Rodriguez" <vm.rod25@gmail.com> wrote:
On Mon, Feb 4, 2019 at 12:49 PM Young, Ken <Ken.Young@windriver.com> wrote: > > Team, > > > > A “Lights On” feature for the 2019.05 release is “CVE Upgrades”. This feature will enable ongoing security updates for the master branch and selectively provide CVE corrective content to supported releases. The first step for this feature is to define a policy. With the help of the Starling X security team, a draft of this policy has been provided below: > > > > https://wiki.openstack.org/wiki/StarlingX/Security/CVE_Support_Policy > > > > Please review and provide comments. I plan to reserve a spot on the Community call for any discussion on Wednesday and start the discussion with the build team to identify tools to support this policy on Thursday.
Question on the last slide you propose a formula as
Criticality >= 7
What standard are you plan to use? CVSS v3.0 or v2.0
I am suggesting we start with v2. I need to look into v3 a little more.
For example, taking this MariaDB
https://nvd.nist.gov/vuln/detail/CVE-2017-15365
Base Score: 8.8 HIGH in V3 and 6.5 MEDIUM in V2
My recommendation will be to use the highest one despite if the score came from V2 or V3
However, I think we should specify that somewhere
Agreed.
One more question, when you said critical issues are fixed if corrections are available upstream it means that ( taking the previous example ) if MariaDB provides a Patch, is merged in master and released in the latest release, like in the previous example : https://github.com/MariaDB/server/commit/0b5a5258abbeaf8a0c3a18c7e753699787f...
But CentOS has not taken it yet, are we OK to apply this patch in STX until CentOS apply in incoming future?
We will wait for CentOS. We are in the process of patch elimination. I do not to carry more.
Hi Ken This is the link to the tool that we could use to catch the CVEs https://github.com/clearlinux/cve-check-tool Hoep it helps as an starting point Regards Victor
Regards
Victor R > > > Regards, > > Ken Y > > _______________________________________________ > Starlingx-discuss mailing list > Starlingx-discuss@lists.starlingx.io > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On 2019-02-06 15:28:24 +0000 (+0000), Victor Rodriguez wrote: [...]
This is the link to the tool that we could use to catch the CVEs
https://github.com/clearlinux/cve-check-tool
Hoep it helps as an starting point
That seems to be unmaintained for the past couple of years (last commit was from April 2017 and it has accumulated a number of untriaged issues and pull requests since then). If you're interested in using it, you may want to consider helping the previous maintainers resurrect it. Maybe also consider (actively-maintained) https://github.com/intel/cve-bin-tool which uses a different approach: looking for signs of vulnerable libraries linked into compiled files. It could help you identify when packages you're maintaining need to be rebuilt due to vulnerabilities in their dependencies. -- Jeremy Stanley
participants (6)
-
Jeremy Stanley
-
Jones, Bruce E
-
Michel Thebeau
-
Saul Wold
-
Victor Rodriguez
-
Young, Ken