Third-Party Software Risk Assessment Under NIST 800-171 Rev 2

Defense contractors depend on software they did not write: operating system utilities, engineering tools, drivers, SaaS clients and plugins. Each one can introduce risk into an environment that handles CUI. A third-party software risk assessment is the structured way to judge that risk before the software is installed, rather than after something goes wrong.

What Rev 2 says about third-party software

CMMC Level 2 is assessed against NIST SP 800-171 Rev 2: 32 CFR 170.14(c)(3) states that the Level 2 requirements are identical to those in NIST SP 800-171 R2, as set out in 32 CFR Part 170. Rev 2 has no dedicated supply chain risk management family; that family (3.17) appears in Rev 3, which is not the CMMC baseline. Rev 2 touches the subject only in passing: several discussion sections point to NIST SP 800-161 for supply chain risk management, and the CMMC Assessment Guide lists supply chain failures among the external events a risk assessment under RA.L2-3.11.1 may consider. This means there is no single requirement titled "assess your software vendors". Instead, a software risk assessment draws on several Rev 2 practices.

The periodic risk assessment requirement, RA.L2-3.11.1, covers risk from the operation of systems that process CUI, and the software installed on them is part of that picture. Flaw remediation, SI.L2-3.14.1, depends on vendors that publish and ship fixes. Configuration management practices, including CM.L2-3.4.8 on application execution and CM.L2-3.4.9 on user-installed software, are where the decision is enforced. Mapping a software review to these practices is a judgment call, and it should be agreed with your compliance advisor.

Four groups of risk factors

A useful assessment looks at four things, in an order that lets you stop early.

The vendor. Who owns and controls the company, where it is incorporated and where its developers and servers are, and whether it appears on sanctions or prohibited-source lists. A failure here is often disqualifying regardless of how good the product is. See screening vendors for sanctions and ownership.

The product's security record. Vulnerability history, how quickly fixes ship, whether there is a published disclosure channel, and whether the product is still supported. A product with no updates for years is a risk that grows with time.

The software's behavior. What it does when installed and run: which network destinations it contacts, what it writes to disk and to the registry, whether it installs services or kernel-mode drivers, and which privileges it asks for. This is observed, not assumed, which is why sandbox analysis belongs in the assessment.

Fit with your environment. The same software carries different risk in different places. A tool that phones home is a larger concern on a system that holds CUI than on an isolated lab machine. Consider the data the software will touch and the network it will sit on.

Deciding: approve, approve with conditions, reject

Reduce the findings to one of three outcomes. Approve when risk is acceptable as is. Approve with conditions when risk can be reduced with enforceable measures, such as limiting permitted network destinations, preventing administrator execution or disabling an update or telemetry feature. Reject when the risk cannot be reduced to an acceptable level or a disqualifying factor is present. Record the rationale for every outcome, because rejected requests are evidence that the process works.

Compensating controls must be real

A condition that cannot be enforced is a wish. If a decision depends on blocking a network destination, confirm that your firewall rule exists. If it depends on running as a standard user, confirm that the application control policy enforces it. Keep the enforcement record with the decision.

Scoping effort to risk

Not every application needs a full analysis. A practical approach is to tier requests: a fast review for low-risk software with a known publisher and no network behavior, and a deeper review for software that is unsigned, installs drivers, handles credentials or connects to external services. Define the tiers in writing so reviewers apply them consistently. The end-to-end flow is described in our approval workflow.

Where DigVel fits

DigVel's two-phase service follows this structure: Phase 1 screens the vendor and the product's record and stops early on a blocker, and Phase 2 analyzes the installer's behavior in a sandbox and maps findings to NIST SP 800-171 practices. See the service overview, the methodology and the control mapping. This article is general information, not legal advice, and a report from DigVel supports your own assessment rather than replacing it.