Licensoverholdelsesrevision via afhængighedsanalyse

IN-COM September 7, 2026 Overholdelse, Data, Enterprise modernisering, Effektanalyse, Ældre systemer

Anmodningen om due diligence i forbindelse med fusioner og opkøb ankommer tirsdag morgen: en komplet rapport om overholdelse af open source-licenser for al software, der skal indsendes fredag. Det juridiske team har tre dage til at udarbejde en oversigt over alle open source-komponenter i hele produktets kodebase, alle gældende licenser, og alle forpligtelser, der skal opfyldes før opkøberens juridiske gennemgang. For organisationer, der behandler overholdelse af licenser som en periodisk manuel gennemgangsøvelse, begynder en af de dyreste brandøvelser inden for virksomhedssoftware samme tirsdag morgen. For organisationer med en moden infrastruktur til afhængighedsanalyse begynder det med at køre en rapport.

Software samles for det meste, ikke skrives. Black Duck 2026 OSSRA-rapporten viste, at 98 % af kommercielle kodebaser indeholder open source-komponenter, 87 % har mindst én kendt sårbarhed, og det gennemsnitlige antal sårbarheder pr. kodebase er mere end fordoblet år-til-år. Licensoverholdelsesrevision er den disciplin, der besvarer et andet, men relateret spørgsmål: ikke kun hvilke komponenter, der indeholder sårbarheder, men hvilke komponenter pålægger juridiske forpligtelser for, hvordan softwaren kan distribueres, ændres eller kommercialiseres. En overset GPL-2.0-afhængighed i et proprietært kommercielt produkt er ikke en sikkerhedshændelse. Det er en licenskrænkelse, der kan kræve offentliggørelse af kildekoden, juridisk forlig eller tilbagetrækning af produktet.

Fundamentet for licensoverholdelsesrevision er afhængighedsanalyse, den systematiske identifikation af hver softwarekomponent, som en kodebase direkte eller indirekte afhænger af, med fuldstændig tildeling af den licens, der styrer hver komponent. Afhængighedsanalyse er ikke en scanning af pakkemanifestet. Det er en fuldstændig strukturel undersøgelse af, hvad softwaren rent faktisk inkluderer på byggetidspunktet og under kørsel, uanset om disse inkluderinger er deklarerede, transitive, leverede eller implicitte.

Ændring af licens? Kend konsekvenserne.

SMART TS XL producerer komponentinventaret til mainframe-software, som standard SBOM-generatorer ikke kan nå.

FÅ MERE AT VIDE…

Indholdsfortegnelse

Hvorfor afhængighedsanalyse er fundamentet

Licensoverholdelse er et afhængighedsproblem, før det er et juridisk problem. Man kan ikke vurdere licensforpligtelserne for et softwareprodukt uden først at vide, hvad produktet er lavet af – hver komponent, hvert bibliotek, hvert kopieret uddrag. Licensanalysen er efterfølgende afhængighedsopgørelsen. Hvis opgørelsen bliver forkert, er licensanalysen bygget på et ufuldstændigt billede.

Tre spørgsmål, som afhængighedsanalyse skal besvare for at sikre overholdelse af licenser:

Hvilke komponenter er inkluderet? Ikke kun de direkte afhængigheder, der er angivet i package.json or pom.xml, men hver eneste transitive afhængighed, de bringer ind, hvert leverandørbibliotek, der kopieres til kildetræet, hver statisk linket komponent, der kompileres til den binære fil, og hvert dynamisk indlæst modul, der kaldes under kørsel. En god SCA-motor krydsrefererer disse komponenter med sårbarhedsdatabaser som NVD'en, kontrollerer licensmetadata og markerer kendte udnyttelser eller juridiske risici, før de påvirker din leveringspipeline. Den samme motor skal også være nøjagtig på lagerniveau, dvs. hvad der rent faktisk er i softwaren, før licensanalysen kan stoles på.

Under hvilke licenser er de underlagt? En komponent kan have en enkelt deklareret licens, en dobbeltlicens med muligheder, flere licenser, der gælder for forskellige filer, eller en licens, der er ændret på tværs af versioner. FOSSAs licensdetektionsmotor hævder 99.8% nøjagtighed, hvilket er vigtigt, når dit juridiske team skal verificere open source-forpligtelser sammen med sikkerhedsopgørelsen. Licensidentifikation på komponentniveau er nødvendig, men utilstrækkelig. Identifikation på fil- eller kodestykkeniveau er påkrævet for komponenter, hvor forskellige filer har forskellige licenser.

