Giving Procurement and Security a Single OWASP LLM Top 10 and NIST AI RMF Score They Both Trust

An AI vendor risk assessment mapped to OWASP LLM Top 10 and NIST AI RMF should score shared controls. OWASP supplies attack specificity, while NIST supplies governance anchors. Mapping the vendor’s evidence to both, then using clear weights and minimum requirements set for the buyer, gives procurement and security one composite score they can defend while keeping critical gaps in view.

Why procurement and security produce conflicting verdicts on the same AI vendor

At the procurement table, security has a vulnerability checklist and procurement has a governance questionnaire for the same AI vendor. Each team can explain its own verdict. Neither can readily act on the other’s findings, because the instruments answer different questions. Security asks which AI attack vectors the vendor addresses, while procurement asks whether the organization has a defensible process for governing AI risk.

The disagreement is structural. OWASP’s primary audience is developers and security engineers, while NIST AI RMF serves CISOs, compliance leads, and executives. Without a shared way to score vendors, assessments depend on personal judgment and are hard to compare during audits. Strong results in areas that matter less can also hide critical weaknesses. Shadow AI compounds that problem when a purchase process misses AI-specific questions and the enterprise inherits risk before governance can operate.

What the OWASP LLM Top 10 (2025 edition) actually enumerates and why the numbering matters for scoring

The OWASP LLM Top 10 2025, released November 18, 2024, gives security teams a taxonomy of AI attack classes. It does not supply a vendor scoring formula. Its numbered entries identify different kinds of exposure, rather than interchangeable units that procurement can simply count. A questionnaire asking whether a vendor addresses every entry therefore turns distinct technical risks into binary answers without establishing their severity in the proposed deployment.

The entries used in this crosswalk illustrate that variety. LLM01 Prompt Injection concerns malicious instructions that redirect model behavior, while LLM02 Sensitive Information Disclosure concerns the exposure of sensitive information. LLM03 Supply Chain addresses risks from the components and suppliers behind an LLM application. LLM06 Excessive Agency covers the harm an AI system can do through the permissions and autonomy it has. These are not equivalent control problems, so a positive answer for one cannot establish protection against another.

For Supply Chain, model cards and published documentation provide model information, but they offer no guarantees on origin. An attacker can compromise a supplier account on a model repository or create a lookalike and combine it with social engineering. Disclosure is not the same as assurance. A scorecard that accepts documentation alone can reward a vendor without establishing the integrity of what it supplies.

Numbering creates a separate comparison problem because the 2025 and 2026 editions both circulate. This mapping uses the documented, PDF-released 2025 edition as its baseline. Excessive Agency is LLM06 in that edition and moves to LLM03 in the 2026 edition. The label alone is therefore not enough. Questionnaire templates citing 2025 numbering need updating when teams adopt the later edition, with the attack-class name preserved so that the mapping remains intelligible.

What NIST AI RMF and the Generative AI Profile (AI 600-1) add that OWASP cannot supply

NIST AI RMF organizes risk management around four functions, which are Govern, Map, Measure, and Manage. Their categories and subcategories give procurement a documented structure for identifying, assessing, and responding to AI risk across an organization. NIST AI 600-1, the Generative AI Profile released July 2024, extends that structure to generative AI. It names 12 risks unique to or exacerbated by generative AI, from confabulation to information security, and supplies suggested actions keyed to RMF subcategories. Those named anchors make a control-level crosswalk possible.

An organization can complete an AI inventory, document a risk register, and map generative AI risks while leaving agents free to call production databases without an audit trail. The framework supplies a management process. It also supplies no vendor-specific score by default. Treating its broad coverage as a single average introduces another weakness, because a strong Transparency rating can mask a fatal gap in Privacy and Security.

Three structural gaps that prevent either framework from producing a score the other team accepts

The first gap is a vocabulary mismatch. OWASP names attack classes, while NIST names governance functions and the work within them. Their taxonomies do not map one-to-one. A security assessment of Supply Chain and a procurement assessment of Govern may examine overlapping reality, but their scores cannot be combined until the shared controls are made explicit. Some controls will touch more than one function or attack class.

OWASP supplies no aggregation formula, and NIST supplies neither runtime controls nor a default vendor score. Alignment with Measure, for example, does not prove that an agent’s actions are constrained in production. A combined assessment must separate evidence that a governance process is in place from evidence that technical protection is in place. It must also state how those findings affect the result.

When the same number names different attack classes in different editions, questionnaires that look alike can measure different things. Version-stamping is part of the scoring method. Teams must check which edition was used before they combine results. The same discipline applies to weighting, because a universal number would obscure how a regulated buyer’s governance needs differ from a consumer-facing buyer’s technical exposure.

How do you map an AI vendor risk assessment to OWASP LLM Top 10 and NIST AI RMF?

To build the questionnaire, the assessment team should use a control-level crosswalk. For each OWASP entry, the crosswalk identifies the relevant RMF function, the specific subcategory or AI 600-1 suggested action, and a vendor question addressing the shared risk. The control is the bridge between them. Security can then read the answer in attack terms and procurement in governance terms, so the vendor only has to answer one questionnaire.

