Tag-security: [Suggestion] Updates to Lead Security Reviewer Role and Security Assessments Guide and phrase naming

[TheFoxAtWork]

Description:

1 - Clarifying Question changes

• [ ] Change Dumb question phase to Clarifying Question Phase in assessment guide
• [ ] Update Clarifying Question Phase as the responsibility of the Lead Security Reviewer explicitly or their designee
• [ ] explain what Clarifying Question phase is
• [ ] Clarifying question phase is adhoc and not in the 3 week cycle.

2 - Lead Security Reviewer Changes

• [ ] Update Lead Security Reviewer role to state Clarifying Question Phase is their responsibility
• [ ] explain why limited to them or their delegate
• [ ] Clarifying Question phase is also an initial pass before other reviewers to ensure document content is clearly understood, terms explained, concepts have context. This enables reviewers to focus on security and technical details. Provide option to delegate this function.

3 - Reviewer Role Changes

• [ ] Update other Reviewer roles to exclude Clarifying Question Phase unless delegated
• [ ] point back to what the phase is (clarifying question) and who is responsible.

4 - Assessment Guide Changes

• [ ] Update assessment guide with more content: suggestion to review the repo
• [ ] list where final assessment slides are placed in the repo as part of the security assessment guide/outline/expectations.
• [ ] clearly define format for conflict of interest
• [ ] explain importance of conflict of interest statements
• [ ] identify conflict review phase

5 - Self-Assessment Template Updates (outline)

• [ ] Update the self-assessment template to encourage cross-linking to relevant sections of the repo or other docs
• [ ] update self assessment with section for threat model to ensure projects have the opportunity to include it.
• [ ] include section for Critical Functions & Features that are security relevant to the software. These items could then be leverage for future reviews under change detection as well as manageable items for a security audit.

[TheFoxAtWork]

also need to add more content to the security assessment guide, reviewing the repo. Also maybe update the self-assessment template and include language to encourage cross-linking to relevant sections from the repo.

[TheFoxAtWork]

Updates to include the lead reviewer doing an initial pass to ensure all other reviewers can clearly understand the content of the document, what do the terms mean? what is the context for the concepts introduced, etc. this allows reviewers to ask more pointed technical questions of the assessment

[TheFoxAtWork]

some Notes on this for are in the Feb 19 meeting

[TheFoxAtWork]

from @ultrasaurus : Also see: https://github.com/cncf/sig-security/labels/assessment-process

[ficcaglia]

Updates to include the lead reviewer doing an initial pass to ensure all other reviewers can clearly understand the content of the document, what do the terms mean? what is the context for the concepts introduced, etc. this allows reviewers to ask more pointed technical questions of the assessment

although I would tweak to allow for delegating this --- as is now the case for the Cloud Custodian assessment where Sarah is lead but I am doing the initial pass on the self assessment doc

[lumjjb]

One of the things i found during the review was that the dumb question phase, could be ad-hoc and not necessarily be part of the 3 week review cycle as discussed. This could start by anyone that has volunteered for the review. (and could be part of the initial requirement as part of the pre-assessment phase).

[lumjjb]

@anvega I think you had some ideas for improvements for the assessments as well.

[ultrasaurus]

Note: Clarifying question phase is in the outline ...

Upon request by the project, security reviewer may do an inital review to verify completeness, ask for clarifications and provide quick feedback

I think we switched it up (at least I did in my mind and didn't look back at the doc) and decided it's always needed

[TheFoxAtWork]

per slack discussion:
Okay - so for the purposes of the self-assessment. create a section to enumerate critical features/functions of the software that are security relevant, As a starting point. These items could then be leverage for future reviews under change detection as well as manageable items for a security audit.

[chasemp]

A note from the Spiffy/Spire call yesterday (which was very informative and great), it was brought up features were added to Spire mid-flight during the review period. It leaves a kind of gaping hole in terms of what version or release exactly does the review relate to? These things are always point-in-time, etc. At my place of business we do smaller scale similar risk assessments and readiness reviews and these tie back to a specific commit hash or tag in the repo. A rolling release project is great, but there has to be a consistent anchor for posterity if the assessments are going to be meaningful in terms of integration within the ecosystem and lifecycle of feature maturity and addition.

tldr; assessments should reference a specific commit explicitly to avoid tacitly approving, or incidentally appearing to approve of, features and code added during (or in the future) which is not part of any assessment.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.

[TheFoxAtWork]

Closing as OBE reference #449