A common sign is that teams can scan dependencies yet still cannot see risks in CI/CD tools, plugins, runners, or IaC paths. If security findings never connect code issues to pipeline context, gaps remain in how software is built and deployed. Another signal is repeated supply chain incidents despite mature dependency scanning, which suggests the control boundary is too narrow.
Where SCA Stops Giving a Full Supply Chain Picture
Traditional SCA is strongest when the question is “what libraries are in the build?” It becomes weaker when the real exposure sits around the build system, delivery path, or the software factory itself. That is where teams can have a clean dependency report and still miss compromised actions, runners, plugins, CI/CD secrets, or infrastructure-as-code paths that alter what ships.
A useful way to read the signal is to separate dependency visibility from delivery visibility. If your tooling only explains package provenance and known CVEs, but not how a change moved through pipeline trust boundaries, the control is answering a narrower question than the risk you are trying to manage.
That gap matters because modern supply chain attacks often target the surrounding workflow, not just the package graph. Internal case studies such as GitHub Action tj-actions supply chain attack and Shai Hulud npm malware campaign show why pipeline secrets, workflow logic, and publishing steps can be the real blast radius.
What the Warning Signs Look Like in Practice
The clearest sign is that teams can name vulnerable dependencies but cannot answer who touched the build, which runner executed it, which plugin expanded privileges, or which IaC change influenced deployment. If the output stops at “package X is risky” and never reaches “this workflow can exfiltrate secrets or alter release integrity,” visibility is incomplete.
Another sign is repeated incidents that look unrelated on the surface but share the same blind spot. For example, compromise of a build action, developer plugin, or package maintainer account can all lead to the same outcome, because the control plane around code delivery is under-instrumented. The supply chain issue is then not just dependency risk, but trust in the systems that assemble and publish software.
A third signal is that findings never connect to operational context. If a scanner flags an open source component but not whether it is used in a privileged build job, a release pipeline, or an environment with long-lived secrets, the result is a list of alerts rather than a visibility model. That usually means the organisation is looking at artefacts instead of the path they travel through.
How to Tell Whether Visibility Is Narrower Than the Risk
Ask whether your control can explain both provenance and execution. A mature view should tell you not only what code was introduced, but also where it ran, what credentials it could reach, what outbound channels were available, and whether the change was signed, reviewed, or isolated. When those answers are missing, the gap is usually in pipeline telemetry, secret handling, or trust in third-party build components.
It also helps to check whether control owners treat CI/CD, plugins, runners, and IaC as part of the software supply chain or as separate infrastructure concerns. When those domains are separated organisationally, findings often fragment too. The result is that security teams can report on dependency hygiene while missing the exact paths attackers use to turn that dependency access into production compromise.
External guidance such as NIST SSDF (SP 800-218), SLSA, and OpenSSF is useful here because it shifts attention from dependency lists to build integrity, provenance, and secure development practices.
Risk and Threat Considerations
When SCA cannot see the build and delivery path, adversaries can hide in the control points that decide what actually gets released. The risk is not only a missed vulnerable dependency, but a missed compromise of trusted workflow components that can inject code, steal secrets, or alter release artefacts without changing the dependency scan output.
Failure mechanism: The organisation monitors package composition but not the surrounding execution context, so malicious or compromised CI/CD components, runners, plugins, or IaC changes remain outside the alerting boundary.
Impact: Attackers can turn a trusted software process into a delivery channel for secret theft, tampered builds, and downstream compromise while the dependency report still appears healthy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and integrity directly address software delivery visibility gaps. |
| Recommendation — Adopt SLSA practices to verify build provenance and reduce trust in unobserved pipeline steps. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Software supply-chain visibility depends on verified development and build integrity. |
| CM-8 — System Component Inventory | Supply chain visibility starts with knowing the components and pipeline assets in scope. | |
| Recommendation — Apply SA-11 to validate code and build outputs before release. Maintain CM-8 inventories that include build tools, runners, and deployment components. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | SCA gaps are part of application software security and secure build governance. |
| Recommendation — Use CIS-16 to secure software development and release processes end to end. | ||
Practitioner Guidance
What to verify: Confirm whether your current SCA output can trace a finding from dependency to build job, runner, plugin, and deployment step. If it cannot, treat that as a scope problem, not a tuning problem.
Decision rule: If the tool cannot explain release integrity or secret exposure in pipeline context, do not rely on it as your primary supply chain control. Use it as one input, but pair it with controls that observe provenance, pipeline behaviour, and trusted build inputs.
What practitioners underestimate: Teams often assume dependency coverage equals supply chain coverage. In practice, the highest-risk gap is usually the control boundary between code review and code execution, where trust is inherited by tools, jobs, and automation that SCA alone does not model.
Practitioner takeaway: If you can scan the library inventory but not the delivery path, you do not yet have supply chain visibility, you have dependency visibility.
Related resources from NHI Mgmt Group
- What are the signs that blockchain supply chain controls are not giving pharma teams enough visibility?
- What are the signs that supply chain security controls are not giving teams enough visibility?
- What are the signs that an SCA programme is failing to protect the software supply chain?
- What are the signs that an AI workflow tool is not giving teams enough visibility for troubleshooting and audit?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