Hvilke forpligtelser pålægger disse licenser? En permissiv licens (MIT, Apache-2.0) pålægger krav om kreditering. En svag copyleft-licens (LGPL) pålægger forskellige forpligtelser afhængigt af, om komponenten er linket dynamisk eller statisk. En stærk copyleft-licens (GPL-2.0, GPL-3.0) kan kræve distribution af kildekoden til hele det kombinerede værk. Forståelse af forpligtelsen kræver forståelse af licensvilkårene, ikke kun licens-id'et.

De fire typer afhængigheder, der skaber licenseksponering

Ikke alle afhængigheder er lige synlige eller lige styret af eksisterende værktøjer. Licenseksponering kommer fra fire forskellige afhængighedstyper, der hver især kræver forskellige registreringsmetoder:

1. Pakkehåndteringsafhængigheder (deklarerede og transitive)

Det mest synlige lag: afhængigheder deklareret i manifestfiler (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) og de transitive afhængigheder, de løser under byggeprocessen. Pakkehåndteringsafhængigheder er den bedst dækkede kategori, SCA-værktøjer scanner manifester, låser filer og byggeartefakter for at opregne dem.

Den afgørende forskel er mellem direkte og transitiv. En direkte afhængighed er den, udvikleren har valgt. En transitiv afhængighed er det, den direkte afhængighed kræver. En udvikler, der tilføjer en enkelt react-data-grid En pakke til et Node.js-projekt importerer muligvis snesevis af transitive afhængigheder, hver med sin egen licens. Udvikleren valgte ikke disse licenser. De findes alligevel i afhængighedstræet.

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.

Den transitive licensfælde: Licensrisikoen ligger ikke i det, du har deklareret. Den ligger i det, dine afhængigheder har deklareret, og det, deres afhængigheder har deklareret. Et rent direkte afhængighedstræ med permissive licenser kan skjule en GPL-licenseret transitiv afhængighed tre niveauer dyb, der pålægger hele distributionen copyright-forpligtelser.

2. Leveret og kopieret kildekode

Kildekode fra eksterne projekter kopieret direkte ind i arkivet, et mønster der er almindeligt i C/C++-projekter, Go-projekter uden moduler og ældre kodebaser. Leverandørkode vises ikke i pakkehåndteringsmanifester, fordi den blev tilføjet via kopier-indsæt i stedet for via en afhængighedshåndtering.

SCANOSS' scanning på kodesnippetniveau går langt ud over manifestbaseret detektion og matcher kildekodefragmenter med over 100 millioner open source-filer i OSSKB. Scanning på kodesnippetniveau er påkrævet for at identificere leverandørkode og kopierede funktioner, tilgange der ikke erklærer nogen manifestafhængighed, men har fulde licensforpligtelser, som om komponenten eksplicit var inkluderet.

En leverandørstyret hjælpefunktion kopieret fra et Stack Overflow-svar, der stammer fra GPL-licenseret kode, har den samme copyleft-forpligtelse som en direkte GPL-afhængighed, men den vises ingen steder i pakkemanifestet, låsefilen eller nogen automatiseret scanning, der kun læser deklarerede afhængigheder.

3. Statisk forbundne biblioteker

Biblioteker kompileres direkte ind i applikationens binære fil under byggeprocessen. I modsætning til dynamisk linkede biblioteker, der findes som separate filer under kørsel, er statisk linkede biblioteker integreret i den eksekverbare fil. De er ikke synlige i pakkehåndteringsmanifesterne, de vises i byggekonfigurationer (Makefile, CMakeLists.txt, linker-scripts) og i selve den kompilerede binære fil.

For LGPL-licenserede biblioteker er det specifikt forskellen mellem statisk og dynamisk linkning, der bestemmer licensforpligtelsen. LGPL tillader dynamisk linkning uden copyleft-udbredelse; statisk linkning kan udløse copyleft-krav på det kombinerede værk. Et binært analyseværktøj, der undersøger det kompilerede artefakt, snarere end kun kildemanifestet, er påkrævet for at identificere statisk linkede komponenter og deres licenser.

4. Køretidsindlæste afhængigheder

Biblioteker indlæses dynamisk under kørsel via plugin-arkitekturer, sen binding eller integration af scripting-motorer. Disse afhængigheder kan muligvis ikke løses udelukkende fra kildekodeanalyse, de afhænger af kørselsmiljøet, konfigurationen og udførelsesstien. Databasedrivere indlæst via refleksion, parser-plugins opdaget via service loader-mekanismer og scripting-udvidelser indlæst fra filsystemstier ved opstart er alle kørselsafhængigheder med potentielle licensimplikationer.

Licensrisikokategorier og deres forpligtelser

Open source-licenser falder inden for et spektrum fra permissiv til restriktiv. Forståelse af, hvor hver licens placeres på dette spektrum, bestemmer den compliance-forpligtelse, den skaber:

Tilladte licenser (MIT, Apache-2.0, BSD-2-klausul, BSD-3-klausul, ISC)

Forpligtelse: Kreditering, inkludering af licenstekst og copyright-meddelelse i distributioner. Kildekodeoplysning er ikke påkrævet. Kommerciel brug tilladt uden begrænsning. Integration i proprietære produkter tilladt.

Risikoniveau for kommerciel software: Lavt. Attribution er let at opfylde automatisk.

Svage copyright-licenser (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)

Forpligtelse: Kreditering plus ændringer til den licenserede komponent skal deles. Specifikt for LGPL: dynamisk linkning opfylder generelt licensen uden at udløse copyright på den kaldende kode; statisk linkning gør muligvis ikke.

Risikoniveau for kommerciel software: Mellem. Afhænger af linkmetoden. Dynamisk linkning er normalt sikkert; statisk linkning kræver omhyggelig juridisk gennemgang.

Stærke copyright-licenser (GPL-2.0, GPL-3.0, AGPL-3.0)

Forpligtelse: Kreditering plus hele det samlede værk, der inkluderer GPL-komponenten, skal gøres tilgængeligt under GPL-vilkår (kildekodeoplysning). AGPL udvider dette til software, der tilgås over et netværk.

Risikoniveau for kommerciel software: Højt. En GPL-licenseret komponent, der er statisk linket til eller afledt af et proprietært kommercielt produkt, kan kræve offentliggørelse af den proprietære kildekode. Dette er den licensrisiko, der genererer de største retsforlig.

Netværksophavsret (AGPL-3.0)

Forpligtelse: Alle forpligtelser i henhold til GPL-3.0, plus: brugere, der interagerer med softwaren via et netværk, anses for at modtage softwaren, hvilket udløser forpligtelsen til kildeoplysning, selv for SaaS-produkter, der aldrig distribuerer binære filer.

Risikoniveau for SaaS-produkter: Meget højt. AGPL er specifikt designet til at lukke "SaaS-smuthullet" i GPL. Et kommercielt SaaS-produkt, der indeholder en AGPL-komponent, skal oplyse sin kilde til enhver bruger, der interagerer med det over et netværk.

Proprietære og kommercielle licenser

Forpligtelse: Defineret af licensaftalen, varierer fra "ingen videredistribution" til "royalty pr. enhed" til "virksomhedslicens". Disse er ikke open source, men vises i afhængighedstræer, når kommercielle komponenter anvendes.

Risikoniveau: Varierer afhængigt af vilkårene. Opdages ofte under due diligence i forbindelse med fusioner og opkøb, når licensgebyrforpligtelserne for de opkøbte produkter opregnes.

Licenskompatibilitet: Matrixen der betyder noget

Når komponenter med forskellige licenser kombineres i et enkelt softwareprodukt, skal licenserne være kompatible. Ukompatible licenskombinationer skaber juridisk risiko, der ikke kan løses ved udelukkende kreditering, og selve kombinationen kan krænke en eller begge licenser.

