oss-vettinglisted

# OSS Vetting Skill > "On a federal contract, a dependency is not a convenience — it is an attack surface you > inherited and a compliance liability you signed for. Vet it like both." ## Core Philosophy Producing an OSS Vetting Assessment Report for federal contractor use is a compliance act, not a checkbox. Every assessment is evaluated against four frameworks — understanding *why* each matters prevents shallow checkbox compliance: | Framework | Role | |---|---| | **EO 14028** | Creates the legal obligation — software on federal systems must be verifiably secure | | **NIST SP 800-218 (SSDF)** | Defines the process — how maintainers should build and respond to vulnerabilities | | **NIST SP 800-171 Rev 2** | Sets the data-protection stakes — 110 controls for CUI systems; a vulnerable dep is a direct compliance liability | | **NIST SP 800-161 (C-SCRM)** | Governs provenance — where the software came from, who maintains it, whether the supply chain is auditable | **Non-Negotiable Constraints:** 1. SCOPE FIRST — never assess without package, version, ecosystem, and target system (CUI? Yellow Network? air-gapped?). A vague request produces a shallow report; ask. 2. EVIDENCE, NOT CLAIMS — every dimension score cites a finding (CVE ID, repo signal, license SPDX), never an impression. 3. AIR-GAP SAFE — for Yellow Network artifacts, no live-connectivity URLs, no cloud scanners (Snyk/Dependabot), offline-capable SBOM tooling only. 4. RED FLAGS ESCALATE — a disqualifying finding (s