Case Study 1: Meridian Assesses Its Core-Banking Vendor and Rolls Out SBOMs

"We can't replace this vendor by Friday, or by next year. So we'd better be able to prove they're doing what they promised — and we'd better know what's inside the software we run for them." — Elena Vasquez, GRC Analyst, Meridian Regional Bank (constructed)

Executive Summary

Meridian Regional Bank's single largest technology dependency is its core-banking platform — the system of record for every account balance and transaction, delivered and supported by an external vendor (call it CorePoint Systems, constructed). It is the textbook Tier 1 vendor: most-regulated data, most-business-critical, and a concentration risk with no quick substitute. This case study follows GRC analyst Elena Vasquez and security engineer Sam Whitfield as they (1) run a full Tier 1 vendor security assessment, (2) translate the gaps into enforceable contract clauses, and (3) stand up Meridian's first SBOM requirement and consuming pipeline, so the next Log4Shell is a query instead of a fire drill. The work is governance-heavy and build-heavy at once — exactly the GRC/engineer pairing this chapter targets. All names, figures, and findings are constructed for teaching (Tier 3).

Skills applied: vendor tiering; concentration-risk analysis; vendor security assessment (questionnaire + SOC 2 evidence review); weighted scoring with a critical-control override; drafting contractual security requirements; SBOM generation/ingestion and continuous vulnerability matching; board-level risk framing; mapping to GLBA/FFIEC obligations.

Background

Meridian's CISO, Dana Okafor, has spent the last several chapters maturing the bank's program: governance (Chapter 26), an enterprise risk assessment and appetite statement (Chapter 27), and a compliance mapping across PCI-DSS, GLBA, and the rest (Chapter 28). An FFIEC examination is on the calendar, and the examiners have signaled they will look hard at third-party risk — specifically at how Meridian oversees its critical service providers. Dana's enterprise risk register already carries a row that has made her uneasy for years: "Core-banking vendor outage or compromise — likelihood 2 × impact 5 = 10, HIGH", with a treatment column that, until now, read "monitor."

"Monitor" is not a defensible answer to an examiner, and it is not a defensible answer to herself. The problem is real: CorePoint is irreplaceable on any short horizon. Migrating a bank's core is a multi-year, high-risk program; there is no "switch vendors this quarter" option. So Meridian cannot treat this concentration risk by avoidance. What it can do is treat it the way this chapter prescribes — assess CorePoint to Meridian's standard, make the standard contractually binding and verifiable, monitor continuously, and — new this quarter — gain visibility into what is inside the software CorePoint delivers, so an industry-wide vulnerability stops being a two-week scramble.

Dana hands the assessment to Elena and the SBOM pipeline to Sam, with one instruction echoing the Chapter 1 ethos: "Be honest about the gaps. An assessment that finds nothing wrong with our most critical vendor isn't reassuring — it's incompetent."

The Engagement

Phase 1 — Tiering and the concentration question

Elena starts by confirming the obvious and then refusing to stop there. CorePoint is Tier 1 by every criterion simultaneously:

The last row is the one that changes the shape of the assessment. A normal Tier 1 assessment asks "is the vendor secure?" Elena's must also ask the concentration question: "What happens if CorePoint fails or is compromised, and can Meridian survive it?" That second question pulls in resilience and exit analysis that a pure security questionnaire would miss.

Concentration-risk worksheet — CorePoint (core-banking)
  Single point of failure?      YES — system of record, no hot alternative
  Realistic exit timeline?      ~2-3 years (core migration program)
  Treatment chosen:             ACCEPT the concentration (no viable alternative)
                                + MITIGATE with resilience + verification + monitoring
  Mitigations:
    - Contractual uptime/RTO/RPO commitments + DR test participation rights
    - Verified vendor business-continuity posture (review their BC/DR evidence)
    - Tested "vendor outage" communication & manual-process plan (ties to Ch.24 IR)
    - Annual reassessment + continuous monitoring (security ratings, breach news)
  Residual risk (documented):   A determined compromise of CorePoint, or a prolonged
                                outage exceeding contractual RTO, remains a top-3
                                enterprise risk. Accepted by the board with eyes open.

