How to use driver-related CLIs for driver creation in a highly restricted Azure DevOps Pipeline environment?

Question

I'm porting some Jenkins builds into a highly restricted ADO Pipeline environment. When making some CAT files the MakeCAT utility was being used and when verifying INF files the InfVerif tool was being used. In our company's highly restricted ADO environment I can't seem to access tools directly anywhere outside the build directories for the job and was told there wouldn't be a compromise on that.

The best I could figure was directly downloading the files and their dependencies as Secure Files and kluding together tool directories for each required tool. That is a dirty hack and skates around legal grey-areas with tool licensing, so I'm not a fan of that approach. But that said I used DUMPBIN /IMPORTS to see which each respective tool required:

InfVerif.exe:

    msvcrt.dll
    ntdll.dll
    api-ms-win-core-libraryloader-l1-1-0.dll
    KERNEL32.dll
    VERSION.dll
    ADVAPI32.dll

MakeCAT.exe:

    msvcrt.dll
    KERNEL32.dll
    WINTRUST.dll
    USER32.dll

When it comes to creating drivers and driver-related files what are we expected to utilize in ADO Pipelines with these kinds of restrictions? I don't mind using alternative tooling so long as it accomplishes the same exact goals.

ps: I went ahead and copied all the DLLs in each tool's directory and played "delete DLLs until this tool starts to break," to narrow down what was actually needed to be packaged on a local system. InfVerif needed no additional DLLs and MakeCAT only needed wintrust.dll added. Mind you this was constrained to our own usage of each tool and your usage may differ from ours and require additional dependencies to package.

Answer 1

Generally the point of build agents is that running jobs utilise the capabilities of the agent to create the build.

It would be quite obscure to ask developers to self-package every single dependency into the pipeline and kludge together executables and dll's for common SDK tools.

Presumably these build agents have stuff like .NET SDK's installed for the builds to utilise. This is no different. You should ask the team managing the build agents to install the relevant SDKs and ensure the paths are configured and available for the build agent.

(e.g echo PATH inside build agent should include directories where those SDK's are installed)

Asking developers to check in packaged exe's and dlls is more of a security risk. Who knows where they come from and if they are safe?