Een bedrijf gebruikt een alleen intern gebruikte bibliotheek met de naam acme-utils, die in zijn interne pakketrepository (private registry) staat. Een aanvaller registreerde in een openbare pakketrepository een pakket met dezelfde naam, acme-utils, en een hoger versienummer, en het bleek dat de interne buildomgeving, afhankelijk van de buildinstellingen, het pakket van de aanvaller kon binnenhalen. Welke tegenmaatregel tegen deze „dependency confusion” is het meest passend?

Antwoord: B. Alleen intern gebruikte pakketten in een namespace plaatsen die de organisatie beheert, instellen dat die namespace alleen uit de interne repository wordt opgehaald, en versies en hashwaarden vastleggen met een lockbestand

Dependency confusion is een vorm van aanval op de toeleveringsketen van software. Sommige pakketbeheerders raadplegen meerdere repository's en kiezen, afhankelijk van hun instellingen, het hogere versienummer als dezelfde naam voorkomt; aanvallers misbruiken dat om een kwaadaardig pakket met dezelfde naam als een intern pakket te laten binnenhalen. De tegenmaatregel is voor interne pakketten een namespace (scope) te gebruiken die de organisatie beheert, die namespace alleen aan de interne repository te koppelen en expliciet aan te geven uit welke repository elk pakket wordt opgehaald. Door bovendien de versies en hashwaarden van de afhankelijkheden met een lockbestand vast te leggen, wordt voorkomen dat ze ongemerkt door iets anders worden vervangen. Ook de namespace van de organisatie als eerste in de openbare repository registreren, helpt om imitatie te voorkomen.