🛡️ Defender's Lens: Notice what "accept" means here, done properly. It is not "ignore." Elena records the acceptance explicitly in the enterprise risk register (Chapter 27), names the residual risk in plain language, and attaches mitigations and an exit estimate. When the FFIEC examiner asks "how do you manage the concentration in your core provider?", Dana has a one-page answer instead of a shrug. An accepted risk that is documented, mitigated, and revisited is a managed risk; an unexamined dependence is a landmine.

Phase 2 — The vendor security assessment

Elena runs the full Tier 1 assessment. CorePoint, being a mature financial-software vendor, cooperates — which itself is a good sign, but Elena corroborates everything rather than taking cooperation as proof.

The questionnaire. She sends a comprehensive security questionnaire (a SIG-style instrument adapted for software vendors) covering governance, access control, encryption, vulnerability/patch management, secure development, incident response, business continuity, data handling, and sub-processors. She scores the answers with the weighted method from §29.4, marking the critical controls.

The weighted math (Elena does it explicitly so it's auditable): weights sum to $3+3+2+3+2+2+2+3+3+2+1 = 26$, so the maximum is $26 \times 4 = 104$. The earned total is $(3{\cdot}4)+(3{\cdot}4)+(2{\cdot}3)+(3{\cdot}3)+(2{\cdot}3)+(2{\cdot}1)+(2{\cdot}2)+(3{\cdot}4)+(3{\cdot}3)+(2{\cdot}3)+(1{\cdot}2)$ $= 12+12+6+9+6+2+4+12+9+6+2 = 80$. So the weighted result is $80/104 \approx 0.77$, or 77%.

The critical-control check. This is the discipline that matters. No critical control scored below 2 — the lowest critical is build-pipeline integrity/provenance at exactly 2 — so the override does not force a HIGH-RISK tier. But two findings demand attention regardless of the 77% average: the SBOM gap (score 1) and the partial provenance (score 2 on a critical control). The verdict is therefore not "77% — pass" but:

• Overall: 77% weighted — Conditional approval / continue with conditions (CorePoint is an existing vendor; this is a re-assessment, so the practical output is a remediation plan and contract amendments).
• Required commitments: provide a current SBOM (CycloneDX or SPDX) per release; firm up the KEV-triggered emergency-patch path; commit to a provenance/build-integrity roadmap with milestones; breach notification within 72 hours in the contract; data-destruction certificate within 30 days on termination.
• Residual risk: moderate and documented; the provenance gap (the SolarWinds-class exposure) is the most important open item and is tracked to a milestone, not closed.

⚠️ Common Pitfall (avoided): Elena's first draft of the verdict was "77%, approve." Dana pushed back exactly as Elena had pushed back on Theo in Chapter 1: "77% of what? Tell me the two things that aren't fine, and what we're doing about them." The percentage is a summary, not a decision. The decision is the list of conditions — and the honest naming of the provenance gap as a residual risk Meridian is living with while CorePoint matures, rather than pretending the average makes it disappear.

Phase 3 — Contractual security requirements

Findings that aren't in the contract are wishes. Elena works with Meridian's legal team to turn the assessment into binding clauses at the next contract amendment. The Tier 1 clause set (abbreviated):

CorePoint contract — security schedule (excerpt)
  §4.1 Minimum controls — controls consistent with the vendor's SOC 2 Type II /
       ISO 27001 scope; MFA on all privileged and support access; encryption of
       Meridian data at rest (AES-256) and in transit (TLS 1.2+).
  §4.2 Right to audit — Meridian may, annually and after any material security event,
       review evidence, receive the SOC 2 report, and commission an independent audit.
  §4.3 Breach notification — vendor notifies Meridian within 72 hours of any security
       incident affecting Meridian data or the core-banking service, with scope detail.
  §4.4 Vulnerability management — criticals patched within 15 days; an EMERGENCY path
       for vulnerabilities on the CISA KEV catalog or actively exploited in the wild.
  §4.5 SBOM — vendor delivers a current SBOM (CycloneDX 1.5+ or SPDX) for each release
       of software deployed in Meridian's environment.                         [NEW]
  §4.6 Build integrity / provenance — vendor maintains signed releases and a documented
       roadmap toward verifiable build provenance (SLSA-aligned).              [NEW]
  §4.7 Sub-processors — vendor discloses sub-processors, flows these requirements down,
       and notifies Meridian of material changes.
  §4.8 Liability & insurance — indemnification for vendor-caused breaches; vendor
       maintains cyber-insurance at a stated minimum.
  §4.9 Data return/destruction — on termination, data returned and/or destroyed within
       30 days, with a written certificate of destruction.
  §4.10 Right to terminate — for uncured material breach of this security schedule.

🔗 Connection: Read §4 as the four risk-treatment options from Chapter 27 written in legalese. §4.1, §4.2, §4.4 are mitigation (reduce likelihood/impact). §4.8 is transfer (shift the cost). §4.10 is the avoidance exit. And the documented concentration acceptance from Phase 1 is conscious acceptance. The Chapter 28 lesson lands too: these clauses deliberately exceed regulatory minimums — a 72-hour notification and a KEV-triggered emergency patch path are tighter than "comply with applicable law" because Meridian's exposure doesn't wait for the legal floor. Compliance is the floor; this is above it.

Phase 4 — The SBOM rollout (Sam's build-side work)

While Elena handles paper, Sam builds the machinery that gives the new §4.5 clause teeth. An SBOM clause is worthless if the SBOMs land in an inbox and die there; the value is in continuously matching them against vulnerability feeds. Sam designs the consuming pipeline:

Meridian SBOM ingestion & matching pipeline (Sam's design)

  [Vendor SBOMs]            [Internal app SBOMs]
  (CorePoint, others)       (generated by SCA in CI — ties to Ch.12/31)
         │                          │
         └────────────┬─────────────┘
                      ▼
            ┌───────────────────┐
            │  Central SBOM      │   one store, every app + product,
            │  repository        │   keyed by component + version (purl)
            └─────────┬─────────┘
                      │  nightly + on new advisory
                      ▼
            ┌───────────────────┐     feeds:
            │  Vulnerability     │◄──── NVD / NIST CVE database
            │  matching engine   │◄──── CISA KEV (actively exploited)
            └─────────┬─────────┘◄──── OSV.dev (open-source vulns)
                      │  match on purl + version range
                      ▼
            ┌───────────────────┐
            │  Alert + ticket    │──► Marcus's SOC queue, prioritized by
            │  (risk-ranked)     │    KEV/EPSS (Ch.23), not raw CVSS
            └───────────────────┘

Figure CS1.1 — The SBOM only earns its keep when matched. SBOMs from vendors and from Meridian's own CI flow into one store; a matching engine compares every component+version against NVD, CISA KEV, and OSV; matches become risk-ranked tickets. When the next Log4Shell drops, this pipeline answers "where are we exposed?" in minutes.

Sam tests the pipeline against the past. He loads the CorePoint SBOM and the SBOMs from Meridian's own applications, then asks the question of December 2021: which of these contain a vulnerable Log4j? The script (this chapter's code/example-02) walks every SBOM's dependency graph, finds log4j-core entries, and flags any below 2.17.0. On Meridian's own loan-origination-web, it finds the buried, transitive log4j-core 2.14.1 from §29.3 — exactly the kind of instance that took other organizations days to locate by hand. CorePoint's current release comes back clean (patched), but the exercise proves the point: with the pipeline, the hunt is a query.

🛡️ Defender's Lens: The SolarWinds lesson is also wired in here, but it lives in a different place. Sam's matching pipeline answers the Log4Shell question (known vulnerable component, where?). It does not answer the SolarWinds question (was a legitimate-looking artifact tampered with at build?), because an SBOM lists components, not build integrity. That gap is precisely why §4.6 (provenance roadmap) exists, and why Meridian also isolates and monitors CorePoint's privileged support access (the Sunburst foothold pattern). SBOM and provenance are the two halves; Meridian is now building both, with the provenance half tracked as the top residual risk. Chapter 31 takes the provenance work into the pipeline in depth.

Phase 5 — The board framing

Dana distills the whole engagement for the Audit Committee into a narrative the board can act on, because a board does not buy controls — it buys managed risk:

"Our largest single technology risk is a vendor we cannot quickly replace. We are not pretending we can eliminate that. What changed this quarter is that we now manage it deliberately: we assessed CorePoint against our own standard and found it strong with two named gaps; our contract now obligates them to that standard and lets us verify it; we monitor them continuously; and — for the first time — we have an inventory of what's inside the software we run, so the next industry-wide vulnerability is a one-hour query instead of a two-week fire drill. The one risk I'm explicitly asking you to accept with me is that CorePoint's build-integrity assurance is still maturing; we have it on a tracked roadmap and we'll report progress."

That is the chapter in a paragraph: third-party risk is unavoidable, but it is manageable, and Meridian now manages its most important vendor relationship with assessment, contract, monitoring, and visibility — honestly, including the part that isn't finished.

Discussion Questions

1. Elena treated CorePoint's cooperation as a good sign but not as proof, corroborating every critical claim. Where is the line between healthy verification and an adversarial relationship that damages a genuinely good vendor partnership? How do you stay rigorous without being insulting?
2. The concentration risk was accepted. Under what circumstances should a bank instead invest in reducing it (e.g., funding a multi-year core migration to a more resilient or multi-vendor arrangement)? What would tip the cost-benefit?
3. CorePoint scored 77% overall, with the provenance gap as the key residual risk. Was conditional continuation the right call, or should Meridian have demanded provenance assurance as a hard precondition? Argue both sides, considering that there's no alternative vendor.
4. Sam's SBOM pipeline answers the Log4Shell question but not the SolarWinds question. If you had budget for only one of the two next year — extending SBOM coverage to more products, or implementing provenance verification for the core-banking software — which would you fund, and why?
5. The board "accepts" the provenance residual risk. What ongoing reporting would you give them so that "accepted" doesn't quietly become "forgotten"?

Your Turn

Take a critical software vendor for an organization you know (or invent one) and run an abbreviated version of this engagement. (1) Tier it and decide whether it's also a concentration risk; if so, complete a short concentration worksheet (single point of failure? exit timeline? treatment?). (2) Build an eight-to-ten-question security questionnaire, score it with weights and a critical-control override, and produce a structured verdict (rating + flagged gaps + required commitments + residual risk) — not just a percentage. (3) Draft five contract clauses addressing your top gaps, including an SBOM clause if the vendor delivers software. (4) Sketch (in words or a diagram) how you'd consume and continuously match SBOMs. Keep it to two pages. If you can't justify a score in a phrase, note what evidence you'd go get.

Key Takeaways

• A critical, irreplaceable vendor is Tier 1 and a concentration risk; the assessment must ask both "is it secure?" and "can we survive its failure?" — the second pulls in resilience and exit analysis.
• Concentration risk is treated by accepting it explicitly (when there's no alternative) plus mitigating with resilience clauses, monitoring, and a tested outage plan — never by ignoring it. A documented, mitigated, revisited acceptance is a managed risk.
• Score to a structured verdict, not a percentage. A 77% with two flagged gaps becomes "conditional approval + required commitments + named residual risk," and the critical-control override guards against a tidy average hiding a deal-breaker.
• Contractual clauses are the four risk treatments in legalese — and they deliberately exceed regulatory minimums (72-hour notification, KEV-triggered emergency patching). Compliance is the floor.
• An SBOM clause is worthless without a consuming pipeline. Value comes from storing every SBOM centrally and continuously matching components+versions against NVD, CISA KEV, and OSV — turning the next Log4Shell into a query.
• SBOM answers the Log4Shell question; provenance/SLSA answers the SolarWinds question. Meridian builds both, tracking the provenance gap as its top residual supply chain risk (and carrying it into Chapter 31).
• The board buys managed risk, not controls. The winning frame: "we can't replace this vendor, but we now assess, contract, monitor, and see inside it — honestly, including what isn't finished."