Adoption Roadmap

  • Integrate this content into the structure of the delivery kit

Phase 1: Perform pilot with 1-4 dev teams/projects

Key staff: Pilot project development team

Key GitLab capabilities: CI/CD, Scanner templates, Pipeline security tab

Collaboration focus:

  • Implement individual scanners in the CICD configuration for individual projects
  • Run on both default branch and MR scans
  • Include static and dynamic scans where appropriate
  • Ensure operational integrity (do the scans run and generate data?)
  • Identify performance optimization opportunities

Phase 2: Initiate vulnerability management

Key staff: Information Security team

Key GitLab capabilities: Vulnerability Report

Collaboration focus:

  • Immediately upon the arrival of scan data, begin reviewing vulnerability report

Phase 3: Activate scanners universally

Key staff: Information Security team

Key GitLab capabilities: Scan Execution Policies, Pipeline Execution Policies, CI/CD components

Collaboration focus:

  • Generate security policy project(s)
  • Replace one-off scanner implementation in pilot project(s) with links to security policy project(s)
  • Implement Pipeline Execution Policies (or CI/CD components) for scan types unsupported by Scan Execution Policies
  • Draft plan for universal policy rollout

Why Scan Execution Policies?

  • They can be rolled out in pilot group
  • Security scans by default are allowed to fail, therefore should not affect pipeline scalability.
  • That being said, if pipeline duration for any monorepos are affected, due to slow SAST execution, this may need to be adressed.
  • Using latest version is possible via template variable, in order to activate scans for both Merge Request Pipelines and Branch Pipelines
  • For air-gapped environments you can use SECURE_ANALYZERS_PREFIX with Scan Execution Policy variable to activate scans.

Phase 3: Develop vulnerability management workflow

Key staff: Information Security team

Key GitLab capabilities: Vulnerability Report, Merge Request Approval Policies

At this stage, we have running pipelines and scan results. Based on the results now we can finally start identifying how a Merge Request Approval Policy and Vulnerability Management process should actually work. At this stage we develop the concept together with the teams involved related to

  • who can change state of a vulnerability.
  • who can approve an MR, when there is a certain level of vulnerability.
  • when are you allowed to deploy a change, even when there is a vulnerability.

Bear in mind, that current GitLab Vulnerability Management is based on GitLab Flow branching model. Identifying, if there are any gaps related to trunk based branch models is crucial in this stage, to consider potential workarounds or customisations to the Vulnerability MAnagement flow

Phase 4: Continuously reduce security risk

Once the piloting stage is complete, the tooling and concepts in place should achieve following.

A self-service rollout VM framework to other teams should be implemented. Teams have the option based on their workflow to trigger rollout themselves with minimal support requirements from Security or pilot teams. Some additional features to cover

  • Type of different compliance frameworks should be identified. Certain organisations like Finance, can require different compliancies. Whilist organisations like HR may be subject to data regulations. Also the separation of duties, may play a role here, in regards to how vulnerabilities are differently classified.

  • We can now consider establishing Pipeline Execution Policies to integrate with other 3rd party scanners or enforce other custom CI yamls in the organisation.

Technical and organizational changes

  • Access control for infosec team
  • Integration with Jira if required
  • Developer teams learn DevOps best practices such as trunk-based development, MR approvals, review apps
  • Infosec and dev teams develop combined communications/workflows for vulerability triage and management

Meeting Teams Where They Are

Security is a journey, not a destination (as with most transformation topics). While we want every team to be secure, trying to implement everything at once is like trying to run before you can walk - you'll likely stumble and create resistance to security initiatives.

Instead, meet teams where they are and help them level up gradually

Crawl:

  • Start with easy wins like dependency scanning
  • Focus on fixing critical vulnerabilities first
  • Build security awareness through documentation and training
  • Establish basic security hygiene in pipelines

Walk:

  • Add SAST scanning with focused rule sets
  • Implement security review processes
  • Start tracking security metrics
  • Expand vulnerability management practices

Run:

  • Full suite of security scanners
  • Advanced configuration and custom rules
  • Automated security gates in pipelines
  • Proactive security practices

The key is to make each step manageable while maintaining momentum. This builds confidence, shows value, and creates security champions within teams. For different customers the definition of crawl, walk, and run may vary, but the concepts apply regardless.