A Transformation Mindset

Typically, application security adoption follows broad adoption of GitLab for SCM and CICD. But it's possible that some team members are still onramping with some aspects of GitLab Flow such as feature branches and shifting left, and might even be new to Git itself (i.e. from Perforce or svn) - that's OK.

Often, senior leadership and team members have a beginning understanding of GitLab's application security offerings (i.e. from the sales process) and want to learn more. That's a hook for getting started.

It's best if the company has CI/CD in place for other operations (unit testing and cloud deployments, for example) - but not entirely necessary.

For success, it's critical that we provide leadership across both aspects of the application security transformation.

Technical Aspects of Success

The actual GitLab features that support business goals and the integration/configuration of those features in the groups, subgroups, and projects. Plus enablement of hands-on teams in efficient utilixation of the product's capabilities.

Organizational

Aligning the way people plan, communication, collaborate, work, and think with business goals, organizational values, regulatory concerns, and each other.

Organizational transformation has 5 parts:

Strategy: Clear goals and objectives (OKRs, KPIs, MBOs, etc) combined with meaningful organizational values
Skill: Knowledge and abilities of individuals, backed by training, enablement, and support
Styles: A generative culture that fosters both autonomy and collaboration
Structure: Appropriate roles, job titles, reporting relationships, dotted lines, and incentives
Systems: Tools and technology that underlie successful processes (including but not limited to GitLab)

As a product/engineering-driven software company, we have a tendency to focus on the technical aspects of transformation and neglect the organizational ones - but those are the hard ones, and must be addressed to ensure success.

Technical Aspects of Transformation

GitLab features related to application security

Scanners
- All the types
- Results in artifacts
- Results in MRs
Security policies
- Policy projects
- Scan execution policies
- Scan results policies
Executive reporting
- Security dashboard
- Security center
- Vulnerability report
Vulnerability management
Compliance frameworks
Integration of 3rd party scanners

Organizational Aspects of Transformation

For developers

Agile best practices
Git best practices (if coming from pre-Git SCM)
MR best practices (if coming from other Git SCM)
Branching/MR strategy (first agreed at org level)
Integrating scanning with automated build/test
Feature/MR approval/merge process/workflow
Runner resource optimization (maybe some scans still only run post-merge or pre-release)

For devops teams

Maintenance of GitLab (is this SM?) and Runners
Release verification and deployment/distribution process
GitLab and scanner administration
Process for future enablement of dev and infosec teams re Git, GitLab, scanners, and workflows

For infosec team

Decisionmaking processes (which scanners, what stages)
Responsibility (DRIs) for scanner implementation, vuln management, MR review, release approval, etc
Process and staff allocations for handling results from first-time scanning passes

For everyone

Regular process for handling results and vulnerabilities, including escalations
Collaboration and communication process with other teams
Integration of vulnerability management with agile planning (i.e. issues to resolve vulns)

Getting started

Project phases might include: