# Build dependencies inherit the build job's reach

Review credentials and network access where third-party code executes. A package excluded from production can still affect the software you deploy.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Map execution stages to authority

List installation, compilation, tests, packaging and deployment as separate stages. Record which dependencies execute in each and which credentials are available.

A test runner with access only to synthetic fixtures has a different exposure from the same runner in a job containing production deployment tokens. The package name alone does not determine the risk.

Keep unrelated secrets out of dependency installation and untrusted test contexts. Use the CI platform's supported isolation and identity mechanisms rather than relying on developers to remember which scripts are safe.

## Restrict promotion as well as execution

Separate building an artifact from authorising its deployment where the workflow requires that boundary. An arbitrary dependency should not gain release authority merely because it runs during compilation.

Verify the expected artifact identity and available provenance before promotion. The verifier must check the trusted builder and relevant inputs, not simply the presence of a signed statement.

Review pull-request workflows carefully so untrusted contributions cannot obtain privileged credentials through build or test steps.

## Treat inventories and logs as data

Dependency inventories can reveal internal package names and architecture. Share them according to the organisation's information policy while preserving enough access for review and incident response.

Avoid logging registry credentials, environment dumps or private source contents during installation diagnostics. A failed build should not become an accidental credential export.

Scope registry access to the packages and actions the job needs. Read access for installation and publish access for release are different capabilities.

## Test the boundary with harmless fixtures

Use a controlled script in an isolated test project to confirm which environment variables and network destinations are available. Do not execute a suspected malicious package in a privileged environment as a diagnostic shortcut.

Verify that a normal build still succeeds under the reduced authority. Document any required exception with its package, stage and owner rather than granting broad access to the entire pipeline.

The review should explain what third-party code can reach before runtime. That is often where the most consequential supply-chain permissions are concentrated.

## Sources

- [SLSA: provenance](https://slsa.dev/spec/v1.2/provenance)
- [OWASP: vulnerable dependency management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)