How to conduct a software supply chain risk assessment fo...

Insurance carriers underwriting cyber and tech E&O policies increasingly ask a hard question before binding a policy: how much software supply chain risk sits inside the applicant's vendor stack? A rigorous software supply chain risk assessment for insurance carriers pulls together dependency graphs, SBOMs, build provenance, and vendor questionnaires into a single, defensible risk score — the same kind of evidence underwriters need to price a policy and claims teams need after a breach. This guide walks through a repeatable, sequential process you can run in-house or hand to a third-party assessor: from scoping the vendor population, through SBOM collection and verification, to scoring vendors against an insurtech risk assessment framework and wiring continuous monitoring into renewal cycles. By the end you'll have a working insurance carrier vendor audit checklist and the commands to execute it.

Step 1: Scope Your Software Supply Chain Risk Assessment for Insurance Carriers

Before touching a single scanner, define what "vendor" means for your book of business. Carriers typically need three overlapping populations: policyholders applying for cyber coverage, third-party MGAs and claims platforms the carrier itself depends on, and critical software subprocessors (payment rails, policy admin systems, telematics feeds) that touch sensitive data. Each population carries a different assessment depth.

Start by tiering vendors on two axes: data sensitivity (PII/PHI, claims data, payment data) and system criticality (can the carrier issue policies or pay claims without it?). A simple tiering table:

Tier 1 (Critical):  Policy admin, claims processing, payment processing
Tier 2 (High):      Underwriting tools, telematics, document management
Tier 3 (Standard):  Marketing tools, internal productivity software

Tier 1 vendors get full SBOM collection, build provenance checks, and quarterly reassessment. Tier 3 vendors get an annual questionnaire. This tiering decision drives every later step, so document it in your risk assessment charter and get underwriting and compliance sign-off before you start collecting evidence.

Step 2: Build the Insurance Carrier Vendor Audit Checklist

With tiers defined, translate them into a concrete insurance carrier vendor audit checklist that both your team and the vendor's security contact can execute against. At minimum, the checklist should require:

• A current SBOM (SPDX or CycloneDX) generated within the last release cycle, not a static document from onboarding
• Evidence of dependency vulnerability scanning with defined SLAs for critical/high findings (e.g., critical CVEs remediated within 15 days)
• Build provenance attestations (SLSA level or equivalent) showing artifacts were built from reviewed source, not a developer laptop
• Signed container images or binaries, verifiable independent of the vendor's own attestation
• A named incident response contact and breach notification SLA tied into the master services agreement
• Evidence of secrets management and CI/CD hardening (no long-lived credentials in pipelines)
• Fourth-party disclosure — a list of the vendor's own critical subprocessors

Turn this into a scored questionnaire (yes/no/partial, weighted by tier) rather than a free-text form. Free-text answers don't scale across hundreds of policyholders and can't be diffed release over release, which is the whole point of doing this continuously rather than once at renewal.

Step 3: Collect and Verify SBOMs, Don't Just File Them

An SBOM you can't verify is a PDF, not evidence. For vendors who can grant read access to a repository or registry, generate or regenerate the SBOM yourself rather than trusting a submitted file:

# Generate an SBOM directly from a vendor's published container image
syft registry:vendor-app:1.4.2 -o cyclonedx-json > vendor-app-sbom.json

# Scan it for known vulnerabilities against the latest advisory database
grype sbom:vendor-app-sbom.json --fail-on high

For vendors distributing signed artifacts, verify the signature and provenance rather than accepting a screenshot of a green checkmark:

cosign verify \
  --certificate-identity-regexp "https://github.com/vendor-org/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  vendor-registry.io/vendor-app@sha256:8f2c...

If the vendor can't produce a machine-readable SBOM or a verifiable signature, that's a finding in itself — record it as a control gap rather than skipping the step, because "no visibility" is exactly the risk an insurance policy is meant to price.

Step 4: Score Vendors with an Insurtech Risk Assessment Framework

Raw scan output doesn't help an underwriter compare Vendor A to Vendor B. You need a scoring framework that normalizes technical findings into a business risk rating. A workable insurtech risk assessment framework combines four weighted factors:

risk_score:
  weights:
    vulnerability_exposure: 0.35   # unpatched criticals/highs, age of oldest critical
    provenance_integrity: 0.25     # signed builds, SLSA level, reproducibility
    data_sensitivity: 0.25         # tier from Step 1
    incident_history: 0.15         # prior breaches, disclosed CVEs in their stack
  thresholds:
    low: "< 30"
    medium: "30-60"
    high: "> 60"

Map the resulting band directly to underwriting actions: low-risk vendors proceed at standard terms, medium-risk vendors trigger a remediation plan with a follow-up reassessment date, and high-risk vendors require either compensating controls (network segmentation, additional monitoring) or a sublimit/exclusion on the policy. Keep the weighting formula version-controlled — when underwriting or claims later asks "why did this vendor score a 42," you need to reproduce the calculation exactly as it was applied at binding.

Step 5: Automate Continuous Carrier Software Due Diligence

A point-in-time assessment goes stale the moment a vendor ships a new release with a fresh dependency tree. Effective carrier software due diligence has to run on a schedule, not just at renewal. Wire the SBOM generation and scoring steps from Steps 3 and 4 into a recurring job:

# .github/workflows/vendor-risk-rescan.yml
on:
  schedule:
    - cron: "0 6 * * 1"   # weekly, every Monday
jobs:
  rescan-tier1-vendors:
    runs-on: ubuntu-latest
    steps:
      - name: Regenerate SBOMs and rescore
        run: |
          for vendor in $(cat tier1-vendors.txt); do
            syft registry:$vendor -o cyclonedx-json > "sboms/$vendor.json"
            grype sbom:"sboms/$vendor.json" -o json > "scans/$vendor.json"
          done
      - name: Alert on score drift
        run: python3 score_and_diff.py --threshold-delta 10

Alert on score drift, not just absolute thresholds — a vendor jumping from 22 to 41 in a week is often more actionable than one sitting steadily at 55. Feed the delta into whatever ticketing or GRC system your compliance team already uses so reassessments show up as tracked work, not a spreadsheet nobody revisits until the next renewal cycle.

Step 6: Document Findings and Route Them to Underwriting and Claims

Close the loop by producing a report that both a security engineer and an underwriter can read. For each vendor, capture: the tier, the current risk score and its four component sub-scores, open findings with remediation deadlines, and a plain-language summary of residual risk. Store this alongside the policy file so that if a claim is later filed, the claims team can pull the assessment history and see exactly what was known — and when — about the vendor implicated in the incident. This history is often the difference between a clean claims process and a coverage dispute over what the carrier reasonably should have known at binding.

Troubleshooting and Verification

• SBOM generation fails or returns an empty component list: confirm the image or artifact isn't multi-arch-ambiguous — pin a specific digest (vendor-app@sha256:...) rather than a tag, and re-run syft against that digest.
• cosign verify fails with "no matching signatures": the vendor may be signing with a different OIDC issuer or a self-managed key rather than keyless signing. Ask for their public key and rerun with cosign verify --key vendor-cosign.pub instead of the identity-based flags.
• Grype reports differ between runs for the same SBOM: the vulnerability database is time-sensitive; run grype db update immediately before scanning and pin the database version in your CI logs so results are reproducible for audit purposes.
• Vendor risk scores swing wildly week to week: check whether the vulnerability_exposure weight is reacting to newly disclosed CVEs in transitive dependencies the vendor doesn't control directly — consider a shorter lookback window or a decay function so a single new disclosure doesn't dominate the score.
• Underwriters can't reproduce a score from six months ago: verify your scoring config is version-controlled and every historical report references the exact commit or tag of risk_score weights used at the time, not just the current live config.

Run a quarterly tabletop exercise where compliance, underwriting, and security jointly reproduce one vendor's score end to end. If any team can't get from raw scan output to the final band without asking someone else to "just check," the process isn't audit-ready yet.

How Safeguard Helps

Safeguard was built for exactly this workflow. Instead of stitching together syft, grype, cosign, and a spreadsheet across hundreds of policyholders and subprocessors, Safeguard continuously discovers vendor software artifacts, generates and diffs SBOMs release over release, verifies build provenance and signatures automatically, and rolls the results into a configurable risk score aligned to your insurtech risk assessment framework. Findings route directly to ticketing and GRC systems, drift alerts fire the moment a Tier 1 vendor's score moves, and every score is versioned so underwriting and claims teams can reproduce exactly what was known at binding. For carriers running vendor audits across a large policyholder book, that turns a quarterly fire drill into a standing, defensible control — the kind of evidence that holds up whether you're pricing a renewal or defending a claims decision.