Public works finds open-source model components in a vendor stack. What supply-chain step should come first?

Public works must treat open-source model components as supply-chain artifacts, not as risk-free gifts. The correct first step is to verify license compatibility with municipal procurement and redistribution rules, then complete a security review of those components before they enter production. License review surfaces copyleft, patent, and attribution constraints that can conflict with city contracts, public-data release obligations, or downstream vendor terms. Security review covers known CVEs, model- and dependency-level integrity, provenance of weights and packages, and whether the component’s maintenance posture supports civic SLAs. Together, these controls convert an opaque vendor stack into an accountable bill of materials.

Skipping license and security review because open source is “always free of risk” confuses cost with assurance: free redistribution does not imply safe code, compatible licenses, or trustworthy training data. Assuming community popularity alone proves production safety substitutes social proof for due diligence; widely used packages still ship vulnerabilities and license traps that matter for regulated municipal workloads. Banning documentation of open-source components so auditors cannot find them is concealment, not control—it increases legal exposure and fails transparency expectations for public-sector AI.

Exam caveat: open-source inclusion is common and often desirable in civic stacks; the exam point is governed intake (license + security), not a blanket ban. Popularity and “free” status never replace review.

Operational check: require an SBOM or component inventory for the vendor stack, map each open-source element to an approved license policy, run vulnerability and integrity checks, record residual risk and owner, and block production promotion until public works signs off on both legal and security gates.