Tag-security: Assessments Listing

Created on 17 Jun 2019  Â·  26Comments  Â·  Source: cncf/tag-security

To Do:

  • [ ] Create general README in assessments/projects
  • [ ] updated Assessment process to create a README in each project folder
  • [ ] Link audits, if occurred, on the project's README

Background/original info:

Description: Recommend creating a Closed Assessments folder in Assessments to organize and store all assessment docs per project
Assessments/Closed Assessments/Project1README.md

Project1README.md lists ticket numbers of the request, dates of the activities, CNCF state at time of assessment, reviewers, project lead, etc. recommendation summary, and links to final report. (think of first glance info of high level info without digging into the final report - report has more details and should be linked to where we store it).

Impact: Provide centralized location for identifying previous projects worked by CNCF Security SIG. Provide high level overview of those previous efforts.

assessment-process good first issue help wanted

Most helpful comment

there is an open issue to document the fact that security assessments last for one year and that we plan to do some kind of mini-review of whatever has changed: https://github.com/cncf/sig-security/issues/152

All 26 comments

This is great. Thanks for writing this up! I've been thinking of the process as:

  • requested (issue) ==>
  • active / in-progress / draft ==>
  • completed / done / published

The "assessement" is both an activity and an outcome. After we have finished the activity, then the document is ready and available for people to use in helping them consider whether the project meets their needs... so "closed" doesn't work so well from my perspective.

I will draft a README for in-toto, which may help. The self-assessment just got changed into markdown and so adding README/Summary is next step: https://github.com/cncf/sig-security/tree/master/assessments/projects/in-toto

I think this will lead to another question on the effective period of one assessment. Say we marked OPA done for assessment, will there be a time we need to re-assess given probably the project has been undergoing changes ? Shall we mark an "effective period" that when that period expires the sig needs to do a update assessment ?

I think we should stick to each phase of CNCF model, any changes in the projects status should prompt a review (pre-incubation, incubation to sandbox, sandbox to graduation, and once every yr-two yrs? Or perhaps a review for every major version/release?

I think we should stick to each phase of CNCF model, any changes in the projects status should prompt a review (pre-incubation, incubation to sandbox, sandbox to graduation, and once every yr-two yrs? Or perhaps a review for every major version/release?

I think this is a great idea to align with CNCF project lifecycle :) Per release might be too much of duplicated work

there is an open issue to document the fact that security assessments last for one year and that we plan to do some kind of mini-review of whatever has changed: https://github.com/cncf/sig-security/issues/152

maybe we should have a README in the /assessments/projects/ folder

=> @JustinCappos to resolve when back from vacation

Definitely recommend a README in that folder. Content should include the life expectancy of each assessment as well as kind of assessment based on stage in CNCF.

@ultrasaurus recommend merging this ticket and #152 to cover creation of a README including all of this.

Also create a "unofficial" listing for when vendors or projects come to us with evidence of an audit or outside of CNCF, we can store alongside the "official" listing of what security has done.

Given I'm conflicted with in-toto, I'm probably not the right person to
write the document for it. However, I can do the OPA one.

On Wed, Jul 3, 2019 at 1:52 PM Emily The Moxie Fox notifications@github.com
wrote:

Also create a "unofficial" listing for when vendors or projects come to us
with evidence of an audit or outside of CNCF, we can store alongside the
"official" listing of what security has done.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cncf/sig-security/issues/206?email_source=notifications&email_token=AAGROD3FNVX5XXGS62T7P3LP5TRMBA5CNFSM4HYYZETKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZFGXAI#issuecomment-508193665,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGROD5VZU45NRDWLFJGQILP5TRMBANCNFSM4HYYZETA
.

related issue: prioritization / intake process guidelines: https://github.com/cncf/sig-security/issues/281

I think it would be great if the TBD README listed the projects that had been audited as well as the assessments. I can't seem to find a list of the CNCF security audits -- anyone have a link to that?

maybe @justincormack @caniszczyk @JustinCappos know where those are listed?

Okay, we're reaching out to @caniszczyk to get the audit list. Once we have that, I think we can put a table together.

@TheFoxAtWork Do you feel we need to have a separate closed folder? Things don't get merged into here until we have finished, so to me these folders already have the assessments. I'd more like to just surface some metadata from the subfolders to make it easier for people to understand what has happened without opening a ton of READMEs.

309 I'd like to keep the in-progress items (which are tracked by issues) separate from this so we do not duplicate effort.

Once we're in rough agreement, I can go ahead and make the changes...

heard via email from @amye -- she's tracking down list of audits and will add them here

Looking forward to seeing this. I know several folks have been looking for
such a resource...

On Tue, Dec 17, 2019 at 11:33 PM Sarah Allen notifications@github.com
wrote:

heard via email from @amye https://github.com/amye -- she's tracking
down list of audits and will add them here

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cncf/sig-security/issues/206?email_source=notifications&email_token=AAGROD7JAH4G3AUHP5KSFVDQZGR3NA5CNFSM4HYYZETKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHE2KQQ#issuecomment-566863170,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGROD3LNCID2SPC7SXAS5DQZGR3NANCNFSM4HYYZETA
.

With the current project board, should this be resolved? @ultrasaurus @JustinCappos

concur with @lumjjb

I thought this issue would be resolved with a readme for assessments/projects that linked to assessments as well as audits

reading back through the ticket and discussion, want to double check before updating the ticket:

  1. Create general README in (assessments/projects)[https://github.com/cncf/sig-security/tree/master/assessments/projects]
  2. updated Assessment process to create a README in each project folder
  3. Link audits, if occurred, on the project's README

@ultrasaurus @JustinCappos does this work?

Works for me!

updated - over to you @JustinCappos

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

This still needs to happen -- all the projects have READMEs, looks like it is just a matter of linking them via a root README. Anyone could submit the PR for that I think.

Maybe create a separate issue for the audits: and assign to @caniszczyk who was going to dig up that info

Planning on updating this ticket to rescope based on discussion:

  • [ ] Create general README in assessments/projects
  • [ ] in assessments/guide update Step 5, task 3 "Project lead prepares a PR to /assessments/project-docs/project-name/" to include a README for the project. README should include link to the original issue for assessment, assessment date, and project status at time of assessment (pre-incubation, incubation, sandbox, etc.).

Audit linking should be a separate ticket
@lumjjb @JustinCappos @ultrasaurus ?

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

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

  • assessments/guide

the joint-review README template needs updated to specify:

  • [ ] original issue for assessment,
  • [ ] assessment date, and
  • [ ] project status at time of assessment (pre-incubation, incubation, sandbox, etc
Was this page helpful?
0 / 5 - 0 ratings