Automated Dependency Management And Security Scanning

Andi Lamprecht ·2026-05-11· 5 min read· Accepted

Title

Context

Security findings are currently detected only during active development when branches are worked on. Inactive repositories accumulate undetected vulnerabilities because there is no regular scanning on trunk branches. This creates two critical problems:

1. Reactive detection: We only discover security issues when developers happen to work on a repository, leaving long periods where vulnerabilities remain unknown.
2. Manual remediation overhead: Engineers must manually update dependencies, run tests, and validate fixes—a time-consuming process that often gets deprioritized under delivery pressure.

We identified that most security updates follow a predictable pattern: update dependency → run automated tests → build application → deploy. If all steps pass, the update is safe to merge. This workflow is highly automatable.

Additionally, we currently have no systematic approach for:

• Proactively updating dependencies before security issues are disclosed
• Handling unresolvable findings (e.g., vulnerabilities in transitive dependencies with no available fix), mostly documented in [Security GHA scanner guide](confluence-title://ENG/Security GHA scanner guide), but needs review and update according to this process
• Allocating engineering time to address code-level security issues found by security scanning
• Ensuring vulnerabilities are addressed to meet compliance requirements

The team capacity constraint requires automation to manage the volume of dependency updates across multiple repositories while maintaining quality and security posture.

Decision

We will adopt an automated dependency management and security scanning strategy consisting of:

1. Scheduled security scanning running daily/weekly on trunk branches using standard security scanners (like osv-scanner, Trivy, etc.) to maintain current security status across all active repositories.

2. “Renovate” for automated dependency updates to generate grouped pull requests that update vulnerable dependencies with available patches. Renovate will be configured to:

   • Group updates by type (patch, minor, major, dev dependencies)

   • Create PRs with release notes and changelog context

   • Support proactive updates even without known vulnerabilities

     

3. Automated validation pipeline that executes tests, builds, and deployment checks on every dependency update PR.

4. Integrated notifications and tracking via Slack (#security-findings channel) for visibility and Jira for issue tracking, enabling engineers to address updates during low-priority work windows.

5. Documented exception workflow for temporarily ignored and/or unresolvable findings following the procedure in the [Security GHA scanner guide](confluence-title://ENG/Security GHA scanner guide).

6. Sprint allocation guideline of 1-2 security tickets per sprint to systematically address code-level vulnerabilities found by CodeQL, prioritized from Highest to Lowest severity.

Implementation approach

• Start with template repository containing baseline configurations
• Roll out to 3-5 pilot repositories for validation
• Expand to all active repositories (commits in last 60 days)
• Apply to remaining repositories in final phase

Consequences

What becomes easier

• Continuous security posture: We’ll detect vulnerabilities immediately in all repositories, not just those under active development.
• Security patch support for active deployed versions: Automation will capture security issues on the production-facing code by aiming branches that holds currently deployed version and provide a PR with recommendation to fix.
• Reduced manual toil: Engineers spend less time manually updating dependencies and validating changes—automated pipelines handle the repetitive work.
• Faster remediation: Security patches can be applied within 24-48 hours of disclosure instead of waiting for the next development cycle.
• Proactive updates: Staying current with dependencies reduces the risk of accumulating breaking changes and shortens the vulnerability window.
• Visibility and prioritization: Centralized Slack notifications and Jira integration make it easy to see what needs attention and track progress.
• Systematic code-level fixes: Regular sprint allocation ensures code-level vulnerabilities don’t accumulate indefinitely.

What becomes more difficult

• Initial setup overhead: Configuring Renovate, scheduled workflows, and integrations requires upfront investment.
• Notification management: Engineers must adapt to monitoring #security-findings channel; risk of notification fatigue if volume is too high.
• Exception handling: Unresolvable findings require manual triage, documentation, and periodic re-evaluation.
• False positive management: Security scanners may flag issues that require suppression or exception handling.
• Failed PR investigation: Red pipelines on dependency updates require debugging to determine if the failure is related to the update or a pre-existing issue.

Risks and mitigations

• Notification fatigue → Risk: Engineers ignore alerts

  • Mitigation: Tune Renovate grouping to reduce PR volume; use digest format; escalate critical findings.

• Insufficient test coverage → Risk: Updates merged without proper validation

  • Mitigation: Block merge on repositories below coverage threshold; prioritize improving tests.

Cost Impact

• Infrastructure & Operational Costs: GHA Runner Compute ~= $100–300/mo compute.
• Engineering Time Savings: 5–10 hours/month per engineer on waiting time, context switching.

Alternatives Considered

1. Dependabot only

Description: Use GitHub’s native Dependabot for all dependency management.

Rejected because:

• Dependabot produces duplicated information with osv-scanner in Github Advanced Security report.
• Dependabot doesn’t provide comprehensive way of excluding certain packages or CVEs from scanning run and report.
• Renovate also provides an option to monitor subset of branches by regexp, better support for proactive updates and more advanced configuration options that will be valuable as our needs evolve.
• While Dependabot offers zero-setup-cost GitHub integration, it has weaker grouping capabilities compared to Renovate. Although Dependabot added grouping features, Renovate’s grouping is more mature and flexible (e.g., group all patch updates, all dev dependencies, all minor updates in single PRs).

2. Manual process with scheduled scanning only

Description: Implement scheduled security scans but continue manual dependency updates without automation.

Rejected because: This addresses detection but not remediation, leaving the manual overhead problem unsolved. Given our team capacity constraints and the volume of dependencies across multiple repositories, this approach doesn’t scale and fails to achieve the efficiency gains needed to stay current with security updates.

3. Hybrid approach (Dependabot + Renovate)

Description: Use both tools across different repositories based on specific needs.

Rejected because: Operating two dependency management systems creates operational overhead, inconsistent workflows, and team confusion. Engineers would need to learn two tools and maintain two sets of configurations. The marginal benefits of choosing per-repository don’t outweigh the complexity cost.

4. Pure multi-instance (dedicated scanning per repository)

Description: Set up separate, repository-specific security workflows without centralized orchestration.

Rejected because: This creates configuration drift, makes it harder to enforce consistent policies, and increases maintenance burden. Centralized template-based approach ensures consistency and makes it easier to roll out improvements across all repositories.

Links

• [Implementation Plan: Dependency management with Renovate](confluence-title://ENG/Implementation Plan: Dependency management with Renovate)
• https://docs.renovatebot.com/