The profile supplies a concrete starting point. Sensitive Information Disclosure, LLM02 in the 2025 edition, maps to its Data Privacy and Information Security risk categories. For evidence of testing, suggested action MS-2.7-007 covers prompt-injection red-teaming under MEASURE 2.7, while MS-2.10-001 covers data-leakage and privacy red-teaming under MEASURE 2.10, providing more precise anchors than “NIST aligned. A question about red-teaming can therefore name the relevant OWASP attack classes and the specific NIST actions together.

The question can ask whether testing covers prompt injection, data leakage, and misuse, and which framework guides the exercises. Evidence tied to the named edition and actions can then populate both sides of the assessment. Broader mappings, such as Supply Chain to Govern and Map, still need specific subcategory or action anchors before they become complete questionnaire items. Every crosswalk should retain its OWASP edition so that later procurements can compare like with like.

OWASP’s AI Vulnerability Scoring System, or AIVSS, provides a method for technical weighting. Version 0.8 is a pre-release milestone from March 2026, with v1.0 in final review and expected by the end of 2026. It begins with a CVSS base score, adds an agentic-capabilities assessment covering autonomy, non-determinism, and tool use, and multiplies the sum by a mitigation factor. The earlier divide-by-two step was removed in v0.8. This is useful evidence of a systematic scoring effort, but its pre-release status makes it unsuitable as the sole foundation for a production vendor score.

How to weight the mapped controls into a composite score both teams can defend

A defensible composite score needs explicit weights tied to the proposed use. Attack severity comes first, because the same category can represent very different exposure across deployments. Excessive Agency is more dangerous in an agent with database access than in a read-only summarization tool. Context changes the weight of the control.

Within the composite, each RMF function should keep its own score and show its gaps, which an average across functions could hide. A strong Govern result cannot compensate for a weak Measure result. The EFROS Index example shows how a claim of partial alignment at the framework level can hide gaps at the subcategory level that a composite must expose.

Regulatory weight then adapts the assessment to the buyer. Buyers in healthcare, financial services, and federal contracting should give Govern and Manage more weight and ask for documents that show AI 600-1 alignment. Buyers who face consumers may give more weight to coverage of technical attacks. A default profile is only a starting point. Buyer-configurable weighting preserves comparability within a procurement cycle when every vendor is assessed under the same profile, without pretending that scores from unrelated industries are interchangeable.

A vendor unable to demonstrate any control against Prompt Injection or Supply Chain should not receive a passing composite score, regardless of its governance ratings. The resulting number must be accompanied by the OWASP edition, RMF version, weighting profile, and assessment date. Those details make its assumptions inspectable and establish whether comparison with another vendor or an earlier assessment is valid.

What a vendor assessment questionnaire looks like when it operationalizes the composite score

The practical questionnaire should ask for verifiable evidence and name the red flags that affect scoring. Every item needs traceability to an OWASP entry by edition and number, and to an RMF subcategory or profile action. Broad function labels are not sufficient anchors.

For security testing, the question asks whether red-teaming covers prompt injection, data leakage, and misuse, and which framework it follows. A good answer describes regular exercises mapped to a named OWASP edition and the profile’s Measure actions. The evidence must show which cases are AI-specific and which fall under general application security. A response saying only “we conduct security testing” is a red flag when it provides no framework reference, edition, or AI-specific test evidence.

For supply chain provenance, the question asks how the vendor verifies the integrity of third-party models, datasets, and plugins. A good answer supplies a signed AI bill of materials, verified model signatures and file hashes, and a documented supplier vetting process. Documentation alone does not answer that question. Reliance solely on model cards is a red flag because it leaves origin assurance unresolved, even if the model itself is thoroughly described.

For excessive agency, the question asks which permissions, tools, and autonomy levels the AI has in production and how they are constrained. A good answer describes minimum-permission design, human approval for high-impact or irreversible actions, and an audit trail for all tool calls. The boundary must match the task’s needs. Permissions chosen for deployment convenience, or the absence of a runtime audit trail, signal a gap that a governance policy cannot repair.

For governance documentation, the question asks whether the vendor maintains an AI inventory and can demonstrate alignment against named RMF subcategories. A complete inventory, a written risk register, and an AI 600-1 mapping for each subcategory give the evidence needed to answer. An unsupported framework-level claim does not suffice. The OWASP side of these questions should identify the attack-specific controls the documentation supports, rather than treat governance documentation as proof that every attack class is addressed.

Even a well-evidenced questionnaire captures only one moment. Model updates and changing attack surfaces make continuous monitoring necessary if the score is to remain valid after deployment. Tool fit therefore depends on the scope of that monitoring. Cycode takes an SDLC-integrated approach to controls, while dedicated AI risk intelligence platforms continuously monitor the AI assets of vendors across the vendor ecosystem. For TPRM, InfoSec, Privacy, and Legal teams, the relevant platform criterion is whether ongoing AI-specific signals can inform vendor assessment, rather than leave the procurement score frozen while the system changes.