DevSecOps Operations

Resolving the Container vs. Dependency Deadlock: Unified SLA Tracking

Stop Dev and DevOps finger-pointing. Learn to merge container security and Dependabot alerts into a unified vulnerability queue with shared InstaSLA tracking

By InstaSLA Superadmin · Published · 13 min read

Dependabot alert managementapplication security SLAunified vulnerability queueInstaSLA fix campaignsOS vs app vulnerability SLAcontainer security vs DependabotDevSecOps workflow integrationshared SLA accountabilitycontainer vs dependency deadlockGitHub container scanning alertsunified SLA trackingmerging security alertsplatform team vulnerability managementapp team dependency updatesbase image OS updateNPM package vulnerabilitiesPyPI dependency securityresolving DevOps vs App frictionshared vulnerability accountabilityDevSecOps team alignment
Resolving the Container vs Dependency Deadlock Unified SLA Tracking

Resolving the Container vs. Dependency Deadlock: Unified SLA Tracking

In the trenches of modern DevSecOps, few things cause more friction than a critical vulnerability alert without a clear owner. The scenario is painfully familiar: a high-severity CVE is flagged in a production service. The security team routes the ticket to the application (App) team. The App team sees that the vulnerable component is a system-level library and reassigns it to DevOps (or Platform). DevOps checks the base image, finds it current by their own metrics, and argues that the App team must be pulling the package in through a build script.

The ticket bounces. Days pass. The Service Level Agreement (SLA) breaches, and the service stays exposed.

This is the Container vs. Dependency deadlock. It is a byproduct of dual-layered architectures in which an application is tightly coupled to the container it ships in. Resolving it takes more than a better ticket template. It takes DevSecOps workflow integration built around a unified vulnerability queue, where alerts from container scanners and dependency scanners such as Dependabot are grouped into coordinated fix campaigns with shared SLA accountability.

The Anatomy of the Dual-Layered Deadlock

A typical microservice is a stack, not just the code your developers wrote:

  1. The base layer (OS and runtime): usually owned by DevOps or Platform Engineering. It includes the Linux distribution (Alpine, Debian, Ubuntu), system libraries such as glibc and openssl, and the language runtime.
  2. The application layer (dependencies): owned by the App team. It includes the open-source libraries declared in manifests like package.json, requirements.txt, or pom.xml, plus everything they pull in transitively.

The application layer is bigger than most teams assume. Black Duck's 2026 Open Source Security and Risk Analysis (OSSRA) report, which examined nearly 1,000 real-world codebases, found an average of 1,180 open-source components per application, and more than 90% of audited codebases contained components four or more years out of date. Then the base image adds its own inventory of OS packages on top. As Black Duck puts it, you did not write that code and did not choose most of those packages, but once you ship the image, you own all of it.

Consider a vulnerability in a ubiquitous library like libcurl or zlib, or a tool like ImageMagick. Who owns the fix?

  • If the package is installed through apt-get or apk add in the Dockerfile, the Platform team likely owns the update.
  • If a language package downloads or bundles its own vulnerable binary during npm install or pip install, the App team owns the bump.
  • If both are true, the answer is "both," and that is where deadlocks are born.

The counting problem makes it worse. Scanners often report one stale base image as dozens of separate findings. If twenty findings trace back to one old base image, you don't have twenty problems, you have one, and the fix is a rebuild rather than twenty rounds of triage. A ticket-per-finding process turns that one problem into twenty arguments.

When teams try to enforce an OS vs app vulnerability SLA, this ambiguity creates loopholes. People gravitate toward their own domain and reject tickets that look like they belong elsewhere.

Tooling Silos: Container Security vs. Dependabot

The cultural divide is reinforced by tooling. The industry has largely built separate ecosystems for the two layers.

The application lens: Dependabot and SCA

Developers live in Software Composition Analysis (SCA), and for GitHub teams that mostly means Dependabot. Dependabot parses manifests and lockfiles, raises alerts, and opens pull requests that bump vulnerable versions. For many App developers it is their main interface with security: if Dependabot is quiet, the app must be fine.

That assumption has a blind spot. Dependabot does not scan built container images. Its Docker ecosystem reads image references in Dockerfiles and Kubernetes manifests, checks the registry for newer tags, and opens pull requests to update them. That is a version update mechanism, not a vulnerability scan of what is actually inside the finished image. It also has practical gaps worth auditing in your own repositories:

  • Base images declared through a build argument (for example FROM ${BASE_IMAGE}) can be skipped by Dependabot's parser, so nothing is watched.
  • Dependabot's Docker scanning looks for standard file names by default, so a non-standard Dockerfile name can silently produce no update PRs.
  • A wildcard directories entry only matches directories that actually contain a Dockerfile or Kubernetes YAML. Otherwise the run fails or does nothing.
  • Private registries need explicit configuration, and a replaces-base setting decides which registry Dependabot resolves unqualified image names against.

The infrastructure lens: container scanners

Platform and DevOps teams typically rely on image scanners such as Trivy, Grype, Docker Scout, Clair, or Snyk Container. These unpack the built image layer by layer and check OS packages, language packages found inside the image, and sometimes misconfigurations and secrets.

One correction to a common assumption: GitHub's own scanning products cover code (CodeQL), secrets, and dependencies. Container image findings usually reach GitHub because a third-party scanner runs in CI and uploads its results as SARIF, at which point they show up under Code scanning alerts in the Security tab. That is useful, because it means image findings and Dependabot alerts can live in the same GitHub alert stream. But it also means the scanner's CI job, not GitHub, is the source of truth for the container layer.

The visibility gap

The real problem in the container-versus-Dependabot debate is that the two tools answer different questions in different places:

  • App teams live in the pull request view, handling Dependabot PRs.
  • DevOps teams live in CI logs or a scanner dashboard, handling image findings.
  • Security engineers context-switch between both, manually correlating an OS-level finding with an application that is deployed by a different team.

During a zero-day, this breaks down completely. Security cannot afford to open two sets of tickets in two systems and hope the teams coordinate.

Your scanner is part of the supply chain, too

The scanning layer deserves the same scrutiny as the code it scans. On March 19, 2026, attackers used compromised credentials to publish a malicious Trivy release, force-push 76 of 77 version tags in aquasecurity/trivy-action, and replace all 7 tags in aquasecurity/setup-trivy with malicious commits, according to the project's own security advisory. Microsoft's analysis noted that the affected workflows completed successfully with expected output, which masked the compromise from pipeline operators. The incident was a continuation of a campaign that began in late February 2026.

The lesson for this topic is practical. Any workflow that referenced those actions by a mutable version tag silently resolved to the attacker's code. Pin third-party actions, including security scanners, to full commit SHAs, and let Dependabot's github-actions ecosystem keep those pins current. A unified queue that depends on scanner output is only as trustworthy as the pipeline that produces it.

The Solution: Workflow Integration and the Unified Queue

The way out is to change how vulnerabilities are routed, tracked, and remediated: move from tool-centric alerting to service-centric alerting.

A unified vulnerability queue aggregates findings from every scanning tool (SAST, SCA, secret scanning, container scanning) and normalizes them into a single, deduplicated list of risks tied to a specific service or repository. When an engineer opens the queue for payment-service-api, they should not see "Dependabot alerts" on one tab and "Trivy alerts" on another. They should see one prioritized list of what threatens that service, regardless of which tool found it.

For GitHub-native teams there are two practical building blocks. First, get everything into GitHub's alert model: Dependabot alerts natively, and container findings via SARIF upload. Second, add an ownership and SLA layer on top, because GitHub's alert feed on its own tells you what is vulnerable, not who is accountable or by when.

Fix Campaigns: Coordinating Work Across Layers

This is where a workflow layer like InstaSLA fits. Its public documentation describes a GitHub-native tool that assigns GitHub security alerts to a person, team, or repository owner, tracks severity-based deadlines, groups repeated package advisories across repositories into fix campaigns, escalates risk, and exports compliance evidence.

Instead of spawning hundreds of disconnected tickets, a security team groups related work into one campaign. GitHub also ships its own security campaigns feature for coordinating remediation at scale, so the pattern is becoming standard. The difference is the ownership, SLA, and evidence layer wrapped around it.

How a campaign works in a dual-layer scenario

Imagine a severe vulnerability is announced in zlib. It shows up in 50 services: some through a Node package that bundles it, others through the Alpine base image.

  1. Aggregate. Query every open alert for the advisory across repositories, whether it arrived as a Dependabot alert or as an uploaded image-scan finding.
  2. Create the campaign. One campaign, one severity, one deadline: "Critical zlib patch."
  3. Assign to owners. Route work to the mapped repository owners. Where a repository has shared ownership (App owns the code, Platform owns the Dockerfile template), tag both teams in the campaign.
  4. Triage in context. For each repository, record where the finding lives:
    • Repo A: flagged in package-lock.json → an App team action.
    • Repo B: flagged in the base image → a Platform action.
    • Repo C: flagged in both → a coordinated fix, with both teams named.

One caution for implementers: InstaSLA's documented campaign feature is described in terms of repeated package advisories across repositories. Before you promise a unified OS-plus-app queue to leadership, confirm with any vendor exactly how image-scan alerts are grouped and deduplicated in your setup. Test it with one real CVE first.

Forcing collaboration through a shared clock

The most powerful element of a campaign is a unified SLA. The timer applies to the vulnerability's presence in the service, not to one team's sub-task. If your policy gives high-severity issues 14 days, the campaign shows a single countdown. If Platform updates the base image but App leaves the Dependabot PR unmerged, the service is still vulnerable, the campaign stays open, and the SLA still breaches. Because both teams are visibly accountable for the same clock, the conversation moves from "whose ticket is this?" to "who is doing which half, and when do we deploy?"

Structuring the OS vs. App Vulnerability SLA

A unified queue only works if the rules underneath it are explicit.

1. Document the ownership boundary

A common, workable split:

LayerTypical ownerWhere the fix lives
Base image (FROM line) and OS packages installed via apt, apk, yumPlatform / DevOpsDockerfile, base image tag or digest
Language packages via npm, pip, maven, gradle, gemApp teamManifest and lockfile
Binaries fetched by curl or wget in the app buildApp teamBuild script
Shared Dockerfile templates or golden imagesPlatform, with App consultedTemplate repository

Write down the edge cases too: language packages preinstalled in a base image, multi-stage builds where the final stage copies binaries from an earlier stage, and images inherited from another team.

2. Automate routing from the finding's origin

Use the scanner's own classification instead of guessing. Most image scanners distinguish OS packages from language-specific packages, and that field, not a file path, is the cleanest routing key. Route OS-package findings to the Platform owner and language-package findings to the App owner, then hold both accountable through the campaign. Automated tagging removes the administrative first hop without removing shared accountability.

3. Make deadlines risk-based, not just severity-based

A flat "14 days for High" treats a theoretical flaw in an internal batch job the same as an actively exploited flaw on an internet-facing gateway. The federal government has moved in this direction. CISA's Binding Operational Directive 26-04, issued June 10, 2026, replaces the flat timelines of BOD 22-01 and BOD 19-02 with a four-variable model: whether the asset is publicly exposed, whether the CVE is in the Known Exploited Vulnerabilities (KEV) catalog, whether exploitation can be automated, and the technical impact. The highest-risk combination gets a 3-day patching deadline, and other combinations get longer windows. For example, on three Linux kernel CVEs added to KEV on September 18, 2026, one carried a 3-day window on all assets while the other two carried 3 days for publicly exposed assets and 14 days for internal ones.

BOD 26-04 binds federal civilian agencies (FedRAMP cloud providers are also in scope, according to some analyses), not private companies. But it is a solid template for a private-sector SLA matrix. Two details matter for the container debate: the directive defines remediation broadly, so isolation or mitigation can count, and it places a premium on accurate asset inventories with clear ownership, which is exactly what the deadlock erodes.

4. Shrink the OS layer so there is less to argue about

Much of the deadlock disappears if the base layer carries fewer findings in the first place. Minimal and hardened images help. In December 2025, Docker made its catalog of more than 1,000 Docker Hardened Images free and open source under Apache 2.0. The images are built on Debian and Alpine and ship with SBOMs and provenance attestations. Docker reserves its contractual SLA of critical-CVE fixes within seven days for paid tiers, and free-tier users get patches without a predefined time window. Chainguard and other vendors offer comparable minimal images. Treat these as an input to your SLA policy, not a substitute for it: a vendor's patch SLA only helps if your team rebuilds and redeploys against it.

5. Enforce at the pipeline, carefully

An SLA needs teeth, and the CI/CD pipeline is where they live. Scanners support this directly. Trivy's action, for instance, can fail a job on findings at chosen severities via an exit code, while still uploading SARIF so the finding is tracked. Treat the container and the application as one immutable artifact: if the image built at the end of the pipeline still contains the breached vulnerability, the build should fail, no matter which team's half is outstanding.

Two implementation notes:

  • Gate on the right signal. Blocking every deploy on every breached medium finding creates pressure to game the process. Reserve hard blocks for critical, KEV-listed, or internet-exposed findings, and route the rest through escalation.
  • Be precise about who does the blocking. InstaSLA's public documentation describes ownership, deadlines, escalation, and evidence, and does not claim to block deployments on an SLA breach. Gating comes from your CI configuration, GitHub rulesets or required status checks, or a purpose-built policy engine that reads the SLA state. Plan for that integration work explicitly.

Keep an exception path, too. A documented, time-boxed risk acceptance with a named approver beats an engineer disabling the check at 2 a.m.

Conclusion

The debate between container security and application dependency management is a symptom of fragmented tooling and siloed ownership. Dependabot updates what your manifests and Dockerfiles declare, image scanners report what actually shipped, and neither tells you who has to act or by when. As attackers target the software supply chain, including the scanners themselves, organizations cannot afford the delays that come from arguing over ticket routing.

The fix is structural: one queue per service, one campaign per vulnerability, one shared SLA clock, ownership rules written down before the next zero-day, deadlines that reflect real risk, and a pipeline that enforces the result. When App and Platform share a single source of truth and a single countdown, the question shifts from "whose fault is this?" to "how do we secure this service?", and that change is what makes remediation faster.

Sources

Related articles