Ability to make Security / Vulnerability bugs non-public

[nashif]

Reported by Mark Linkmeyer:

See Summary

(Imported from Jira ZEP-1296)

[nashif]

by Inaky Perez-Gonzalez:

Mark Linkmeyer who do I have to contact in the JIRA admins to make this possible?

[nashif]

by Mark Linkmeyer:

Hi Inaky Perez-Gonzalez , you'll need to make a proposal to the Zephyr Process WG on how you'd like to change Jira to support this. Once the changes are approved we'll get Andy of The Linux Foundation to make the change. The Zephyr Process WG meets every Monday at 9am PST. Let me know when you want on the agenda. There's time in next Monday's meeting, if you're ready.

[nashif]

by Inaky Perez-Gonzalez:

Proposal:

• A boolean field shall be added to JIRA bugs to mark it security sensitive (or any other name that makes sense). This renders the entry invisible to anyone except as described below.
• security sensitive bugs are only accessible (view/modify) to members of the Security Group; members of this Security Group are: members of the Security Working Group other as proposed and ratified Security Working Group, who will also have the authority to remove others ** the reporter
• Security Working Group meetings have to review the embargoed bugs on every meeting with more than three people in attendance. Said review process shall decide if new issues needs to be embargoed or not.
• security sensitive bugs shall to be made public (by removing the security sensitive indicator) after an embargo period of TBD days. The Security Working Group is the only entity with authority to extend the embargo period on a case by case basis; the JIRA entry should be updated with the rationale for the embargo extension so at some point said rationale will be made public.If the Security Working Group does not act upon a security sensitive bug after its TBD days of embargo are over, it shall be automatically made public by removing the security sensitive setting.
• [per Kate's comment] Likewise, there shall be code repositories marked as security sensitive, accessible only to the Security Group members where the code to fix said issues is being worked on and reviewed. The person/s contributing the fix shall also have access, but fix contributors shall have only access to the tree for said fix, not to other security sensitive trees.
• A CVE space shall be allocated to assign Zephyr issues when the SWG decides such is needed.

[nashif]

by Inaky Perez-Gonzalez:

Anas, I probably won't be able to attend the 7am SWG this Friday -- in case I don't, can you bring the proposal forward on my behalf? I was supposed to present it.

[nashif]

by Anas Nashif:

assigning back to you, we did not get to it last meeting, so you can address this in the next meeting.

[nashif]

by Inaky Perez-Gonzalez:

ARs: do more research on CVE assignment and interaction, vetting process for new security issues (accepted as embargoed or not), adding an embargo end date field.

[nashif]

by Andy Gross:

Need to add one thing to the accessibility control section: Ability to add other users for individual issues

[nashif]

by Mark Linkmeyer:

Hi Andy Gross , what needs to happen on this yet to get the proposal approved? I ask because I'd like to drive getting Jira updated accordingly, once it's approved. I see your comment from May 5th, but it's not clear who needs to (or who will) add what you mention as needed. To whom was your comment directed?

[nashif]

by Andy Gross:

Mark,

This was to Inaky. Is there someone else who should be driving this from an implementation standpoint?

[nashif]

by David Brown:

A couple of thoughts on the implementation:

• I don't think disembargo should be automated, but done by manual review. It's better to embargo slightly too long than not long enough.
• There needs to be a field to add users that have the ability to view the issue. Having a group that can view is fine, but interested parties will need to be added to the ticket.