Every organization with more than a handful of software vendors has a third-party risk management process. Most of them hate it. The vendors hate filling out questionnaires. The security team hates reviewing the answers. And everyone quietly acknowledges that a self-reported spreadsheet completed once a year is not an accurate picture of a vendor's actual security posture.
The third-party risk assessment model is broken. It has been broken for years. But the convergence of SBOM adoption, continuous monitoring technology, and regulatory pressure is finally creating the conditions for something better.
Why the Current Model Fails
The standard third-party risk assessment looks something like this: send a questionnaire (often hundreds of questions), wait weeks for responses, review the answers, assign a risk score, file it away, and repeat next year. The problems are structural.
Self-reported data is unreliable. Vendors answer questionnaires based on their best understanding of their own security posture, which is frequently optimistic. They describe their policies, not their practices. The difference between "we have a patch management policy" and "we apply critical patches within 72 hours" is the difference between a document and a capability. Questionnaires measure the former.
Point-in-time assessments miss ongoing risk. A vendor that passes an annual assessment in January can suffer a breach in February and you would not know until the next assessment cycle. Annual reviews create a false sense of security — the assessment is stale the moment it is completed.
Scale breaks manual processes. The average enterprise works with hundreds of software vendors. Sending, collecting, reviewing, and scoring hundreds of questionnaires consumes thousands of hours per year. The effort is disproportionate to the insight gained, especially for lower-tier vendors that receive a cursory review regardless.
The adversary does not care about your questionnaire. Supply chain attackers target the weakest link. They are not fooled by SOC 2 reports and policy documents. They look for outdated dependencies, exposed credentials, misconfigured build systems, and abandoned maintenance — none of which appear in a standard vendor questionnaire.
What Automation Looks Like in Practice
Automating third-party risk assessment does not mean replacing human judgment with an algorithm. It means shifting the inputs from self-reported claims to evidence-based signals, and shifting the frequency from annual to continuous.
SBOM-Based Assessment
The most significant shift in third-party risk assessment is the ability to evaluate a vendor's software composition directly. When a vendor provides an SBOM for their product, you can programmatically assess:
- Known vulnerabilities in every component, including transitive dependencies
- Component age and maintenance status — are dependencies current or years out of date?
- License compliance — do the licenses in the dependency tree conflict with your usage?
- Dependency depth and complexity — how many transitive dependencies exist, and what is the overall attack surface?
This is not theoretical. SBOM exchange between vendors and customers is growing rapidly, driven by federal procurement requirements, the EU Cyber Resilience Act, and industry-specific mandates in healthcare and financial services. Organizations that can ingest and analyze vendor SBOMs have a fundamentally more accurate picture of vendor risk than those relying on questionnaires.
Continuous Monitoring
Instead of a single assessment per year, automated monitoring systems track vendor risk signals on an ongoing basis:
- Public vulnerability disclosures affecting the vendor's products
- Security incident reports and breach notifications
- Certificate and domain monitoring for the vendor's infrastructure
- Open-source component health based on SBOM analysis
- Compliance status changes — expired certifications, audit findings
These signals are aggregated into a risk score that updates in real time. When a vendor's risk profile changes — a critical vulnerability is disclosed in their product, their security certification lapses, or a dependency they use is compromised — the assessment updates immediately rather than waiting for the next annual review.
Evidence Collection and Verification
Automated systems can also collect and verify evidence that was previously self-reported:
- Security headers and TLS configuration from public-facing infrastructure
- DNS and email security (SPF, DKIM, DMARC) configuration
- Public code repository security practices (branch protection, dependency scanning, signed commits)
- Vulnerability disclosure program existence and responsiveness
None of these signals tell the complete story, but they provide an evidence-based supplement to self-reported questionnaire data. A vendor that claims to follow security best practices but has expired TLS certificates and no vulnerability disclosure program is worth investigating further.
Building an Automated Assessment Program
Tier Your Vendors
Not every vendor warrants the same level of scrutiny. Tiering your vendors based on the criticality and sensitivity of the data and systems they access lets you allocate assessment resources proportionally.
Tier 1 — vendors with access to production systems, customer data, or critical infrastructure. These receive the most rigorous assessment: SBOM analysis, continuous monitoring, periodic deep-dive reviews.
Tier 2 — vendors whose products are used in development or internal operations. These receive SBOM analysis and continuous monitoring, with periodic reviews triggered by risk signal changes.
Tier 3 — vendors with limited access and low criticality. These receive automated monitoring and are flagged for review only when risk signals exceed thresholds.
Require SBOMs in Procurement
The most impactful change an organization can make is requiring SBOMs as a condition of procurement. This shifts the burden of transparency to the vendor and provides the raw material for automated assessment.
Specify the format (CycloneDX or SPDX), the required completeness level (minimum fields, transitive dependency inclusion), and the delivery mechanism (API endpoint, registry, or direct upload). Organizations that have implemented this requirement report that it also serves as a useful signal about vendor maturity — vendors that can produce a quality SBOM quickly are generally more mature in their development practices.
Automate the Questionnaire
For the questions that still require self-reporting, automate the collection and scoring process. Map questionnaire responses to specific evidence sources where possible, so that self-reported answers can be partially verified. Use conditional logic to skip questions that are answered by other evidence — if SBOM analysis shows a vendor patches critical vulnerabilities within 72 hours, you do not need to ask them about their patch management policy.
Define Automated Risk Thresholds
Establish clear thresholds that trigger automated actions:
- Critical vulnerability in a Tier 1 vendor product triggers immediate notification and remediation tracking
- Health score below threshold triggers escalated review and vendor engagement
- License conflict detection triggers legal review
- Expired compliance certification triggers procurement hold
These thresholds replace the subjective judgment calls that slow down manual processes and ensure consistent risk treatment across the vendor portfolio.
The Regulatory Tailwind
Regulators are increasingly mandating the kind of evidence-based, continuous vendor assessment that automation enables. CISA's guidance on software supply chain security explicitly recommends SBOM-based vendor evaluation. The EU Cyber Resilience Act requires demonstrable due diligence in the software supply chain. Financial regulators (OCC, DORA) are tightening expectations around third-party technology risk.
Organizations that automate now are building capability that will become a compliance requirement within the next two to three years. The ones waiting for the mandate will scramble to build what early adopters have already operationalized.
How Safeguard.sh Helps
Safeguard's TPRM module automates third-party risk assessment by ingesting vendor SBOMs, continuously monitoring component health and vulnerability status, and scoring vendor risk based on evidence rather than self-reported questionnaires. Policy gates can enforce vendor risk thresholds in your deployment pipeline — blocking releases that depend on vendor components that fall below your organization's risk appetite. Combined with Griffin AI for querying vendor risk across your entire portfolio, Safeguard replaces the annual questionnaire cycle with continuous, evidence-based vendor risk management.