Kombineret med	MIT	Apache-2.0	LGPL-2.1	GPL-2.0	GPL-3.0	PLFA-3.0
MIT	Kompatibel	Kompatibel	Kompatibel	Kompatibel	Kompatibel	Kompatibel
Apache-2.0	Kompatibel	Kompatibel	Kompatibel	Uforenelig	Kompatibel	Kompatibel
LGPL-2.1	Kompatibel	Kompatibel	Kompatibel	Kompatibel	Uforenelig	Uforenelig
GPL-2.0	Kompatibel	Uforenelig	Kompatibel	Kompatibel	Uforenelig	Uforenelig
GPL-3.0	Kompatibel	Kompatibel	Uforenelig	Uforenelig	Kompatibel	Kompatibel
Proprietary	Kompatibel	Kompatibel	Forsigtighed	Uforenelig	Uforenelig	Uforenelig

Den mest betydningsfulde inkompatibilitet for kommerciel software: Apache-2.0 og GPL-2.0 er inkompatible. Et Apache-2.0-licenseret bibliotek kan ikke kombineres med en GPL-2.0-licenseret komponent i det samme værk. Da mange grundlæggende open source-komponenter (Linux-kernemoduler, nogle ældre Java-biblioteker) er GPL-2.0 snarere end GPL-3.0, skaber denne inkompatibilitet en reel compliance-risiko i blandede afhængighedstræer.

AGPL-3.0-rækken er den mest restriktive for SaaS: stort set intet kombineres rent med AGPL-3.0 i et kommercielt produkt uden at udløse netværkets copyright-forpligtelse.

Håndhævelse af licenspolitik i CI/CD

Licensoverholdelse, der afhænger af periodiske revisioner, fejler i introduktionsøjeblikket: GPL-afhængigheden, som nogen tilføjede i sidste sprint, har været i produktion i tre uger, før den kvartalsvise revision fanger den. Kontinuerlig håndhævelse ved merge-gaten er den eneste tilgang, der forhindrer ikke-kompatible afhængigheder i at komme ind i kodebasen.

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-*.json

Pas på: Licenspolitikken er organisationsspecifik. Listen over forbudte licenser i eksemplet ovenfor afspejler en fælles kommerciel politik, men din organisations juridiske team skal definere, hvilke licenser der er tilladte, markeret til gennemgang og forbudte for din specifikke produkttype, distributionsmodel og kundeaftaler. Et bibliotek, der er tilladt i et internt værktøj, kan være forbudt i et kundedistribueret produkt.

SBOM-generering og formatstandarder

En Software Bill of Materials (SBOM) er den strukturerede artefakt, der gør licensoverholdelse auditerbar, delbar og maskinverificerbar. Compliance-teams kan bekræfte licensforpligtelser uden manuelle revisioner, når en SBOM leverer disse data. To formater dominerer markedet:

CycloneDX , udviklet af OWASP, designet til sikkerheds- og forsyningskæde-brugsscenarier. Understøtter komponenter, tjenester, sårbarheder (VEX), formler og maskinlæringsmodeller for styklister. Det foretrukne format til sikkerhedsfokuserede SBOM'er og det format, der kræves af de fleste moderne SCA-værktøjsintegrationer.

SPDX, vedligeholdt af Linux Foundation, ISO/IEC-standarden (ISO 5962:2021). Krævet af nogle offentlige indkøbsstandarder, herunder aspekter af EO 14028. Mere fokuseret på licensoverholdelse end sikkerhed, med et rigere licensudtrykssprog (SPDX-udtryk kan indfange komplekse scenarier med flere licenser: GPL-2.0-only AND MIT OR Apache-2.0).

EO 14028 blokerer allerede ikke-SBOM-leverandører fra føderale kontrakter, CRA begynder at håndhæve sårbarhedsrapportering i september 2026, og PCI DSS 4.0 er allerede i revisorernes hænder. Enten leverer I SBOM'er, eller også mister I aftaler.

For virksomhedssoftwareprodukter koster det ikke meget at producere begge formater ud over at generere fra den samme afhængighedsanalyse. Målgruppen for de to formater er forskellig: sikkerhedsteams og arbejdsgange inden for sårbarhedsstyring bruger CycloneDX; juridiske teams, indkøbs- og overholdelsesarbejdsgange foretrækker typisk SPDX.

Problemet med den ældre kodebase: Ingen pakkehåndtering, intet manifest

De ovenfor beskrevne afhængighedsanalyseværktøjer, SCA-scannere, lockfile-parsere og SBOM-generatorer, fungerer ud fra den antagelse, at softwareafhængigheder administreres via pakkehåndteringsværktøjer og deklareres i manifestfiler. Denne antagelse gælder for moderne Java-, JavaScript-, Python-, Go- og Rust-projekter. Den gælder ikke for ældre virksomhedsmiljøer bygget på COBOL-, JCL- og mainframe-platforme.

