First-Party Dependency Security: Your Internal Supply Chain

When security teams talk about the software supply chain, they usually mean open source: the npm packages, PyPI wheels and Maven artifacts that someone outside the company wrote. That is where most scanning effort goes, because that is where the public advisories are.

But most organizations run a second supply chain that gets far less attention, and first-party dependency security is how you account for it. It is made of the packages your own teams publish: the shared authentication client, the internal logging library, the common data models, the platform SDK every service imports. They live in private registries like AWS CodeArtifact, Artifactory, Nexus, GitHub Packages or GCP Artifact Registry, and they are consumed by dozens or hundreds of services.

First-party dependency security is the practice of treating those internal packages as the supply chain they are. This post covers why internal packages are a blind spot, the specific risks they carry, and what it takes to see them properly.

Why first-party packages are a blind spot

Traditional SCA tools look at a manifest, resolve the dependencies, and match each one against a vulnerability database of public advisories. That works for open source. It fails for internal packages in three ways.

No public advisories

Nobody files a CVE against acme-auth-client 2.3.1. If that library pins a vulnerable version of an HTTP client, or bundles one, no advisory database will ever say so. The vulnerability is real, but it lives one layer down, inside a package the scanner treats as an opaque name.

No clear owner in the tooling

When a finding appears in a service that imports an internal library, it is attributed to the consuming service. The team that owns the service did not write the library and often cannot change it. The team that owns the library may never see the finding. The fix stalls in the gap between them.

Invisible fan-out

A single internal package with a vulnerable transitive dependency can put the same finding into every service that consumes it. Without knowing that the library is first-party, those findings look like dozens of unrelated problems instead of one problem with one fix in one repository.

The risks internal packages actually carry

Inherited open-source vulnerabilities

The most common issue is also the most boring. An internal library depends on open-source packages, those packages accumulate vulnerabilities, and every consumer inherits them. Fixing it in each consumer is slow and fragile. Fixing it once, in the library, and publishing a new version is the real remediation.

Secrets baked into published artifacts

Internal packages are built by internal pipelines, and internal pipelines are where test credentials, service tokens and config files end up in artifacts by accident. A secret in a published package is exposed to everyone who can pull from the registry, which is often the whole company.

Policy drift

Your license policy, your approved-version policy and your minimum-age rules apply to open source. Do they apply to what your internal libraries pull in? Usually nobody checks, so an internal package becomes a way for an unapproved dependency to enter a service that would have blocked it directly.

Dependency confusion

When an internal package name also exists, or can be registered, on a public registry, a misconfigured package manager may resolve the public one. Alex Birsan's 2021 research on dependency confusion showed how widely this worked against large companies. The defenses are package-manager configuration: scoped names, pinned sources, and source mapping such as NuGet package source mapping or npm scopes tied to your registry.

What first-party dependency security requires

Seeing internal packages properly takes more than adding a registry to a scanner.

1. Know which packages are yours. Every dependency needs a classification: first-party or third-party, direct or transitive, and which registry served it. Without that, internal packages are just names.
2. Analyze the published artifact. The package in the registry is what consumers actually run. Analyze it for its own dependencies, vulnerabilities and secrets, not only the source repository it came from.
3. Link the artifact to its source. A finding inside an internal package should point at the repository and team that build it, so the fix goes to the people who can make it.
4. Collapse the fan-out. When twenty services inherit a vulnerability from one internal library, the work item is one upgrade in one repository, followed by a version bump in consumers.
5. Apply the same policy. Guardrails and license rules should evaluate the dependencies of internal packages as strictly as direct open-source dependencies.

Who owns first-party package security

Ownership is where most first-party programs stall, so decide it explicitly.

• The library team owns the library. Vulnerable dependencies inside an internal package, secrets in its artifacts and its release cadence belong to the team that publishes it. They are the only people who can fix the root cause.
• Consuming teams own the upgrade. Once a fixed version is published, each consumer owns moving to it, the same way they would for an open-source release.
• The platform team owns the registry. Registry configuration, access control, retention and the resolution rules that prevent dependency confusion sit with whoever runs the registry.
• AppSec owns the policy and the visibility. Deciding what internal packages must satisfy, and making sure findings reach the right team, is a security program job.

Write this down. When a finding lands in a consuming service and nobody knows whether it is theirs or the library team's, it waits. A one-page ownership rule removes most of that waiting.

Signals that an internal package needs attention

You do not have to analyze every internal package with the same urgency. A few signals separate the ones worth looking at first:

• Wide consumption. A library imported by fifty services multiplies every problem it has by fifty.
• Stale releases. A package whose last release is more than a year old almost certainly depends on open-source versions with known vulnerabilities.
• Security-sensitive purpose. Authentication clients, crypto wrappers, HTTP clients and serialization helpers carry more risk per bug than a date-formatting utility.
• No clear owner. A package whose original team was reorganized away is the one most likely to have been forgotten.
• Published from an unprotected pipeline. If anyone with repository write access can publish a new version, the registry is only as trustworthy as that repository's access controls.

A practical checklist for private registries

• List every private registry in use, by ecosystem. Many organizations find more than they expected.
• Confirm each package manager resolves internal names only from the internal registry.
• Use scoped or namespaced package names wherever the ecosystem supports them.
• Give read-only, least-privilege credentials to any tool that inventories the registry.
• Record the owning team for every published package.
• Scan published artifacts for secrets, not just source repositories.
• Track which services consume each internal package and at which version.
• Treat "upgrade the internal library" as the default fix for inherited vulnerabilities.

First-party code is still code you ship

The supply chain framing can make it sound as if risk only comes from outside. It does not. An internal package is code your organization wrote, published and runs in production. It deserves the same inventory, the same vulnerability analysis and the same policy enforcement as anything pulled from a public registry, and it gets it far less often.

How Heeler treats first-party packages

Heeler connects to the registries where your teams publish packages and treats what it finds there as first-party code, correlated with the rest of your inventory and evaluated for vulnerabilities, secrets and policy drift. Supported package registries include AWS CodeArtifact, GCP Artifact Registry, Artifactory, Nexus, GitHub Packages and GitLab Package Registry. Registries inside your network can be reached through an on-premises broker. See Connect Registries and Artifacts for the full list.

• Classification on every dependency. SCA findings mark each dependency as direct or transitive, first-party or third-party, and whether it came from a private registry.
• Internal packages recognized as yours. For example, your organization's own NuGet packages are recognized, so findings inside them flow to the right repository and team instead of being treated as an external dependency.
• Least-privilege access. CodeArtifact is reached through a dedicated cross-account IAM role, kept separate from the read-only role used for cloud inventory.
• Remediation through private registries. A repository whose lockfile resolves against a private registry is included in the first-party inventory and is eligible for SCA Auto-fix.

FAQ

What is first-party dependency security?

It is the practice of inventorying, analyzing and enforcing policy on the packages your own teams publish and consume, not just open-source dependencies.

Why don't SCA tools find vulnerabilities in internal packages?

Internal packages have no public advisories, so a tool that matches package names against public databases treats them as opaque and misses the vulnerable dependencies inside them.

How do you fix a vulnerability inherited from an internal library?

Fix it once in the library's own repository, publish a new version, and upgrade consumers to it, rather than patching each consuming service separately.

How do you prevent dependency confusion?

Configure package managers so internal names resolve only from your private registry, using scoped names and source mapping, and avoid internal names that are unregistered on public registries.

If your internal libraries are a black box to your current scanner, see what changes when they are classified, analyzed and tied back to the teams that own them. Get a demo