[Incubation] Kubescape incubation application #1291
Labels
Comments
This was referenced Apr 4, 2024
|
@craigbox as part of this task:
Can you please submit a "Presentation" Issue in https://github.com/cncf/tag-security so we can dive deeper into the project and give feedback ? |
|
@slashben will lead that: if you have a chance, please do refer back to the linked meetings for occasions where he has presented Kubescape in the past. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Kubescape incubation application
Project points of contact:
Incubation Criteria Summary for Kubescape
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
See ADOPTERS.
Owing to the nature of security software, only a small subset are willing to be listed.
Our download numbers suggest Kubescape is used by thousands of end users, either directly, or as customers of commercial security solutions such as ARMO Platform and Jit.
Application Process Principles
Required
Give a presentation and engage with the domain specific TAG(s) to increase awareness
Kubescape was presented to TAG Security in August 2022, with new features presented in December 2023 (video).
TAG provides insight/recommendation of the project in the context of the landscape
To be completed by TAG Security.
All project metadata and resources are vendor-neutral.
Kubescape launched in September 2021 as a tool for validating a cluster against the NSA hardening guidance that had been issued under a month before.
As Kubescape’s creators ARMO built out their hosted offering, the maintainers added features to Kubescape to support that product, including vulnerability scanning and analysis of access control rules. Much of that data was only available through ARMO’s commercial product, originally called Kubescape Cloud
The Kubescape project joined the CNCF Sandbox in 2022. At that time, Kubescape Cloud was renamed to “ARMO Platform” to ensure vendor neutrality.
Over the course of a year in the sandbox, the Kubescape maintainers have separated Kubescape from ARMO.
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
Met during sandbox onboarding.
Due Diligence Review.
To be completed by TOC sponsor.
Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
Governance and Maintainers
Required
Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
A number of active maintainers which is appropriate to the size and scope of the project.
The project has 9 maintainers, all of whom are active.
Code and Doc ownership in Github and elsewhere matches documented governance roles.
https://github.com/orgs/kubescape/teams/maintainers reflects the maintainer lists.
Document agreement that project will adopt CNCF Code of Conduct.
Adopted during Sandbox onboarding.
CNCF Code of Conduct is cross-linked from other governance documents.
CODE_OF_CONDUCT.md
All subprojects, if any, are listed.
n/a
Contributors and Community
Required
Clearly defined and discoverable process to submit issues or changes.
CONTRIBUTING.md
Project must have, and document, at least one public communications channel for users and/or contributors.
List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
Our primary method of communication is GitHub.
Real time communication is through #kubescape and #kubescape-dev on CNCF Slack
We also have mailing lists available to us through lists.cncf.io, but these are not currently active.
These are documented on our community page and GitHub project README.
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
We host a twice-monthly meeting, which is documented on our community page and announced in our Slack channels.
Documentation of how to contribute, with increasing detail as the project matures.
CONTRIBUTING.md.
Demonstrate contributor activity and recruitment.
73 committers have had PRs merged in the last 12 months and 224 contributors have interacted with the project on GitHub.
Engineering Principles
Required
Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.
Document what the project does, and why it does it - including viable cloud native use cases.
Kubescape is a security posture management tool, designed to identify and resolve security, misconfiguration, and compliance issues in a Kubernetes environment.
The project includes tools that can be run on a command line, or in a cluster, or integrated into many other popular tools allowing you to scan workload manifests while they are being developed or integrated, or after they are deployed.
Kubescape was the first tool to automate checking against the NSA hardening guidance and has since added support for other frameworks (including MITRE ATT&CK® and the CIS Benchmark).
It also includes comprehensive vulnerability scanning and reporting, allowing you to see the state of vulnerabilities detected in your containers.
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
ROADMAP.md
Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.
ARCHITECTURE.md
Document the project's release process.
Building
Security
Required
Clearly defined and discoverable process to report security issues.
Kubescape uses the GitHub security reporting process, with an SLO of 7 days for contact and 90 days for disclosure.
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
Membership of the Kubescape organisation requires 2 factor authentication.
Document assignment of security response roles and how reports are handled.
SECURITY.md
Given that Kubescape is security software, security response is a responsibility of all project maintainers.
Document Security Self-Assessment.
Underway.
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
Best practices badge.
Ecosystem
Required
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
ADOPTERS.md
Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)
These will be provided to our TOC sponsor.
TOC verification of adopters.
To be completed by the TOC
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
In order for cloud native computing to be ubiquitous, it must be secure. Kubescape exists solely to improve the security posture of workloads running on Kubernetes; it does not target workloads outside Kubernetes or Cloud Native.
The ultimate goal of the Kubescape project is to provide coverage of the full space of Kubernetes administrative security concerns.
Kubescape interacts with a number of CNCF projects:
The project also includes integrations for Argo, Backstage and Flux.
The text was updated successfully, but these errors were encountered: