Toxic Dependencies

Toxic dependencies er et begreb inden for softwareudvikling og sikkerhed, der dækker over tredjepartsafhængigheder, som udgør en langsigtet risiko for systemets sikkerhed, stabilitet, performance eller forretningsmæssige bæredygtighed. Problemet opstår, når afhængigheder introduceres uden klar kontrol, ejerskab eller exit-strategi.

Hvad er Toxic Dependencies?

En toxic dependency er en ekstern komponent (library, framework, SDK, SaaS eller API), som applikationen er afhængig af, men som:

• ikke længere vedligeholdes,

• udvikles uden sikkerhedsfokus,

• ændrer vilkår uforudsigeligt,

• eller er for dybt indlejret til nem udskiftning.

Afhængigheden fungerer teknisk, men skaber strategisk gæld.

Hvordan opstår problemet?

Typiske årsager:

• Hurtige valg under tidspres (“vi fik det til at virke”)

• Overafhængighed af open source uden ejerskab

• Manglende version pinning

• Manglende vendor risk management

• Frameworks eller packages brugt uden reelt behov

• “Transitive dependencies” uden overblik

Problemet akkumulerer over tid og opdages ofte først, når det er for sent.

Hvorfor er Toxic Dependencies alvorligt?

Sikkerhed

• Kendte CVE’er uden patches

• Supply chain-angreb

• Ondsindede opdateringer eller takeover af packages

Stabilitet og drift

• Breaking changes uden varsel

• Uforudsigelig performance

• Deprecated API’er der lukker ned

Forretning

• Vendor lock-in

• Prisændringer og licensændringer

• Compliance- og juridiske risici

Udviklingshastighed

• Refaktorering bliver dyr

• Releases bremses af eksterne beslutninger

• Teams bliver bange for at opdatere

Typiske eksempler

• Open source libraries uden aktive maintainers

• SaaS-API’er uden SLA eller roadmap

• Framework-plugins der “ejer” forretningslogik

• Auth- eller betalingsløsninger uden fallback

• Dependencies med dybe hooks i core flows

Best Practice – forebyggelse

Dependency governance

• Kend hvorfor hver dependency findes

• Dokumentér ejerskab og ansvar

• Kræv vedligeholdelsesstatus og community-aktivitet

Teknisk isolation

• Indkapsl dependencies bag interfaces

• Undgå direkte coupling til framework-specifikke features

• Brug adapters og facades

Versionskontrol

• Pin versions eksplicit

• Undgå auto-opdateringer i produktion

• Test opgraderinger isoleret

Exit-strategi

• Antag at alle dependencies kan forsvinde

• Overvej “cost to replace” før adoption

• Undgå dependencies i kerneforretning, hvis muligt

Hvad beskytter ikke mod Toxic Dependencies?

• “Det er et populært library”

• “Det har mange GitHub stars”

• “Det er open source”

• “Vi opdaterer senere”

Popularitet er ikke governance.

Forretnings- og udviklingsmæssig betydning

Langsigtet risiko

Toxic dependencies er ofte skjult tech debt, der først rammer under vækst eller krise.

Skalerbarhed

Jo flere afhængigheder, desto mere uforudsigelig bliver roadmap og leverance.

Due diligence

Ved opkøb, investering eller compliance audits er dependencies et fast fokuspunkt.

Udfordringer og løsninger

Udfordring: Mange transitive dependencies

Løsning: Dependency scanning og SBOM (Software Bill of Materials)

Udfordring: Dybt integreret SaaS

Løsning: Abstrahér integrationen og planlæg alternativ

Udfordring: Manglende overblik

Løsning: Regelmæssige dependency reviews og audits

Opsummering

Toxic dependencies er sjældent et teknisk problem i isolation.

Det er et ledelses- og arkitekturproblem.

Hvis en dependency:

• ikke kan fjernes,

• ikke kan opdateres,

• eller ikke kan forklares,

så ejer den allerede dit system.

Professionel softwareudvikling kræver bevidst afhængighedsstyring.