Security Architects are the trusted security advisors of GitLab Engineering. Security Architecture is a natural extension of the greater Architecture initiative at GitLab. It is the preliminary and necessary work to build software with security considerations.
Security Architecture protects the organization from cyber harm, and support present and future business needs by:
The process is designed with these constraints in mind:
Any change in our product offering (whether it is a feature, a service, or an acquisition), that would impact our security posture. Our security posture is defined by:
The Application Security team provides guidelines and requirements to follow during all the life cycle of source code:
The Security Architecture Principles are not requirements nor decisions, but something in between. These principles are taken from the book Software Systems Architecture (see references) and this ACCU 2019 related video. They are very close to the OWASP Security Design Principles, but fit better to our current workflow at GitLab.
Broad privileges allow malicious or accidental access to protected resources.
Limit the blast radius of successful attacks: When one part of the system is compromised, the whole system is not.
Make attacks less attractive.
As part of the Production Readiness Process, it is highly recommended to include a Security Architecture review.
The Security Architecture review process is detailed in this page.
Security Architecture, by nature, doesn't generate measurable data, apart from the number of architecture diagrams and reviews. While this could be used as a metric, it's only reflecting work load, and not achievements. Instead, we are measuring success in terms of maturity.
We are targeting the Maturity Level 1 for FY23-Q1, and our roadmap is discussed in this issue.