You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. What work did the SIG do this year that should be highlighted?
5
+
**1. What work did the SIG do this year that should be highlighted?**
6
6
7
-
-
8
-
-
9
-
-
7
+
- At the time of the 2020 Annual Reports, SIG Security was a very new SIG, just establishing who we are as a group and starting to build a space for security to flourish as a community effort. In 2021, we have come into our own. Since the last annual report, SIG Security has doubled in size, established and matured subprojects that have become welcoming communities of their own, and grown new leaders who have come to lift up more new contributors themselves. We now have generations of contributors working, learning, and honking together.
10
8
11
-
2. What initiatives are you working on that aren't being tracked in KEPs?
9
+
Our [Docs subproject](https://kubernetes.slack.com/archives/C01D8R7ACQ2) has made Kubernetes security more approachable through blogs and tutorials such as [A Closer Look at NSA/CISA Kubernetes Hardening Guidance](https://kubernetes.io/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/), [Securing Admission Controllers](https://kubernetes.io/blog/2022/01/19/secure-your-admission-controllers-and-webhooks/), [Apply Pod Security Standards at the Cluster Level](https://kubernetes.io/docs/tutorials/security/cluster-level-pss/), and [Apply Pod Security Standards at the Namespace Level](https://kubernetes.io/docs/tutorials/security/ns-level-pss/).
12
10
13
-
-
14
-
-
15
-
-
11
+
Our [Tooling subproject](https://kubernetes.slack.com/archives/C01CUSVMHPY) got off the ground in 2021 and is now flying high, [standardizing Kubernetes CVE reporting](https://github.com/kubernetes/sig-security/issues/1), [prototyping vulnerability scanning of Kubernetes artifacts](https://github.com/kubernetes/sig-security/issues/3), and [hosting](https://www.youtube.com/watch?v=zB1-7NLsfps)[learning](https://www.youtube.com/watch?v=o-E6aoKmznY)[sessions](https://www.youtube.com/watch?v=MWAb63gf3gs) which have been viewed hundreds of times.
16
12
17
-
3. KEP work in 2021 (1.x, 1.y, 1.z):
13
+
SIG Security does things differently than a lot of other SIGs. We don’t own code. We work hard to cultivate and grow an inclusive, welcoming environment where everyone, from the newest contributor to the most experienced hacker, can come share their ideas and contribute to the security of the project. This is designed to ripple outward whether or not we are involved, encouraging and facilitating internal collaboration across SIGs and engagement with the external security community. We’re really proud of how far we’ve come, and we’re excited to continue leading by example into 2022 and beyond!
18
14
19
-
<!--
20
-
In future, this will be generated from kubernetes/enhancements kep.yaml files
21
-
1. with SIG as owning-sig or in participating-sigs
22
-
2. listing 1.x, 1.y, or 1.z in milestones or in latest-milestone
23
-
-->
15
+
**2. What initiatives are you working on that aren't being tracked in KEPs?**
16
+
17
+
- Most of our work is outside the scope of KEPs. Improving processes, providing ongoing services, and actively building collaboration within the Kubernetes project are all core to what we do. We operate on the basis of consent, communication, and participation–what gets done is based on who shows up, what ideas they bring, and how the rest of the community responds.
18
+
19
+
[Security Self-assessments](https://github.com/kubernetes/sig-security/issues/2) are a great example of how this works in practice. ClusterAPI maintainers were looking for guidance on evaluating and improving the security of ClusterAPI, and SIG Security members were enthusiastic about helping them. We collaborated with CNCF TAG Security to begin a guided self-assessment exercise for ClusterAPI, adapting TAG Security’s existing self-assessment workflow into a Kubernetes context. Through this process, the participants have gained confidence and experience, word has gotten around, and other Kubernetes subprojects have started asking about their own guided self-assessments. At the time of this writing, Security Self-Assessment is emerging as a likely new SIG Security subproject.
20
+
21
+
Our [Tooling subproject](https://kubernetes.slack.com/archives/C01CUSVMHPY) is working to prototype, define policy for, and implement [vulnerability scanning for build time dependencies and container images](https://github.com/kubernetes/sig-security/issues/3). This initiative involves collaborating with several other SIGs, applying SIG Security’s specialized experience with these tools to produce meaningful improvements without burying other SIGs in additional work.
22
+
23
+
Our [Third-Party Audit subproject](https://github.com/kubernetes/sig-security/tree/main/sig-security-external-audit) continues to administer their namesake initiative. In 2021 they published a [Request for Proposals](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021/RFP.md), evaluated the vendor responses, and began to negotiate contract terms with the selected vendor. As of this writing, they have [announced the vendor selection](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021/RFP_Decision.md) and are making arrangements for work to begin.
24
+
25
+
Our [Security Docs subproject](https://kubernetes.slack.com/archives/C01D8R7ACQ2) works in collaboration with SIG Docs and others on its continuing initiatives: to improve security representation and content in Kubernetes documentation, to communicate information to help end users and others keep themselves safer, and to help foster and grow new contributors. They have been prolifically publishing useful information such as the blog posts shouted out in the beginning of this report, and highlighting good first issues for new contributors to start diving in.
1. What areas and/or subprojects does your group need the most help with?
40
-
Any areas with 2 or fewer OWNERs? (link to more details)
41
+
**1. What areas and/or subprojects does your group need the most help with?**
42
+
43
+
- Our [Docs subproject](https://kubernetes.slack.com/archives/C01D8R7ACQ2) is always looking for security-minded contributors of all experience levels to share their learning and knowledge with the community! This subproject has consistently been a place where people [merge](https://github.com/kubernetes/website/pull/28248) their [first](https://github.com/kubernetes/website/pull/31518) Kubernetes PRs.There’s always room for continuous improvement in our documentation, and contributing to this provides an opportunity to learn more about Kubernetes security while helping everyone run their clusters more safely. We’re really proud of the way Docs encourages and welcomes new contributors, and we’d love to encourage you to become a part of it!
44
+
45
+
**Any areas with 2 or fewer OWNERs? (link to more details)**
41
46
42
-
-
43
-
-
44
-
-
47
+
- The nature of our work means we have little need for OWNERS files, compared to SIGs that ship code. We have two or more OWNERS in all areas, and our community focus helps ensure that when someone needs to scale back their involvement they will be well supported.
45
48
46
-
2. What metrics/community health stats does your group care about and/or measure?
49
+
**2. What metrics/community health stats does your group care about and/or measure?**
47
50
48
-
-
49
-
-
50
-
-
51
+
- We care about our people. We measure community health by looking at community participation, and seeing how people are feeling. Are people coming to meetings and talking to one another on Slack? How many people are engaged? Is anyone dominating the conversation? Are new contributors becoming involved? Are people coming back?
51
52
52
-
3. Does your [CONTRIBUTING.md] help **new** contributors engage with your group specifically by pointing
53
-
to activities or programs that provide useful context or allow easy participation?
54
53
55
-
-
54
+
These types of concerns are notably hard to metricize, which we remain comfortable with.
56
55
57
-
4. If your group has special training, requirements for reviewers/approvers, or processes beyond the general [contributor guide],
58
-
does your [CONTRIBUTING.md] document those to help **existing** contributors grow throughout the [contributor ladder]?
56
+
**3. Does your [CONTRIBUTING.md] help _new_ contributors engage with your group specifically by pointing to activities or programs that provide useful context or allow easy participation?**
59
57
60
-
-
61
58
62
-
5. Does the group have contributors from multiple companies/affiliations?
59
+
- We have known for some time that SIG Security needs a CONTRIBUTING.MD document that more accurately reflects how we do things. SIG Security takes a community-building approach to improving Kubernetes security: we intentionally make a space where someone can begin contributing by sharing their thoughts and ideas in a meeting or Slack message. The CONTRIBUTING.MD document we have in progress reflects this. It encourages participation by showing up and links to the general Kubernetes contributor guides, which are still applicable.
63
60
64
-
-
61
+
**4. If your group has special training, requirements for reviewers/approvers, or processes beyond the general [contributor guide], does your [CONTRIBUTING.md] document those to help _existing_ contributors grow throughout the [contributor ladder]?**
65
62
66
-
6. Are there ways end users/companies can contribute that they currently are not?
67
-
If one of those ways is more full time support, what would they work on and why?
63
+
- SIG Security does not have special training or requirements for reviewers/approvers. The nature of our cross-SIG work means that we have many fewer PRs, OWNERS files, and similar artifacts than many SIGs. The Kubernetes Contributor Ladder document as currently written focuses on scaling review of numerous code PRs. This limits its immediate applicability to our horizontal SIG, which does not own code and is intentionally built upon open, non-hierarchical community participation. We continue to learn through experience how best to utilize and evolve the contributor ladder to encourage and recognize our leading contributors.
68
64
69
-
-
70
-
-
65
+
**5. Does the group have contributors from multiple companies/affiliations?**
66
+
67
+
- Yes.
68
+
69
+
**6. Are there ways end users/companies can contribute that they currently are not? If one of those ways is more full time support, what would they work on and why?**
70
+
71
+
- End users and people who work at end user companies are contributing broadly within SIG Security today. There are so many possibilities of ways to contribute. As a community we continue to experiment and discover new ways, together. Bring your gifts; come share and learn with us!
71
72
72
73
## Membership
73
74
74
-
- Primary slack channel member count:
75
-
- Primary mailing list member count:
76
-
- Primary meeting attendee count (estimated, if needed):
77
-
- Primary meeting participant count (estimated, if needed):
78
-
- Unique reviewers for SIG-owned packages: <!-- in future, this will be generated from OWNERS files referenced from subprojects, expanded with OWNERS_ALIASES files -->
79
-
- Unique approvers for SIG-owned packages: <!-- in future, this will be generated from OWNERS files referenced from subprojects, expanded with OWNERS_ALIASES files -->
75
+
- Primary slack channel member count: 890
76
+
- Subproject slack channel member counts:
77
+
- #sig-security-docs: 260
78
+
- #sig-security-tooling: 357
79
+
- Primary mailing list member count: 246
80
+
- Primary meeting attendee count (estimated, if needed): 13.8
81
+
- Primary meeting participant count (estimated, if needed): 13.8
80
82
81
-
Include any other ways you measure group membership
83
+
Due to the way we conduct our meetings, at the majority of meetings, everyone participates.
82
84
83
-
## Subprojects
85
+
- Unique reviewers for SIG-owned packages: N/A
86
+
- Unique approvers for SIG-owned packages: N/A
84
87
85
-
<!--
86
-
In future, this will be generated from delta of sigs.yaml from $YYYY-01-01 to $YYYY-12-31
87
-
Manually visible via `git diff HEAD@{$YYYY-01-01} HEAD@{$YYYY-12-31} -- $sig-id/README.md`
0 commit comments