I et mainframe-miljø manifesterer afhængighed af tredjepartssoftware sig på tre måder, som standard SCA-værktøjer ikke kan registrere:

Licenserede sorterings- og brugsprodukter. JCL-jobstrømme kalder hjælpeprogrammer, sorteringsprodukter (DFSORT, SyncSort/Syncsort, nu kendt som Precisely, CA Sort), rapportforfattere (SAS, EASYTRIEVE) og datakonverteringsværktøjer, som er licenseret kommerciel software med deres egne licensvilkår, vedligeholdelseskontrakter og overholdelseskrav. Disse vises i JCL som PGM=SORT, PGM=IEBGENER, PGM=ICETOOL, programnavne, ikke pakke-id'er. Intet SCA-værktøj, der læser package.json or pom.xml vil finde dem.

Leverandørleverede COBOL-kopibøger. Tredjepartsleverandører af software leverer COBOL-kopibøger, der er licenseret software. En fintech-softwareleverandør, der leverer COBOL-programmer til betalingsbehandling, kan levere kopibøger, der definerer deres proprietære datastrukturer. Hvert COBOL-program, der inkluderer disse kopibøger, bruger licenseret software. Licensforpligtelserne er reelle; pakkehåndteringsposten findes ikke.

Indlejrede algoritmer fra licenserede kilder. Finansielle institutioner, der kører COBOL-systemer, kan have indarbejdet licenserede algoritmer, aktuarmæssige beregningsrutiner, kryptografiske implementeringer og numeriske analysebiblioteker direkte i COBOL-kildekoden. Disse kan stamme fra licenserede kilder, der blev kompileret i kodebasen og ikke kan identificeres fra pakkeadministratorer.

For disse komponenter er opdagelsesmetoden kildekodeanalyse: sporing af CALL-sætninger for at identificere kaldte programmer, undersøgelse af COPY-sætninger for at identificere inkluderede medlemmer og matchning af programnavne mod et register over kendte tredjepartskomponenter. Outputtet føder den samme licensoverholdelsesworkflow, men det kræver et værktøj, der forstår COBOL- og JCL-semantik, ikke kun moderne pakkemanifestformater.

Opbygning af den revisionsklare compliance-pakke

Når juridisk, compliance eller en ekstern revisor anmoder om dokumentation for overholdelse af licenser, er en scanningsrapport nødvendig, men ikke tilstrækkelig. Den revisionsklare compliance-pakke indeholder:

Komplet afhængighedsopgørelse, hver komponent, version og licens, inklusive transitive afhængigheder, organiseret efter produkt og version
Licensforpligtelsesmatrix, for hver licenskategori, de specifikke forpligtelser (kreditering, kildeangivelse, ændringsmeddelelse) og hvordan hver enkelt opfyldes
Fil med tilskrivningsmeddelelser, samlet juridiske meddelelser for alle komponenter, der kræver kreditering, i det format, der kræves af hver licens (NOTICE-fil for Apache-2.0, LICENSE-fil for MIT osv.)
Uforenelighedsanalysedokumentation for, at der ikke er nogen uforenelige licenskombinationer til stede i det kombinerede produkt, med juridisk begrundelse for eventuelle grænsetilfælde
SBOM-artefakt, aktuel CycloneDX- eller SPDX-fil, underskrevet og tidsstemplet, der dækker alle komponenter i omfanget
Politikdokumentation, organisationens skriftlige open source-licenspolitik, herunder godkendelsesprocessen for nye licenser
Godkendelsesregistre, for enhver licens, der kræver juridisk gennemgang før optagelse, den dokumenterede godkendelse og den forretningsmæssige begrundelse
Afhjælpningshistorikdokumentation af eventuelle tidligere identificerede overtrædelser og de foranstaltninger, der er truffet for at løse dem

Specifikt for due diligence i forbindelse med fusioner og opkøb: Opkøbere anmoder i stigende grad om denne pakke som en del af den tekniske due diligence. En ren compliance-pakke uden uløste overtrædelser fremskynder diligence-processen. En pakke, der afslører uløste GPL-overtrædelser i et proprietært produkt, resulterer typisk i enten prisjustering, krav om escrow eller afhjælpning som en lukkebetingelse, som alle er dyrere end det compliance-program, der ville have forhindret dem.

