I listened to an episode of Software Engineering Radio about third-party browser script security. Most of the discussion focused on frontend security practices, but as a backend engineer one takeaway stood out to me: the importance of securing the code supply chain.

What is the code supply chain?

The code supply chain includes your libraries, their versions, and the sources they come from, whether they are external dependencies or in-house packages.

One point I especially agreed with was the emphasis on signing in-house libraries with your domain, or your company domain. That reduces the risk of someone impersonating your organization and publishing compromised versions of internal packages.

How can the supply chain be violated?

It can be violated in very simple ways.

You may restore a package from the wrong source. Someone may publish a bad version of a package you already trust. An internal package name may exist publicly and get pulled by mistake. Or a developer machine or build pipeline may download libraries from somewhere that was never approved in the first place.

The dangerous part is that all of this can happen before the application even runs. Once the wrong library gets restored during development or CI, the problem is already inside the build.

How do you secure your supply chain?

One DevSecOps practice I have implemented before is creating an internal inventory feed in Azure DevOps that contains only libraries and versions that have already been scanned and approved as secure. That means the codebase pulls and updates libraries only from this controlled feed.

For .NET projects, I have used dotnet list package --vulnerable together with Sonatype tooling to scan libraries. For in-house libraries, we also sign them for an additional layer of security.

Practical guardrails

To make this approach effective, the controls need to exist across local development and CI:

  • Development machines should fetch libraries only from the custom approved feed, not from arbitrary external sources.
  • Code repositories should contain only source code and dependency references with specific versions. Package binaries should not be committed into the repository.
  • CI builds should restore packages only from the approved feed. If someone introduces a dependency outside that feed, the build should fail immediately.

These rules move dependency trust from individual developer decisions into a controlled engineering process.

Why this matters

Third-party browser script attacks are a reminder that trust in dependencies is often broader than teams think. Even if the original incident is frontend-focused, the same mindset applies to backend systems and internal delivery pipelines: know what you consume, verify where it comes from, and make unauthorized dependency paths fail by default.

If you want to go deeper into the original discussion, the episode is worth a listen: