cargo-deny és RustSec: ellenőrizhető függőségi szabályok a CI-ban

A cargo test sikere önmagában nem mondja meg, hogy az alkalmazás függőségei között szerepel-e ismert sérülékeny csomag. A fordító a licencfeltételeket és a csapat által tiltott forrásokat sem értékeli. Ezekhez külön, ismételhető ellenőrzés kell. Ebben a cikkben egy apró Rust-könyvtár függőségi gráfjára fogalmazunk szabályokat, majd ugyanazt a konfigurációt használjuk helyben és egy előkészített CI-sablonban.

A kísérőprojekt az examples/articles/cargo-deny könyvtárban található, Rust 1.97.1 és edition 2024 beállítással. Közvetlen futási függősége a rögzített serde_json 1.0.151; a teljes feloldás a Cargo.lock része. Az ellenőrzéshez cargo-deny 0.20.2 verziót használtunk. A verziórögzítés itt sem azt jelenti, hogy soha nem frissítünk: azt teszi világossá, melyik eszköz értelmezte a szabályokat.

Négy külön kérdést tegyél fel

A cargo-deny ellenőrzései külön kezelik az advisorykat, licenceket, tiltásokat és forrásokat. A RustSec-adatbázis ismert problémákat közöl a crate-ekről. A licencvizsgálat az engedélyezett kifejezéseket ellenőrzi. A tiltási szabályok csomagokra, verziókra vagy több verzió egyidejű jelenlétére vonatkozhatnak. A forrásszabály pedig például ismeretlen registryt vagy Git-függőséget jelezhet.

Ezeket nem érdemes egyetlen „biztonságos” jelzővé összevonni. Egy advisory nélküli csomag tartalmazhat még ismeretlen hibát; egy megengedett licenc nem minősíti a kód minőségét. A RustSec nyilvántartása fontos bemenet, de nem helyettesíti a fenyegetési modell vagy az alkalmazás saját jogosultsági hibáinak vizsgálatát. A kapott eredmény azt mondja meg, hogy az adott pillanatban ismert adatok mellett megfelelt-e a gráf a megadott szabályoknak.

A gráf megértéséhez jól jön a Cargo build, run és test lecke. Ha a függőséget generikus könyvtári kódból használod, a generikus függvények és típusok segít az alkalmazási határ tisztázásában. A szabályt mindig a ténylegesen használt csomagokhoz és feature-ökhöz igazítsd.

Kis, indokolható konfigurációval indulj

A mintában két licenckifejezést engedünk, nem másolunk be hosszú, találomra összeállított listát. A többverziós függőség figyelmeztetés, mert önmagában gyakori és nem feltétlenül hiba. A wildcard verzió és az ismeretlen csomagforrás tiltott. Az advisory-kivételek listája üres: a zöld eredményt nem egy általános felmentés okozza. Az advisory-konfiguráció dokumentációja tartalmazza a részletes lehetőségeket; más eszközverzióra váltáskor a séma változását is ellenőrizd.

[advisories]
db-urls = ["https://github.com/RustSec/advisory-db"]
ignore = []
yanked = "deny"

[licenses]
allow = ["MIT", "Apache-2.0"]

[bans]
multiple-versions = "warn"
wildcards = "deny"

[sources]
unknown-registry = "deny"
unknown-git = "deny"
allow-registry = ["https://github.com/rust-lang/crates.io-index"]

A licencengedélyezés mérnöki konfiguráció; a szervezeted licencpolitikáját az érintett felelősökkel kell meghatározni. A példa értékei a mintagráf futtatásához tartoznak. Ha egy új függőség más licencet hoz, az ellenőrzés megállása hasznos változásjelzés. Ne bővítsd automatikusan az engedélylistát csak azért, hogy zöld legyen a következő futás.

A friss adatbázis és a lockfile együtt számít

cargo install cargo-deny --version 0.20.2 --locked
cd examples/articles/cargo-deny
cargo test --locked
cargo deny --locked check

A --locked megakadályozza, hogy az ellenőrzés észrevétlenül új lockfile-feloldásra váltson. Az advisory-adatbázis ettől még frissülhet, és éppen ez a cél: egy tegnap elfogadott változat ma új jelentést kaphat. A helyi ellenőrzés a nyilvános RustSec-adatbázis lekérésével futott, és mind a négy vizsgálati csoport sikeres volt. Ez időponthoz kötött eredmény; a cikk későbbi olvasásakor újra kell futtatni.

Az offline működés más bizonyítékot ad. Ha csak régi adatbázis érhető el, a zöld eredmény nem jelenti, hogy a legújabb advisorykat is figyelembe vetted. Hálózati hiba esetén ne alakítsd át a sikertelen ellenőrzést automatikus jóváhagyássá. A futási környezet hibáját külön lehet kezelni, de a kiadás döntéséhez tudni kell, milyen adatforrásból született az eredmény.

A CI-sablon kapjon kevés jogosultságot

A projekt mellé adott workflow a beágyazott .github/workflows/dependencies.yml fájlban található. Ez a példakönyvtárban nem aktív repository-workflow. Saját projektbe történő átemeléskor ellenőrizd a munkakönyvtárat, a főág nevét és a támogatott toolchaint. A sablon pull requestre, főági pushra és heti ütemezésre készít futást; az ütemezés azért hasznos, mert a függőségi fájlok változása nélkül is megjelenhet új advisory.

A checkout action teljes commitazonosítóval rögzített, a token csak tartalomolvasási jogot kap. A GitHub biztonságos Actions-használati útmutatója indokolja a minimális jogosultságot és a külső actionök ellenőrzését. A példához nincs szükség telepítési kulcsra vagy éles szolgáltatás hozzáférésére. A sablon helyi előkészítése nem jelent GitHubon lefutott CI-bizonyítékot.

Ha később kivétel szükséges, legyen konkrét advisoryhoz vagy csomaghoz kötve, indokkal és felelőssel. Írd le, melyik kódút érintett, meddig vállalható a kockázat, és mi szünteti meg a kivételt. Egy örökre ott maradó ignore lista könnyen elrejti a változást. A rendszer akkor segít, ha az új figyelmeztetéshez döntés tartozik, a régi felmentés pedig időről időre újra megvizsgálható.

A példa ellenőrzési környezete

Rust 1.97.1, edition 2024 és cargo-deny 0.20.2 mellett a könyvtár egységtesztje sikeres volt. A frissen lekért RustSec-adatokkal mind a négy policy-ellenőrzés sikerült. Egy külön ideiglenes konfigurációban kifejezetten tiltott serde_json csomagot a vizsgálat elutasított. GitHubon futó workflow-t nem indítottunk; a mellékelt YAML helyi, inaktív sablon.