Your platform dashboard can be green while open source dependencies keep rearranging the sprint. A vulnerability holds a deployment. A package update breaks a build. An application team spends another afternoon finding a version it can safely ship. The delivery metrics record the interruption, but the dependency work gets scattered across hotfixes, retries, and maintenance tickets.
That makes a shared platform problem look like a series of local exceptions. The team closest to each failure absorbs the work, and leadership sees less capacity without a clear explanation. Put dependency costs on the platform scorecard, and you can make a specific case for controlling what enters the build while protecting the capacity engineering already has.
Key takeaways
Give dependency work a consistent label so its cost survives the handoff between teams.
Pair delivery outcomes with a leading measure of packages entering without review.
Assign shared intake and remediation responsibilities, while application teams retain compatibility testing.
Start with one service and a 30-day baseline, then take your own numbers to planning.
The cost disappears when the ticket changes names
A recurring pattern in dependency work is the gap between its cause and its label. A vulnerable library becomes a hotfix. A breaking change in an indirect, or transitive, dependency becomes a continuous integration (CI) failure. A security response becomes a reprioritization meeting. Each record describes something real; none necessarily preserves the common cause.[1][2]
The useful first change is small: keep the dependency cause attached to the work. Link the affected package and version to the issue, the failed build, and the held deployment. A platform team can bring those records together with security and application owners, then show which interruptions repeat across services.
AI makes that connection more urgent. An assistant suggests an import, or an agent runs an install, and the package manager resolves the dependencies underneath it. The decision can add more software than the developer explicitly selected. The mechanism is explained in ActiveState’s article on AI-generated dependencies and control at the source.[4]
In The AI Remediation Bill, 94% of respondents said AI had increased open source consumption, and 83% said developer productivity was outpacing governance. ActiveState commissioned the research, conducted by Moving Horizon with 307 enterprise leaders and 10 practitioner interviews. These self-reported findings establish the pressure on the model; your service-level records establish the cost to your team.[3]
The bill exists whether you measure it or not.
Five measures connect the interruption to its cause
Start with the measure tied to the decision you need to make. If roadmap work keeps moving, begin with unplanned dependency hours. If releases keep waiting, begin with blocked deployments. Agree on the service, time window, and definitions before collecting a baseline, so the next period measures the same thing.
1. Dependency-blocked deployments. Count deployment attempts held or failed because of a dependency vulnerability or policy gate. Track their share of all held or failed attempts, and retain the raw counts. CI/CD logs and policy decisions supply the starting evidence; a consistent cause label separates these blocks from other release problems.
2. Dependency remediation lead time. Measure from an upstream fix becoming available to the patched component running in production. Keep those timestamps separate from vulnerability disclosure and detection. This clock shows how long your own evaluation, testing, and promotion process takes after a fix exists.
3. Unplanned dependency work. Tag hours spent on unplanned upgrades, dependency investigation, and vulnerability tickets. Divide those hours by available sprint capacity for the same team and period. Keep scheduled maintenance separate so the measure reveals what displaced planned work.
4. Ungoverned intake rate. Count new package versions reaching production without the review your policy requires, divided by all new package versions reaching production. Join the deployed inventory to approval records. Track missing evidence separately: an absent record requires investigation before you call it a bypass.
5. Dependency build breaks. Add a CI failure category for breaks traced to a transitive dependency change. Link retries to the same underlying event so repeated attempts do not inflate the count. This gives platform owners a concrete reliability problem to investigate.
Keep these measures beside your delivery metrics. DORA’s change fail rate concerns deployments requiring immediate intervention after deployment. A dependency gate that holds a release beforehand belongs in a different count. Use the two together to explain where delivery slowed and whether production stability changed.[6]
Make the shared source a platform responsibility
A scorecard gives you a basis for changing the workflow. Consider a service whose repeated blocks trace back to packages entering before anyone applies policy. ActiveState’s research found that 63% of respondents address open source vulnerabilities only after scanners find them.[3] Scanning remains a necessary backstop as vulnerabilities emerge. Intake controls give that backstop a source governed before the build starts.
Treat the approved source as part of the paved road: the supported development path your teams can use by default. Security sets the acceptance criteria with engineering. Platform owners operate the intake process, preserve the decisions, and make approved versions available. This turns the governance question into a decision about what gets in, with a record of who approved it.[5]
Follow one package through that model. A developer or AI assistant requests it. The intake process evaluates its license, known vulnerabilities, maintenance signals, and provenance. An approved version enters the internal source. Build configuration resolves through that source, with explicit handling for exceptions and public-registry access. A slow or optional path invites workarounds, so measure how long requests wait as well as whether teams follow the path.
When a vulnerability appears and a fix becomes available upstream, a named owner evaluates and publishes the remediated version to the approved source. The application team tests compatibility and promotes it. Specify that ownership and the remediation commitment whether your platform team builds the capability or buys a service. Compatibility and deployment remain application responsibilities.
Take a 30-day baseline to the next planning meeting
Start with one service whose dependency interruptions the team already recognizes. In the first week, agree on the labels, the intake-review requirement, and the people who will reconcile the records. Use the rest of the month to collect the events and check a sample together. You can begin with an issue tracker and existing build records.
At the end of the period, multiply measured dependency-work hours by your agreed loaded hourly cost. Keep release-delay duration, audit work, and incident response alongside that estimate. Convert those into money only where you have defensible local inputs, and remove overlap before combining costs. One response task can appear in several systems and still represent the same hour.
Bring that baseline to engineering, security, and finance with one proposed change: a clearer owner, a better intake path, or a shorter delay between an available fix and production. Then use the same definitions to check whether the change improved the result.
For the next sprint, choose one service and add one dependency-work label. Give someone responsibility for bringing that first month of evidence to planning. The team already pays for the interruptions. A shared record gives it a practical way to fund work that prevents them.
Sources
Leslie Pascual, Hidden Platform Metrics: Talk Script, October 28, 2026.
ActiveState, The AI Remediation Bill, research conducted by Moving Horizon with 307 survey respondents and 10 interviews, July and August 2026. Findings are self-reported.
What are dependency costs in platform engineering?
Dependency costs include investigation, upgrades, testing, build failures, and release interruptions tied to open source packages. A useful baseline links these events to their dependency cause and separates planned maintenance from unplanned work.
Which dependency metric should a platform team track first?
Start with the metric tied to a current planning problem, such as unplanned dependency hours or held deployments. Keep its scope and definition consistent, then add intake measures to investigate how the work begins.
When should dependency remediation lead time start?
For this scorecard, start when an upstream fix becomes available and stop when the patched component runs in production. Record disclosure and detection separately so you can distinguish waiting for a fix from your own response process.
Who owns compatibility testing in a governed intake model?
The application team owns compatibility testing and promotion into production. The platform and security teams agree on intake policy, and a named operator handles the shared source and remediation workflow.
How can a team avoid double-counting dependency costs?
Link issues, builds, and release events to the same underlying work and count each labor hour once. Report delay duration and other consequences separately until their financial value and any overlap have been established.
