K zámene závislostí dochádza vtedy, keď má balíčkovací manažér pre jeden názov závislosti k dispozícii viacero možných zdrojov a vyberie nežiaduci balík. Aplikácia síce požaduje známy názov, avšak pravidlá registrov alebo vyhľadávania nasmerujú inštaláciu na kód, ktorý je kontrolovaný mimo očakávaného zdroja.
Ako vzniká nejednoznačné vyhľadávanie
Organizácie často publikujú interné balíky do súkromného registra, pričom zároveň povoľujú prístup k verejnému registru. Ak v oboch existuje rovnaký názov bez špecifikovaného rozsahu (scope), balíčkovací manažér potrebuje pravidlo na ich rozlíšenie. Na výsledok môžu vplývať preferencie verzií, poradie zdrojov, kešované metadáta alebo samotná konfigurácia.
Zraniteľnosť sa nachádza priamo v procese vyhodnocovania závislostí, nie v príkaze import v aplikácii. Správne vyzerajúci import môže viesť k úplne inému artefaktu, ak sa build spustí v inom prostredí alebo ak znova vyhodnotí celý graf.
| Konfiguračná situácia | Vzniknutá nejednoznačnosť | Dôkazy pre audit |
|---|---|---|
| Súkromný a verejný register zdieľajú názvy | Požiadavku môže splniť ktorýkoľvek zdroj | Konfigurácia registrov a rozsah (scope) balíka |
| Verejné verzie majú prednosť pred internými | Systém môže uprednostniť verejný artefakt | Politika verzií a záznam o vyhodnotení |
| Chýbajúci alebo ignorovaný lockfile | Nové vyhodnotenie môže vybrať iný zdroj | Príkaz pre build a commitnuté súbory |
| Použitie pohyblivého odkazu na zdroj | Obsah sa môže zmeniť bez zmeny názvu | Odkaz na commit, tag alebo digest |
Čo sleduje audit kódu
V rámci auditu vibe-coded softvéru sa najskôr analyzuje kompletný zoznam zdrojov balíkov. Identifikujú sa súkromné názvy, kontroluje sa ich ochrana prostredníctvom menných priestorov či rozsahov (scopes) a preveruje sa spôsob autentifikácie lokálneho vývoja, CI/CD nástrojov a produkčných buildov voči jednotlivým registrom.
Revízia sa potom zameriava na dôkazy o vyhodnocovaní:
- Zoznam registrov: Zaevidovanie všetkých konfigurovaných verejných, súkromných a proxy zdrojov.
- Mapovanie interných názvov: Identifikácia balíkov, ktoré sa smú vyhľadávať výhradne v rámci organizácie.
- Pravidlá priority: Určenie, ktorý zdroj a verzia zvíťazí v prípade kolízie názvov.
- Kontrola súborov lockfile: Overenie, či buildy využívajú commitnuté riešenia a dáta o integrite.
- Bezpečná reprodukcia: Overenie vybraného zdroja v izolovanom prostredí buildu.
Opatrenia na odstránenie nejednoznačnosti
Rozsahy balíkov (scopes) alebo vyhradené menné priestory spájajú interné názvy s konkrétnym registrom. Explicitné mapovanie registrov bráni systému zaobchádzať s verejnými a súkromnými zdrojmi ako so zámennými. Ukotvenie závislostí, commitnuté lockfile súbory a kontroly integrity artefaktov poskytujú ďalšie dôkazy o tom, že vybraný balík zodpovedá tomu preskúmanému.
Analýza zloženia softvéru dokáže zobraziť, ktorý komponent sa nakoniec do buildu dostal, no prevencia spočíva v konfigurácii registrov a samotného buildu. Potrebné sú obe zložky: jedna riadi vyhľadávanie, kým druhá odhaľuje, čo bolo reálne vybrané.
Prečo generované nastavenia stále vyžadujú kontrolu
Generované konfigurácie často vychádzajú z bežných predvolených nastavení balíčkovacích manažérov. Tieto predvolené hodnoty však nevedia, ktoré názvy balíkov sú súkromné alebo ktorý register je pre organizáciu autoritatívny. Build môže opakovane fungovať v jednom prostredí, hoci v inom zostáva nejednoznačný.
Širšia revízia pre riziko závislostí (dependency risk) vníma identitu zdroja ako integrálnu súčasť komponentu, spolu s jeho názvom a verziou. Jasné stanovenie tejto identity je jednou z produkčných povinností opísaných v článku o rozdiele medzi vibe codingom a agentovým inžinierstvom.
