Module 11 Lesson 4: Secure Bank Application
·DevOps

Module 11 Lesson 4: Secure Bank Application

Mission critical. Analyze the multi-layered security and compliance pipeline of a national bank, featuring air-gapped runners and mandatory manual approvals.

Module 11 Lesson 4: Case Study: Secure Bank

In this study, we look at "VaultGuard," a retail bank that must follow strict PCI-DSS and ISO 27001 regulations.

1. The Requirement

  • Privacy: No external cloud runners permitted.
  • Reviews: Every line of code must be approved by 2 different people.
  • Audit: Every deployment must be linked to a Jira ticket ID.

2. The Blueprint (.gitlab-ci.yml)

include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Secret-Detection.gitlab-ci.yml

# 1. Enforcing Reviews (Module 9)
# Done in GitLab Settings: Merge Request Approvals = 2

# 2. Jira Link Check (Custom CP - Module 1)
check-jira-link:
  stage: .pre
  script:
    - if [[ ! $CI_COMMIT_MESSAGE =~ "JIRA-[0-9]+" ]]; then exit 1; fi

# 3. Air-Gapped Runner (Module 9)
# The runner is tagged 'bank-hq' and has NO internet access. 
# It pulls images from a local cache only.

# 4. Mandatory Security Gate (Module 5)
sast:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      allow_failure: false # If a single bug is found, the build hard-fails.

Visualizing the Process

graph TD
    Start[Input] --> Process[Processing]
    Process --> Decision{Check}
    Decision -->|Success| End[Complete]
    Decision -->|Retry| Process

3. Analysis

  • Air-Gapped Runners: By hosting runners on-premise without an internet connection, the bank ensures that even if a library has a "Phone Home" virus, it cannot steal data.
  • Pre-emptive Checks: The check-jira-link job runs in the .pre stage, meaning it is the very first thing to happen. If you didn't document your work in Jira, the computer won't even waste power building your code.
  • Mandatory SAST: While most companies set allow_failure: true, a bank set it to false. They would rather the site stay on the old version than deploy a new, insecure version.

Exercise: The Compliance Officer

  1. Why is a "Confidential Issue" (Module 9) necessary for a bank?
  2. If a developer needs a new NPM library, how do they get it if the runner has "No Internet"? (Research: "Private Artifactory Proxy").
  3. How does the "Audit Events" tab help the bank during a government inspection?
  4. Search: What is "Four-Eyes Principle" and how does GitLab implement it in Merge Requests?

Summary

This case study demonstrates that DevOps and Security are not enemies. By using GitLab to automate the "Boring" parts of compliance (like checking ticket numbers and running scans), the bank allows its humans to focus on the "Hard" parts: high-level architecture and fraud prevention.

Next Lesson: Scale without limits: Case Study: Global Monorepo with 100+ Services.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn