CODE Vulnerability Management

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

ADR-0070 · Author: Sybil Melton · Date: 2025-02-07 · Products: platform
Originally ADR-0011-CODE-VULNERABILITY-MANAGEMENT (v7) · Source on Confluence ↗

Code Vulnerability Management

Context and Problem Statement

The DroneUp Engineering organization requires a decision on what to use for various vulnerability-related needs.

Decision drivers

Feature Completeness
Platform Integration
Cost
Maintenance
User Experience
Opportunity Cost

Considered Options

Snyk
GitHub Advanced Security

Decision Outcome

Chosen option: Snyk, because it is already implemented and satisfies the needs of most of what we are looking for with regards to capability, user experience, integrations, and maintainability.

Consequences

Good, because it is already implemented and consequently does not introduce additional implementation effort.
Good, because it has a capability for code vulnerability analysis.
Good, because it has enough integrations with existing services with Atlassian, GitHub, and GCP offerings.
Good & Bad, because it has a capability for scanning containers but it requires additional separate licensing.
Good, because it has an autofix capability.
Good, because it has vulnerablity reporting which is superior to products which provide similar capabilities.
Good, because it provides DroneUp with the ability to report on licensing and dependencies easily.
Good, because it has an organizational capability that allows product leagues to get an entire view of their league at a glance.
Good, because it can open Pull Requests with suggested remediations.
Good, because an IDE extension exists to help Engineers fix Snyk-identified issues earlier.
Bad, because it’s licensing model is modular and is likely more expensive than products which provide similar capabilities.
Bad, because it requires more context-shifting compared to products which provide similar capabilities. GitHub Advanced Security provides one sole UI where an Engineer can review their code scanning vulnerabilities whereas Snyk requires navigation out of GitHub, to Okta, and then to Snyk.
Bad, because newly created repositories must be imported manually to be covered.
Bad, because it is less extendable in terms of integrations compared to products which provide similar capabilities. Snyk has significantly less options for available integrations than provided in GitHub Advanced Security, including and outside of the primary focus of this ADR for code security scanning.
Good & Bad, because it invokes hardcoded secrets detection rules during SAST scans but does not act as a standalone secrets scanning tool.

Pros and Cons of the Options

GitHub Advanced Security

Good, because setup can be done at the GitHub Organization for supported languages.
Good, because secret detection is included and easily enabled at the GitHub Organization.
Good, because GitHub Marketplace provides an unmatched experience for exploring new integrations easily and quickly.
Good, because Engineers work in GitHub and can see their repositories security posture without context shift.
Good, because it can use GitHub Actions credits already dedicated to DroneUp due to the existing GitHub Enterprise licensing agreement.
Good, because it can suggest fixes
Good, because Dependabot can be used to open Pull Requests.
Good, because it provides the ability to acknowledge or dismiss findings and false positives.
Bad, because it provides a significantly subpar reporting capability.
Bad, because it does require implementation effort.
Bad, because languages not supported by CodeQL scanning requires significant implementation effort and maintenance.
Bad, because it is incapable of direct and native container scanning.
Bad, because it is dependent on GitHub Actions which introduces additional tool sprawl.
Bad, because license and dependency scanning requires significant implementation effort needed to be controlled on a per-repository level.