Description:
Define different types of security testings that we expect CNCF projects to run continuously. Consider defining levels of maturity, e.g. all projects must scan the dependencies used, optional is to run SAST/DAST and how we can reflect those levels (badges?).
Consider also defining the required tools that are considered as "good enough" - might be risky, as we'll have to endorse specific tools/vendors. OWASP projects could be a good start (Zap, dependency track, etc).
Impact: Describe your hopes for how this would reduce risk for the cloud native ecosystem. Who will this help? How will it help them?
Security testing helps to catch various security issues before merging. Ideally, issues like prometheus/prometheus#5580 will be detected earlier and not reported by external users.
Scope: How much effort will this take? ok to provide a range of options if or "not yet determined"
Small effort to define "maturity levels", a lot bigger effort to go over existing projects and map them to the right level, communicating the change etc.
If we're looking at maturity for application security, which seems like a good approach, I'd recommend looking at the OWASP Application Security Verification Standard (ASVS).
It's an actively maintained project which defines maturity levels for application security and suggests lists of requirements or tests that can be used to assess applications at varying levels
https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project#tab=Home
Yes, that's a great suggestion. ASVS is pretty long, so maybe it's better to create a subset of it.
It would be good to look at the CNCF Audits and draw from already documented practices.
Also consider referencing (rather than duplicating), relevant criteria from CII Best Practices Security
Also, I think the initial assessment of https://github.com/prometheus/prometheus/issues/5580 was that these were false positives... it would be good to include guidance on how to catalog / respond to discovery of false positives. I imagine this may come up a lot with open source projects where companies typically do security audits themselves and may need help triaging reported issues.
Having used the CII criteria to review OPA and Falco, I don't see a strong argument AGAINST using CII as the MVP for assessment criteria. Can anyone articulate how the CII criteria fail to meet the goal?
It's actually pretty good, I never saw this list. it's more practical compared to ASVS, I'll be happy to see all CNCF project using these criteria. I filled an issue to add a threat model to the criteria (see coreinfrastructure/best-practices-badge#1302)
CII does discuss threat models for higher badges:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/other.md#documentation_security
On Wed, Jun 26, 2019 at 10:02 PM Omer Levi Hevroni notifications@github.com
wrote:
It's actually pretty good, I never saw this list. it's more practical
compared to ASVS, I'll be happy to see all CNCF project using these
criteria. I filled an issue to add a threat model to the criteria (see
coreinfrastructure/best-practices-badge#1302
https://github.com/coreinfrastructure/best-practices-badge/issues/1302)—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cncf/sig-security/issues/215?email_source=notifications&email_token=AAGENIXDVOOJEQHQMNADTKLP4RJXVA5CNFSM4H226H2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYWA6BQ#issuecomment-506203910,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGENIQDO4NZRL5XZLE23G3P4RJXVANCNFSM4H226H2A
.
Not recommending any particular methodology or format but this is an
informative example from OWASP:
https://www.owasp.org/images/a/aa/AppSecEU2012_PASTA.pdf
On Thu, Jun 27, 2019 at 3:34 AM Robert Ficcaglia rficcaglia@gmail.com
wrote:
CII does discuss threat models for higher badges:
On Wed, Jun 26, 2019 at 10:02 PM Omer Levi Hevroni <
[email protected]> wrote:It's actually pretty good, I never saw this list. it's more practical
compared to ASVS, I'll be happy to see all CNCF project using these
criteria. I filled an issue to add a threat model to the criteria (see
coreinfrastructure/best-practices-badge#1302
https://github.com/coreinfrastructure/best-practices-badge/issues/1302)—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cncf/sig-security/issues/215?email_source=notifications&email_token=AAGENIXDVOOJEQHQMNADTKLP4RJXVA5CNFSM4H226H2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYWA6BQ#issuecomment-506203910,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGENIQDO4NZRL5XZLE23G3P4RJXVANCNFSM4H226H2A
.
BSIMM has a decent section on testing - https://www.bsimm.com/framework/software-security-development-lifecycle/software-security-testing.html . Other sections include the third party libraries (open source) risk mgt. challenges, and answering many of the questions above.
@mhausenblas just wondering - can we close this particular issue if we add to the microsite in some sort of "resources" list or FAQ?
I like the idea of a FAQ and happy to add that. Unsure if that means we want to close this issue right now or when the site is up.
I'll be happy to work on this if someone is willing to mentor and guide me in the process.
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.