Standardize Reviewers and Maintainers for Static Analysis projects
Problem to solve
Our devopssecure projects https://gitlab.com/gitlab-org/security-products/ do not currently align with company guidelines around code reviews, namely having designated Reviewers and Maintainers. We should consider aligning with our other codebases by training and formalizing maintainers for our tools.
Pros
- organization alignment, note projects such as Gitlab Runner and Auto Deploy Helm Chart
- improved consistency across tooling
- as a reviewer, I can focus on functionality (lower-level)
- as a maintainer, I can focus on inconsistencies and edgecases (higher-level)
- Able to maintain better specializations (language and tooling)
Cons
- potential loss of velocity (fewer maintainers)
- lower bus factor
Proposal
Propose maintainers and trainee maintainers for Secure product to better ensure consistency and help reviewers in narrowing review scope
Further details
- Limit scope of the maintainers program to only include projects which are considered to be part of the product or involved in the building of those products.
-
Introduce CODEOWNERS file in each eligible project as a means of declaring who are reviewers and who are maintainers for that project. - New starters don't become maintainers automatically.
-
Change week 2 onboarding issue to satisfy this change.
-
-
Change project settings so only maintainers can merge. -
Disallow all pushes to projects' default branch. - Members of Static Analysis can self-nominate to be a maintainer for their group's projects.
- Use trainee maintainer process when this happens.
- Change to danger bot for this change and better enable reviewer roulette?
- Maintainers in Static Analysis set criteria for becoming a maintainer.
- Maintainers in Static Analysis are empowered to declare when someone is ready to become a maintainer in their group.
Not in scope
- Reorganizing groups and projects under /security-products. There's a lot of stuff here thats a confusing mix of products, benchmarks, demos, etc. This could use some spring cleaning.
- Removing folks from the existing /security-products maintainer pool. Whether or not existing maintainers are grandfathered into being a maintainer is a decision left to each group's engineering manager and architectural council member.
Projects
Analyzers
-
https://gitlab.com/gitlab-org/security-products/analyzers/bandit -
https://gitlab.com/gitlab-org/security-products/analyzers/eslint -
https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder -
https://gitlab.com/gitlab-org/security-products/analyzers/gosec -
https://gitlab.com/gitlab-org/security-products/analyzers/kubesec -
https://gitlab.com/gitlab-org/security-products/analyzers/mobsf -
https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan -
https://gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit -
https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex -
https://gitlab.com/gitlab-org/security-products/analyzers/secrets -
https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan -
https://gitlab.com/gitlab-org/security-products/analyzers/semgrep -
https://gitlab.com/gitlab-org/security-products/analyzers/sobelow -
https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs
Common modules
Edited by Lucas Charles