Hvordan SMART TS XL Understøtter licensoverholdelse i virksomhedskodebaser

SMART TS XL's kortlægning af applikationsafhængighed leverer laget for strukturel afhængighedsanalyse til virksomhedskodebaser, især i det ældre miljø, hvor standard SCA-værktøjer når deres grænser.

For mainframe-miljøer identificerer afhængighedskortet hvert program, der kaldes af alle andre programmer (der viser tredjepartskald, der er integreret i JCL og COBOL), hver kopibog, der er inkluderet i hvert program (der viser leverandørleverede kopibogsafhængigheder), og hvert datasæt, der tilgås af hvert program (der viser datalagsafhængigheder på licenserede databaseprodukter). Denne analyse producerer den komponentinventar, der er forudsætningen for licensoverholdelsesrevision i miljøer, hvor der ikke findes en pakkehåndtering.

Funktionen til statisk kodeanalyse identificerer kodemønstre forbundet med specifikke tredjepartskomponenter: proprietære API-kaldssignaturer, leverandørspecifikke datastrukturkonventioner og licenserede algoritmeimplementeringer integreret i en brugerdefineret COBOL-kilde. Disse resultater supplerer det manifestbaserede lager med de kodeafhængigheder, som manifestscanning ikke kan nå.

Funktionen til konsekvensanalyse gør det muligt at handle på ændringer i licenspolitikken: Hvis en komponents licens ændres, en afhængighed genlicenseres fra MIT til AGPL-3.0, eller en leverandør ændrer sine vilkår, identificerer konsekvensanalysen hvert program i porteføljen, der afhænger af den pågældende komponent, enten direkte eller transitivt. Dette konverterer en licensændringshændelse fra en ukendt risiko til et defineret afhjælpningsområde.

Virksomhedssøgningsfunktionen gør det muligt at forespørge på afhængighedsopgørelsen med henblik på overholdelse af regler og standarder: find alle programmer, der kalder et specifikt værktøj, alle kopibøger, der inkluderer et specifikt leverandørleveret medlem, alle programmer, der afhænger af en specifik licenseret komponent, på få sekunder på tværs af hele den ældre portefølje. Denne søgefunktion er det praktiske værktøj til anmodningen om M&A-revision tirsdag morgen: en forespørgsel snarere end en manuel gennemgang.

For organisationer, der opbygger omfattende SBOM-dækning, der spænder over både moderne og ældre systemer, SMART TS XL leverer den ældre komponentinventar, som standard SBOM-generatorer ikke kan producere, og supplerer værktøjer som Syft, FOSSA og Dependency-Track til den moderne stak.

Revisionen der aldrig burde komme som en overraskelse

Revision af licensoverholdelse er en af de få regulatoriske discipliner, hvor straffen for manglende overholdelse ofte opdages, ikke af en regulator, men af en forretningspartner, en indløser, en kundes juridiske team eller en distributør, der læser licensvilkårene og beder om bevis for overholdelse. Omkostningerne ved denne opdagelse varierer fra akavede til eksistentielle afhængigt af overtrædelsens alvor og transaktionens stadie.

Programmet til afhængighedsanalyse, der forhindrer denne opdagelse i at komme som en overraskelse, er ikke dyrt i forhold til den risiko, det mindsker. Det kræver, at man kender til softwaren, hver komponent, hver transitiv afhængighed, hvert leverandørudgivet kodestykke, hvert ældre værktøj, og at man kontrollerer hvert program løbende i forhold til organisationens licenspolitik i stedet for periodisk. Værktøjerne findes. Standarderne (SBOM, SPDX, CycloneDX) findes. Det regulatoriske mandat (EO 14028, CRA, PCI-DSS 4.0) findes. Den eneste manglende brik for de fleste organisationer er disciplinen til at behandle afhængighedsanalyse som infrastruktur snarere end som en revisionsøvelse.

Den tirsdag morgen, der begynder med en rapport i stedet for en brandøvelse, er den tirsdag morgen, som infrastrukturen for afhængighedsanalyse muliggjorde.