Ühinemis- ja omandamistegevuse hoolsuskohustuse taotlus saabub teisipäeva hommikul: kogu tarkvara avatud lähtekoodiga litsentside vastavusaruanne, mille tähtaeg on reede. Juriidilisel meeskonnal on kolm päeva aega, et koostada inventuur kõigist avatud lähtekoodiga komponentidest kogu toote koodibaasis, kõigist kehtivatest litsentsidest ja kõigist kohustustest, mis tuleb enne omandaja juriidilist läbivaatamist täita. Organisatsioonide jaoks, kes käsitlevad litsentside vastavust perioodilise käsitsi läbivaatamise harjutusena, algab sel teisipäeva hommikul üks ettevõtte tarkvara kõige kallimaid tulekahjuõppusi. Organisatsioonide jaoks, millel on väljakujunenud sõltuvusanalüüsi infrastruktuur, algab see aruande koostamisega.
Tarkvara enamasti monteeritakse, mitte ei kirjutata. Black Duck 2026 OSSRA aruandes leiti, et 98% kommertskoodibaasidest sisaldab avatud lähtekoodiga komponente, 87%-l on vähemalt üks teadaolev haavatavus ja keskmine haavatavuste arv koodibaaside kohta on aastaga enam kui kahekordistunud. Litsentsinõuetele vastavuse auditeerimine on valdkond, mis vastab teistsugusele, kuid seotud küsimusele: mitte ainult sellele, millised komponendid sisaldavad haavatavusi, vaid ka sellele, millised komponendid kehtestavad õiguslikke kohustusi tarkvara levitamise, muutmise või turustamise osas. GPL-2.0 sõltuvuse puudumine omandiõigusega kaitstud kommertstootes ei ole turvaintsident. See on litsentsirikkumine, mis võib nõuda lähtekoodi avalikustamist, õiguslikku kokkulepet või toote turult kõrvaldamist.
Litsentsi vastavusauditi aluseks on sõltuvusanalüüs ehk iga tarkvarakomponendi süstemaatiline tuvastamine, millest koodibaas otseselt või kaudselt sõltub, koos iga komponenti reguleeriva litsentsi täieliku omistamisega. Sõltuvusanalüüs ei ole paketi manifesti skaneerimine. See on täielik struktuuriuuring selle kohta, mida tarkvara tegelikult ehituse ja käitusaja jooksul sisaldab, olenemata sellest, kas need lisandid on deklareeritud, transitiivsed, tarnija poolt määratud või kaudsed.
Litsentsimuudatus? Tea selle mõju.
SMART TS XL loob suurarvuti tarkvara komponentide inventuuri, millega tavalised SBOM-generaatorid hakkama ei saa.
SAAGE LISATEAVET…Miks on sõltuvusanalüüs alus?
Litsentsinõuete järgimine on enne juriidilist probleemi sõltuvusprobleem. Tarkvaratoote litsentsikohustusi ei saa hinnata ilma eelnevalt teadmata, millest see toode on tehtud, iga komponenti, iga teeki, iga kopeeritud koodijuppi. Litsentsianalüüs toimub sõltuvuste inventuuri järel. Vale inventuuri korral põhineb litsentsianalüüs mittetäielikul pildil.
Kolm küsimust, millele sõltuvusanalüüs peab litsentsinõuetele vastavuse tagamiseks vastama:
Millised komponendid on kaasas? Mitte ainult otsesed sõltuvused, mis on deklareeritud jaotises package.json or pom.xml, aga iga transitiivset sõltuvust, mille nad kaasa toovad, iga tarnija teeki, mis kopeeritakse lähtekoodipuusse, iga staatiliselt lingitud komponenti, mis kompileeritakse binaarfaili, ja iga dünaamiliselt laaditud moodulit, mida kutsutakse käitusajal. Hea SCA mootor seob need komponendid haavatavuste andmebaasidega (nt NVD), kontrollib litsentsi metaandmeid ja märgistab teadaolevad ärakasutamised või juriidilised riskid enne, kui need teie tarnetorustikku mõjutavad. Sama mootor peab olema täpne ka inventuuri tasandil, st selle osas, mis tarkvaras tegelikult on, enne kui litsentsianalüüsi saab usaldada.
Milliste litsentside alusel neid reguleeritakse? Komponendil võib olla üks deklareeritud litsents, topeltlitsents valikutega, mitu litsentsi, mis kehtivad erinevatele failidele, või litsents, mis on versioonide lõikes muutunud. FOSSA litsentside tuvastamise mootor väidab 99.8% täpsust, mis on oluline siis, kui teie juriidiline meeskond peab lisaks turvainventuurile kontrollima avatud lähtekoodiga kohustusi. Litsentsi tuvastamine komponendi tasandil on vajalik, kuid ebapiisav, komponentide puhul, mille erinevatel failidel on erinevad litsentsid, on vaja tuvastada faili või koodilõigu tasandil.
Milliseid kohustusi need litsentsid ette näevad? Lubav litsents (MIT, Apache-2.0) kehtestab omistamisnõuded. Nõrk copyleft-litsents (LGPL) kehtestab erinevad kohustused olenevalt sellest, kas komponent on lingitud dünaamiliselt või staatiliselt. Tugev copyleft-litsents (GPL-2.0, GPL-3.0) võib nõuda kogu kombineeritud teose lähtekoodi levitamist. Kohustuste mõistmine eeldab litsentsitingimuste, mitte ainult litsentsi identifikaatori mõistmist.
Neli sõltuvustüüpi, mis loovad litsentsiga kokkupuute
Kõik sõltuvused ei ole võrdselt nähtavad ega ole olemasolevate tööriistade poolt võrdselt hallatavad. Litsentsi kättesaadavus tuleneb neljast erinevast sõltuvustüübist, millest igaüks nõuab erinevaid avastamismeetodeid:
1. Paketihalduri sõltuvused (deklareeritud ja transitiivsed)
Kõige nähtavam kiht: manifestifailides deklareeritud sõltuvused (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) ja transitiivsed sõltuvused, mille nad ehituse ajal lahendavad. Paketihalduri sõltuvused on kõige paremini käsitletud kategooria, SCA tööriistad skannivad manifeste, lukustusfaile ja ehitusartefakte, et neid loetleda.
Kriitiline erinevus seisneb otsese ja transitiivse sõltuvuse vahel. Otsene sõltuvus on see, mille arendaja valis. Transitiivne sõltuvus on see, mida otsene sõltuvus nõuab. Arendaja, kes lisab ühe react-data-grid Node.js projekti paketi importimine võib importida kümneid transitiivseid sõltuvusi, millel kõigil on oma litsents. Arendaja ei valinud neid litsentse. Need eksisteerivad sõltuvuste puus igal juhul.
Json
// package.json: 1 direct dependency declared
{
"dependencies": {
"react-data-grid": "^7.0.0"
}
}// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.Transitiivse litsentsi lõks: litsentsirisk ei seisne selles, mida sa deklareerisid. See seisneb selles, mida sinu sõltuvused ja mida nende sõltuvused deklareerivad. Puhas otseste sõltuvuste puu lubavate litsentsidega võib varjata kolme taseme sügavust GPL-litsentsiga transitiivset sõltuvust, mis kehtestab kogu distributsioonile copyleft-kohustused.
2. Müüja ja kopeeritud lähtekood
Väliste projektide lähtekood kopeeritakse otse repositooriumisse – see on tavaline muster C/C++ projektides, mooduliteta Go projektides ja pärandkoodibaasides. Tarnija kood ei ilmu paketihalduri manifestides, kuna see lisati kopeerimise ja kleepimise teel, mitte sõltuvushalduri kaudu.
SCANOSS-i koodijupi tasemel skannimine läheb kaugemale manifestipõhisest tuvastamisest, sobitades lähtekoodi fragmente enam kui 100 miljoni avatud lähtekoodiga failiga OSSKB-s. Koodijupi tasemel skannimine on vajalik tarnija koodi ja kopeeritud funktsioonide tuvastamiseks – need lähenemisviisid ei deklareeri manifesti sõltuvust, kuid kannavad täielikke litsentsikohustusi, justkui oleks komponent selgesõnaliselt lisatud.
Stack Overflow vastusest kopeeritud müüjapoolne utiliidifunktsioon, mis pärineb GPL-litsentsiga koodist, kannab sama copyleft-kohustust kui otsene GPL-sõltuvus, kuid see ei ilmu kusagil paketi manifestis, lukustusfailis ega üheski automatiseeritud skannimises, mis loeb ainult deklareeritud sõltuvusi.
3. Staatiliselt lingitud teegid
Teekid, mis kompileeritakse otse rakenduse binaarfaili ehituse ajal. Erinevalt dünaamiliselt lingitud teekidest, mis eksisteerivad käitusajal eraldi failidena, on staatiliselt lingitud teegid käivitatavasse faili manustatud. Need ei ole paketihalduri manifestides nähtavad, need ilmuvad ehituskonfiguratsioonides (Makefile, CMakeLists.txt, linkeriskriptid) ja kompileeritud binaarfailis endas.
LGPL-litsentsiga teekide puhul määrab litsentsikohustuse staatiline ja dünaamiline linkimine. LGPL lubab dünaamilist linkimist ilma copyleft-levitamiseta; staatiline linkimine võib käivitada copyleft-nõuded kombineeritud teosele. Staatiliselt lingitud komponentide ja nende litsentside tuvastamiseks on vaja binaaranalüüsi tööriista, mis uurib kompileeritud artefakti, mitte ainult lähtekoodi manifesti.
4. Käitusaja laaditud sõltuvused
Dünaamiliselt käitusajal laaditud teegid pluginate arhitektuuride, hilise sidumise või skriptimismootori integratsioonide kaudu. Neid sõltuvusi ei pruugi olla võimalik lahendada ainult lähtekoodi analüüsi abil, need sõltuvad käituskeskkonnast, konfiguratsioonist ja teostusteest. Peegelduse kaudu laaditud andmebaasi draiverid, teenuse laadimismehhanismide kaudu avastatud parseri pluginad ja käivitamisel failisüsteemi teedelt laaditud skriptimislaiendid on kõik käitusaja sõltuvused, millel võivad olla litsentsiga seotud tagajärjed.
Litsentsiriski kategooriad ja nende kohustused
Avatud lähtekoodiga litsentsid jagunevad lubavatest piiravateni. Iga litsentsi asukoha mõistmine selles spektris määrab sellega kaasneva vastavuskohustuse:
Lubavad litsentsid (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)
Kohustus: Viitamine autorile, litsentsi teksti ja autoriõiguse märge lisamine levitamisse. Lähtekoodi avalikustamine pole nõutav. Kaubanduslik kasutamine on lubatud ilma piiranguteta. Integreerimine omandiõigusega kaitstud toodetesse on lubatud.
Kommertstarkvara riskitase: Madal. Omistamist on lihtne automaatselt täita.
Nõrgad copyleft-litsentsid (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)
Kohustus: Litsentseeritud komponendi autorile viitamine ja muudatused tuleb jagada. Täpsemalt LGPL puhul: dünaamiline linkimine vastab üldiselt litsentsi tingimustele ilma kutsuvale koodile copyleft'i käivitamata; staatiline linkimine ei pruugi seda teha.
Kommertstarkvara riskitase: keskmine. Sõltub linkimismeetodist. Dünaamiline linkimine on tavaliselt ohutu; staatiline linkimine nõuab hoolikat juriidilist läbivaatamist.
Tugevad autoriõiguse litsentsid (GPL-2.0, GPL-3.0, AGPL-3.0)
Kohustus: Autorile viitamine ja kogu GPL-komponenti sisaldav teos tuleb teha kättesaadavaks GPL-tingimuste kohaselt (lähtekoodi avalikustamine). AGPL laiendab seda ka võrgu kaudu ligipääsetavale tarkvarale.
Kommertstarkvara riskitase: Kõrge. GPL-litsentsiga komponent, mis on staatiliselt lingitud patenteeritud kommertstootega või on sellest tuletatud, võib nõuda patenteeritud lähtekoodi avalikustamist. See on litsentsirisk, mis tekitab suurimaid õiguslikke kokkuleppeid.
Võrgu autoriõigus (AGPL-3.0)
Kohustus: Kõik GPL-3.0 kohustused, lisaks: kasutajaid, kes suhtlevad tarkvaraga võrgu kaudu, peetakse tarkvara saajateks, mis käivitab allika avalikustamise kohustuse isegi SaaS-toodete puhul, mis kunagi binaarfaile ei levita.
SaaS-toodete riskitase: Väga kõrge. AGPL on spetsiaalselt loodud GPL-i „SaaS-lünga“ sulgemiseks. Kommertslik SaaS-toode, mis sisaldab AGPL-komponenti, peab avaldama oma allika igale kasutajale, kes sellega võrgu kaudu suhtleb.
Omandiõigusega ja ärilitsentsid
Kohustus: Litsentsilepingus määratletud, varieerub „ümberjagamise keelust“ kuni „ühikupõhise litsentsitasuni“ ja „ettevõtte litsentsini“. Need ei ole avatud lähtekoodiga, kuid ilmuvad sõltuvuspuudes kommertskomponentide kasutamisel.
Riskitase: Oleneb tingimustest. Sageli avastatakse ühinemiste ja omandamiste auditi käigus, kui loetletakse omandatud toodete litsentsitasu kohustused.
Litsentside ühilduvus: oluline maatriks
Kui ühte tarkvaratootesse kombineeritakse erinevate litsentsidega komponente, peavad litsentsid olema ühilduvad. Ühildamatud litsentside kombinatsioonid tekitavad õigusliku riski, mida ei saa lahendada ainult omistamisega, kuna kombinatsioon ise võib rikkuda ühte või mõlemat litsentsi.
| Koos | MIT | Apache-2.0 | LGPL-2.1 | GPL-2.0 | GPL-3.0 | PLFA-3.0 |
|---|---|---|---|---|---|---|
| MIT | Kokkusobiv | Kokkusobiv | Kokkusobiv | Kokkusobiv | Kokkusobiv | Kokkusobiv |
| Apache-2.0 | Kokkusobiv | Kokkusobiv | Kokkusobiv | Kokkusobimatud | Kokkusobiv | Kokkusobiv |
| LGPL-2.1 | Kokkusobiv | Kokkusobiv | Kokkusobiv | Kokkusobiv | Kokkusobimatud | Kokkusobimatud |
| GPL-2.0 | Kokkusobiv | Kokkusobimatud | Kokkusobiv | Kokkusobiv | Kokkusobimatud | Kokkusobimatud |
| GPL-3.0 | Kokkusobiv | Kokkusobiv | Kokkusobimatud | Kokkusobimatud | Kokkusobiv | Kokkusobiv |
| patenditud | Kokkusobiv | Kokkusobiv | Ettevaatust | Kokkusobimatud | Kokkusobimatud | Kokkusobimatud |
Kommertstarkvara puhul on kõige olulisem ühildumatus Apache-2.0 ja GPL-2.0 ühildumatud. Apache-2.0 litsentsiga teeki ei saa samas töös kombineerida GPL-2.0 litsentsiga komponendiga. Kuna paljud avatud lähtekoodiga põhikomponendid (Linuxi kerneli moodulid, mõned vanemad Java teegid) on GPL-2.0, mitte GPL-3.0 litsentsiga, tekitab see ühildumatus segatud sõltuvuspuude puhul reaalse vastavusriski.
AGPL-3.0 rida on SaaS-i jaoks kõige piiravam: põhimõtteliselt ei saa miski kommertstootes AGPL-3.0-ga puhtalt ühilduda ilma võrgu autoriõiguse kohustust käivitamata.
Litsentsipoliitika jõustamine CI/CD-s
Perioodilistest audititest sõltuv litsentsinõuetele vastavus ebaõnnestub juba kasutuselevõtu hetkel: GPL-sõltuvus, mille keegi eelmisel sprindil lisas, on olnud tootmises kolm nädalat enne, kui kvartaliaudit selle tabab. Pidev jõustamine ühendamisväravas on ainus lähenemisviis, mis takistab nõuetele mittevastavate sõltuvuste sisenemist koodibaasi.
yaml
# GitHub Actions: license compliance gate on every PR
name: License Compliance Check
on:
pull_request:
jobs:
license-audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install license checker
run: npm install -g license-checker fossa-cli
- name: Scan dependency licenses
run: |
license-checker --summary --excludePrivatePackages \
--out license-report.json
- name: Enforce license policy
run: |
# Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
FORBIDDEN=$(license-checker --failOn \
"GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
--excludePrivatePackages 2>&1 || true)
if echo "$FORBIDDEN" | grep -q "FAIL"; then
echo "Forbidden license detected in dependencies"
echo "$FORBIDDEN"
exit 1
fi
- name: Generate SBOM artifact
run: |
# Generate CycloneDX SBOM for audit trail
npx @cyclonedx/cyclonedx-npm \
--output-file sbom-$(date +%Y%m%d).json
- name: Upload SBOM as artifact
uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom-*.jsonTähelepanu: litsentsipoliitika on organisatsioonispetsiifiline. Ülaltoodud näites olev keelatud loend kajastab üldist äripoliitikat, kuid teie organisatsiooni juriidiline meeskond peab määratlema, millised litsentsid on teie konkreetse tootetüübi, levitamismudeli ja kliendilepingute puhul lubatud, ülevaatamiseks märgitud ja keelatud. Sisemises tööriistas lubatud teek võib olla kliendile levitatavas tootes keelatud.
SBOM-i genereerimise ja vormingu standardid
Tarkvara materjalide loetelu (SBOM) on struktureeritud dokument, mis muudab litsentside vastavuse auditeeritavaks, jagatavaks ja masinkontrollitavaks. Vastavusmeeskonnad saavad litsentsikohustusi kinnitada ilma käsitsi audititeta, kui SBOM need andmed esitab. Turul domineerivad kaks vormingut:
OWASP-i arendatud CycloneDX on loodud turvalisuse ja tarneahela kasutusjuhtumite jaoks. Toetab komponentide, teenuste, haavatavuste (VEX), valemite ja masinõppemudelite materjalide loetelusid. Eelistatud vorming turvalisusele keskendunud SBOM-ide jaoks ja vorming, mida nõuavad enamik tänapäevaseid SCA-tööriistade integratsioone.
SPDX, mida haldab Linux Foundation, ISO/IEC standard (ISO 5962:2021). Nõutav mõnede valitsuse hankestandardite, sealhulgas EO 14028 aspektide poolt. Keskendub pigem litsentside vastavusele kui turvalisusele, rikkalikuma litsentsiavaldiste keelega (SPDX-avaldised suudavad hõlmata keerukaid mitme litsentsiga stsenaariume: GPL-2.0-only AND MIT OR Apache-2.0).
Seadus nr 14028 blokeerib juba föderaalsete lepingute sõlmimise mitte-SBOM-tarnijatega, CRA hakkab haavatavuste aruandlust jõustama 2026. aasta septembris ja PCI DSS 4.0 on juba audiitorite käes. Te kas saadate SBOM-e või kaotate tehinguid.
Ettevõtte tarkvaratoodete puhul on mõlema formaadi loomine kulukas, arvestades sama sõltuvusanalüüsi põhjal genereerimise kulusid. Mõlema sihtrühm on erinev: turbemeeskonnad ja haavatavuste haldamise töövood kasutavad CycloneDX-i; juriidilised meeskonnad, hanke- ja regulatiivse vastavuse töövood eelistavad tavaliselt SPDX-i.
Pärandkoodibaasi probleem: pole paketihaldurit, pole manifesti
Ülalkirjeldatud sõltuvusanalüüsi tööriistad – SCA-skannerid, lukustusfailide parsijad ja SBOM-generaatorid – toimivad eeldusel, et tarkvarasõltuvusi hallatakse paketihaldurite kaudu ja deklareeritakse manifestifailides. See eeldus kehtib tänapäevaste Java, JavaScripti, Pythoni, Go ja Rusti projektide kohta. See ei kehti COBOL-i, JCL-i ja suurarvutiplatvormidele ehitatud pärandettevõtte keskkondade kohta.
Suurarvuti keskkonnas avaldub kolmanda osapoole tarkvarasõltuvus kolmel viisil, mida standardsed SCA-tööriistad ei suuda tuvastada:
Litsentseeritud sorteerimis- ja utiliiditooted. JCL-i töövoogude hulka kuuluvad utiliidiprogrammid, sortimistooted (DFSORT, SyncSort/Syncsort, nüüd tuntud kui Precisely, CA Sort), aruannete kirjutajad (SAS, EASYTRIEVE) ja andmete teisendamise tööriistad, mis on litsentseeritud kommertstarkvara oma litsentsitingimuste, hoolduslepingute ja vastavusnõuetega. Need ilmuvad JCL-is järgmiselt: PGM=SORT, PGM=IEBGENER, PGM=ICETOOL, programminimed, mitte pakettide identifikaatorid. Puudub SCA tööriist, mis loeks package.json or pom.xml leiab nad üles.
Tarnija poolt tarnitud COBOL-i käsiraamatud. Kolmandate osapoolte tarkvaramüüjad pakuvad litsentsitud tarkvarana COBOL-i käsiraamatuid. Finantstehnoloogia tarkvaramüüja, kes pakub maksete töötlemiseks COBOL-programme, võib pakkuda käsiraamatuid, mis määratlevad nende omandiõigusega kaitstud andmestruktuurid. Iga COBOL-programm, mis neid käsiraamatuid sisaldab, kasutab litsentsitud tarkvara. Litsentsikohustused on reaalsed; paketihalduri kirjet ei eksisteeri.
Litsentsitud allikatest pärit manustatud algoritmid. COBOL-süsteeme käitavad finantsasutused võivad olla otse COBOL-i lähtekoodi lisanud litsentseeritud algoritme, kindlustusmatemaatilisi arvutusrutiine, krüptograafilisi rakendusi ja numbrilise analüüsi teeke. Need võivad pärineda litsentseeritud lähtekoodist, mis kompileeriti koodibaasi ja mida ei saa paketihalduritest tuvastada.
Nende komponentide puhul on avastamismeetodiks lähtekoodi analüüs: CALL-lausete jälgimine kutsutud programmide tuvastamiseks, COPY-lausete uurimine kaasatud liikmete tuvastamiseks ja programmide nimede võrdlemine teadaolevate kolmandate osapoolte komponentide registriga. Väljund edastab sama litsentsinõuetele vastavuse töövoogu, kuid see nõuab tööriista, mis mõistab COBOL-i ja JCL-i semantikat, mitte ainult tänapäevaseid paketimanifesti vorminguid.
Auditivalmis vastavuspaketi loomine
Kui juriidiline, vastavus- või välisaudiitor nõuab litsentsile vastavuse tõendeid, on skaneerimisaruanne vajalik, kuid mitte piisav. Auditiks valmis vastavuspakett sisaldab:
- Täielik sõltuvuste inventuur, iga komponent, versioon ja litsents, sh transitiivsed sõltuvused, mis on korraldatud toote ja versiooni järgi
- Litsentsikohustuste maatriksiga litsentsikategooria kohta konkreetsed kohustused (omistamine, allika avalikustamine, muutmise teade) ja kuidas igaüks neist täidetakse
- Omistamisteadete fail, koostas kõigi viitamist nõudvate komponentide kohta juriidilised teated iga litsentsi nõutavas vormingus (NOTICE-fail Apache-2.0 jaoks, LICENSE-fail MIT jaoks jne)
- Sobimatuse analüüsdokumentatsioon, mis kinnitab, et kombineeritud tootes ei esine ühildumatuid litsentsikombinatsioone, koos õigusliku põhjendusega võimalike piirjuhtumite kohta
- SBOM-i artefakt, praegune CycloneDX- või SPDX-fail, allkirjastatud ja ajatempliga, hõlmates kõiki ulatusse kuuluvaid komponente
- Poliitika dokumentatsioon, organisatsiooni kirjalik avatud lähtekoodiga litsentsipoliitika, sealhulgas uute litsentside kinnitamise protsess
- Kinnitusdokumendid, iga litsentsi puhul, mis enne lisamist vajab juriidilist läbivaatamist, dokumenteeritud heakskiit ja äriline põhjendus
- Paranduste ajalugu, dokumentatsioon kõigi varem tuvastatud rikkumiste ja nende lahendamiseks võetud meetmete kohta
Täpsemalt ühinemiste ja omandamiste hoolsuskohustuse kohta: omandajad taotlevad seda paketti üha enam osana tehnilisest hoolsuskohustusest. Puhas vastavuspakett ilma lahendamata rikkumisteta kiirendab hoolsuskohustuse protsessi. Pakett, mis paljastab lahendamata GPL-rikkumised patenteeritud tootes, toob tavaliselt kaasa kas hinnakorrektsiooni, deponeerimisnõuded või parandusmeetmed tehingu lõpetamise tingimusena, mis kõik on kallimad kui vastavusprogramm, mis oleks neid ära hoidnud.
Kuidas SMART TS XL Toetab litsentside vastavust ettevõtte koodibaasidele
SMART TS XL'S rakenduse sõltuvuste kaardistamine pakub ettevõtte koodibaasidele struktuurilise sõltuvuse analüüsi kihti, eriti pärandkeskkonnas, kus standardsed SCA tööriistad oma piirini jõuavad.
Suurarvutikeskkondade puhul tuvastab sõltuvuskaart iga programmi, mida kutsub iga teine programm (tuues esile JCL-i ja COBOL-i manustatud kolmandate osapoolte utiliidikõned), iga programmi poolt kaasatud koopiaraamatu (tuues esile tarnija pakutavate koopiaraamatute sõltuvused) ja iga andmestiku, millele iga programm juurde pääseb (tuues esile litsentsitud andmebaasitoodete andmekihi sõltuvused). See analüüs loob komponentide inventuuri, mis on litsentsi vastavuse auditeerimise eeltingimuseks keskkondades, kus paketihaldur puudub.
Staatilise koodi analüüsimise võimalus tuvastab konkreetsete kolmandate osapoolte komponentidega seotud koodimustrid: patenteeritud API-kutseallkirjad, müüjaspetsiifilised andmestruktuuri konventsioonid ja kohandatud COBOL-allikasse manustatud litsentseeritud algoritmide implementatsioonid. Need leiud täiendavad manifestipõhist inventuuri kooditaseme sõltuvustega, milleni manifesti skannimine ei pääse.
Mõjuanalüüsi võimalus muudab litsentsipoliitika muudatused teostatavaks: kui komponendi litsents muutub, sõltuvus litsentsib MIT-lt AGPL-3.0-le üle või müüja muudab oma tingimusi, tuvastab mõjuanalüüs kõik portfellis olevad programmid , mis sellest komponendist sõltuvad, kas otseselt või transiitiivselt. See teisendab litsentsimuutuse sündmuse tundmatust riskist määratletud parandusmeetmete ulatuseks.
Ettevõtte otsinguvõimalus muudab sõltuvuste inventuuri vastavusnõuete täitmiseks päringuliseks: leia sekunditega iga programm, mis kutsub esile konkreetse utiliidi, iga käsiraamat, mis sisaldab konkreetset tarnija tarnitud komponenti, iga programm, mis sõltub konkreetsest litsentsitud komponendist, kogu pärandportfellist. See otsinguvõimalus on praktiline tööriist teisipäevahommikuste ühinemiste ja omandamiste audititaotluste jaoks: päring, mitte käsitsi läbivaatamine.
Organisatsioonidele, kes loovad terviklikku SBOM-katvust, mis hõlmab nii kaasaegseid kui ka vanemaid süsteeme, SMART TS XL pakub pärandkomponentide inventuuri, mida tavalised SBOM-generaatorid ei suuda toota, täiendades tänapäevase virna jaoks selliseid tööriistu nagu Syft, FOSSA ja Dependency-Track.
Audit, mis ei tohiks kunagi üllatusena tulla
Litsentsinõuetele vastavuse audit on üks väheseid regulatiivseid valdkondi, kus nõuete rikkumise karistuse avastavad sageli mitte regulaator, vaid äripartner, omandaja, kliendi juristmeeskond või turustaja, kes loeb litsentsitingimusi ja küsib vastavustõendeid. Selle avastamise hind ulatub ebamugavast eksistentsiaalseni, olenevalt rikkumise raskusastmest ja tehingu etapist.
Sõltuvusanalüüsi programm, mis hoiab ära selle üllatusliku avastamise, ei ole kallis võrreldes riskiga, mida see maandab. See nõuab tarkvara, iga komponendi, iga transitiivse sõltuvuse, iga tarnija koodijupi, iga pärandutiliidi tundmist ning igaühe kontrollimist organisatsiooni litsentsipoliitika suhtes pidevalt, mitte perioodiliselt. Tööriistad on olemas. Standardid (SBOM, SPDX, CycloneDX) on olemas. Regulatiivne mandaat (EO 14028, CRA, PCI-DSS 4.0) on olemas. Ainus puuduv osa enamiku organisatsioonide jaoks on distsipliin käsitleda sõltuvusanalüüsi infrastruktuurina, mitte auditiharjutusena.
Teisipäeva hommik, mis algab tulekahjuõppuse asemel aruandega, on see teisipäeva hommik, mille sõltuvusanalüüsi infrastruktuur võimalikuks tegi.
