DevSecOps Operations
M&A Security Due Diligence: Triaging Inherited GitHub Vulnerabilities
Overwhelmed by inherited technical debt? Get our 30-day M&A cybersecurity due diligence playbook to triage GitHub vulnerabilities with InstaSLA fix campaigns
By InstaSLA Superadmin · Published · 13 min read
M&A Security Due Diligence: Triaging Inherited GitHub Vulnerabilities
The ink is dry, the wire has cleared, and the celebratory emails have gone out. If you are a VP of Engineering or a private equity technology advisor, the acquisition phase is over. Post-merger integration (PMI) is where the real work begins.
You get access to the acquired company's GitHub organization. You switch on Dependabot and CodeQL, wait for the first scan results, and the dashboard fills with red: thousands of unpatched dependency alerts, outdated packages, and code-level findings. You did not just buy a product and a revenue stream. You bought years of accumulated, unmanaged technical risk.
Finding that backlog after close is close to a rite of passage. Pre-deal audits often lean on questionnaires and surface-level scans, and the true picture only appears once you have full repository access. The numbers back this up. Black Duck's audit team, which reviews codebases in M&A transactions, found unpatched open source vulnerabilities in 97% of the transactions it worked on, with a mean of 786 vulnerabilities per transaction, and 78% of those codebases contained at least one high-risk vulnerability. Its 2026 OSSRA report, which draws on the same audit data, found at least one open source vulnerability in 87% of audited codebases.
Time is your most expensive asset at this point. You cannot spend the first six months assigning thousands of Jira tickets to a newly acquired engineering team that is already anxious about the merger. You need a structured, high-velocity approach. This article lays out a 30-day playbook for using InstaSLA to group, assign, and quantify inherited security debt, turning a chaotic new codebase into a set of manageable Fix Campaigns.
Why Inherited Risk Becomes Your Risk
Due diligence tells you that risk exists. It rarely equips you to manage it on day one, and the legal and financial consequences land on the buyer regardless of when the flaw was introduced.
Two well-known cases show the pattern:
- Verizon and Yahoo (2017). Two previously undisclosed Yahoo breaches surfaced during the deal. Verizon still closed, but at a price reduced by $350 million (to $4.48 billion), and it agreed to share legal liability for the breaches.
- Marriott and Starwood. Starwood's guest reservation system was compromised in 2014, exposing roughly 339 million guest records. Marriott acquired Starwood in 2016 and did not discover the breach until 2018. The UK Information Commissioner's Office fined Marriott, not Starwood's former owners: £18.4 million in 2020, down from a proposed £99.2 million.
Neither case involved a GitHub dependency backlog, but the lesson transfers directly. Once the deal closes, "we inherited it" is an explanation, not a defense.
Deal teams increasingly recognize this. In a Q4 2025 survey of 150 senior M&A executives by SRS Acquiom and Mergermarket, 84% expected cybersecurity due diligence to face more scrutiny over the next 12 to 24 months, and 43% expected significantly more.
The Crisis of the Acquired Codebase
When an acquirer inherits a legacy codebase, it also collides with a different, often less mature engineering culture. Five problems show up almost immediately.
- The velocity problem. Attackers move faster than integration calendars. VulnCheck found that 28.96% of the vulnerabilities that were newly seen exploited in 2025 showed exploitation on or before the day their CVE was published. Its first-half 2026 data put that figure at 23.43%, and it reported the median time from CVE publication to evidence of exploitation shrinking from 120 days to 80. Mandiant's M-Trends 2026 estimates the mean time to exploit at negative seven days, meaning exploitation frequently begins before a patch exists. A "medium" finding logged during diligence in August can be on a known-exploited list by the time integration starts in September.
- Alert fatigue and attrition risk. An acquired team is already worried about job security, new management, and cultural change. If your first act is dumping 4,000 security alerts onto their sprint backlog, you risk burnout and losing the key people who understand the code.
- The ownership void. In a startup or mid-market target, code ownership is often tribal knowledge. The developer who wrote a vulnerable microservice three years ago may have left. When an alert fires, native tooling has no idea who is accountable.
- Duplicate alert noise. GitHub raises Dependabot alerts per repository. If an outdated
lodashoraxiossits in 50 microservices, you see 50 separate alerts for what is often one root cause. Black Duck's 2026 OSSRA quantifies the gap: audited codebases averaged 581 vulnerability instances but only 237 unique vulnerabilities, because every occurrence of a vulnerable component is counted separately. - Blind spots in the inventory. Manifest-based scanners only see what package managers declare. OSSRA found that 17% of open source components enter codebases outside standard package managers, through copy-pasted snippets, vendored libraries, direct vendor inclusions, or AI generation. Legacy codebases are exactly where this happens, so a clean-looking Dependabot view can understate real exposure.
To overcome these hurdles, move from reactive alert-chasing to an SLA-driven remediation framework. That is the job InstaSLA is built for.
The 30-Day InstaSLA Integration Playbook
InstaSLA gives GitHub-native teams ownership, SLA tracking, and Fix Campaigns for security alerts. Deployed on day one of integration, it lets you work down inherited debt without stalling product momentum.
Days 1-5: Ingestion, Quantification, and the Baseline Assessment
The first five days are about total visibility and building a security-debt balance sheet for your executive sponsors or PE board.
Action 1: Connect and ingest. Connect InstaSLA to the acquired company's GitHub organization and ingest the existing CodeQL, Dependabot, and secret scanning alerts. Do not fix anything yet. This phase is purely observational.
A practical caveat: GitHub only generates alerts for features that are switched on. Code scanning needs a CodeQL configuration per repository, and Dependabot needs the dependency graph. Since April 2025, GitHub has sold its advanced security capabilities as two separate add-ons, GitHub Code Security and GitHub Secret Protection, so enabling them across a newly acquired organization has a licensing cost you should budget for. Also confirm that CodeQL supports the languages in the acquired stack, and plan a separate inventory pass (SBOM or composition analysis) for vendored code that manifests never mention.
Action 2: Quantify the exposure. Categorize inherited debt by severity (Critical, High, Medium, Low) and translate it into business language. Instead of "we have 2,000 CVEs," report "we have inherited 45 critical vulnerabilities affecting internet-facing infrastructure, a material risk to our new asset."
Severity alone is a weak lens, though. Veracode's 2026 State of Software Security report argues teams should concentrate on the 11.3% of flaws that pose real-world danger. Datadog's State of DevSecOps 2026 (as summarized by Pixee) found that only 18% of vulnerabilities labeled critical stayed critical once runtime context was applied. GitHub now supports this directly: its linked artifacts feature lets you attach production context to Dependabot and code scanning alerts, so you can filter for flaws in artifacts actually deployed. For an acquisition, that is a fast way to separate the dormant repositories from the ones running your new revenue stream.
Action 3: Freeze the baseline. Draw a line at the acquisition date. Anything discovered before it is "Legacy Debt"; anything introduced afterwards is "New Debt." This distinction matters psychologically for the acquired team: they are not penalized for the past, but they own what they write from now on.
Keep in mind that the baseline is an internal management tool, not a legal shield. As the Marriott case shows, regulators and customers look to the acquirer.
Days 6-10: Mapping Ownership and Accountability
A vulnerability without an owner does not get fixed. The biggest failure of traditional legacy vulnerability management is assuming someone will eventually pick up the ticket. Veracode's 2026 data puts a number on it: the median fix half-life across all scan types was 243 days, and for software composition analysis findings it was 358 days.
Action 4: Repository owner mapping. Work with the inherited engineering managers to map every active repository to a person or team, and use InstaSLA's ownership routing to assign every GitHub security alert to an accountable party.
Action 5: Handle orphaned code. You will find repositories that run in production but that no one maintains. These are your highest-risk assets. Assign them explicitly to the Director of Engineering or the architecture team and force a decision: re-staff, rewrite, or decommission.
Action 6: Establish the audit history. Assigning ownership in InstaSLA also starts an audit history of assignment changes. If a critical alert sits untouched, you know whose queue it is sitting in.
Days 11-20: Deploying Fix Campaigns
This is where remediation accelerates. You cannot fix 5,000 individual alerts, but you can fix 50 root causes.
Action 7: Identify duplicate dependencies. Look at your InstaSLA dashboard for packages that account for a disproportionate share of critical alerts. Third-party code is usually the source: Veracode found that 66% of critical security debt originates in third-party components.
Action 8: Launch Fix Campaigns. Group repeated package advisories across repositories into a single campaign.
- Example: group all 85 alerts for an outdated
axiosversion into one campaign called "Post-Merger Remediation: Axios Upgrade." - Result: the acquired team sees one coordinated piece of work instead of a fragmented mountain of tickets.
GitHub has its own campaign concept, and it is worth understanding how the two relate. GitHub's security campaigns became generally available in April 2025 for code scanning alerts, with Copilot Autofix generating suggested fixes, and GitHub's documentation now lists secret scanning campaigns as a public preview. Grouping Dependabot package advisories across repositories is the piece that has not been part of GitHub's native campaigns, and it is the piece that matters most in an inherited-dependency scenario. Check GitHub's current documentation before publishing, as this area changes quickly.
Action 9: Track campaign progress. Use the Security Queue in InstaSLA to prioritize by campaign progress. Engineering managers can see which repositories have updated the package and which are lagging, so the campaign crosses the finish line together.
Days 21-30: Enforcing SLAs and Exception Management
By week four the chaos is organized into owned, grouped campaigns. Now attach deadlines and enforce them.
Action 10: Define severity-based SLAs. Adopt a policy that both the acquiring security team and the acquired engineering team can share.
| Severity | Standard SLA |
|---|---|
| Critical | 7 days |
| High | 14 days |
| Medium | 30 days |
| Low | 90 days |
Then layer exploitation evidence on top of severity. In June 2026, CISA issued Binding Operational Directive 26-04, which replaced the flat deadlines of BOD 22-01 with a risk-based model built on four variables: asset exposure, KEV catalog status, exploit automation potential, and technical impact. Its most urgent tier requires remediation within three days, plus forensic triage, for known-exploited flaws that are exposed and highly damaging; other tiers run 14 days, 60 days, or fix-on-next-upgrade. The directive binds federal civilian agencies only, but it is a useful benchmark for private companies. A sensible override for your policy: any known-exploited vulnerability on an internet-facing asset gets a three-day clock, regardless of its CVSS label.
The urgency is real. Per figures cited from Verizon's 2026 Data Breach Investigations Report, only 26% of vulnerabilities on CISA's KEV catalog were fully remediated in 2025, down from 38% the year before.
Action 11: Activate the InstaSLA queue views. Queue views show developers what is overdue, what is due today, and what is due this week, turning abstract security mandates into daily engineering priorities.
Action 12: Implement audit-proof exception workflows. In a legacy codebase, some patches will break the application, and you cannot force an update that takes down a newly acquired revenue stream. A developer who realizes a critical fix will cause an outage should not simply ignore the alert. Use InstaSLA's Risk Acceptance Workflows: when an engineer requests an exception, InstaSLA alerts the CISO or Security Lead, who reviews the context, evaluates business impact, and formally accepts the risk for a defined time window. This creates an audit-proof exception trail for your board, private equity sponsors, and auditors.
Regulatory Clocks Start at Close
Inherited vulnerabilities are not only an engineering problem. If the acquired company sells products with digital elements in the EU, the Cyber Resilience Act's reporting obligations have applied since September 11, 2026. A manufacturer that becomes aware of an actively exploited vulnerability in its product must submit an early warning to ENISA and the relevant national CSIRT within 24 hours, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective measure is available. The obligations cover products already on the EU market, not only new releases, and the clock starts when the manufacturer becomes aware, not when it finishes verifying.
Practically, that means your day 1-10 work, knowing what components ship in which product and who owns each repository, is what makes a 24-hour report possible at all. Confirm with counsel which legal entity counts as the manufacturer after close.
Measuring ROI: Defending the Board's Investment
The goal of this playbook is not just to patch software. It is to protect the valuation of the asset you acquired. Deploying InstaSLA shifts the narrative from "we bought a massive liability" to "we are executing a controlled risk-reduction program."
1. Reduced integration friction. Fix Campaigns collapse duplicate alert noise, which reduces the cognitive load on the acquired team, preserves morale and feature velocity, and builds trust between new management and legacy developers.
2. Defensible board reporting. When the PE sponsor asks for a status update at day 45, you can present a dashboard instead of vague assurances. An illustrative status line: "We inherited 1,500 critical alerts. By mapping ownership and grouping them into 12 Fix Campaigns, we have remediated 80% of our critical exposure within the mandated SLA. The remaining 20% are under formal, documented risk acceptance while we refactor the legacy architecture." (These figures are hypothetical, so set your own targets from your baseline. Be realistic: Veracode's 243-day median fix half-life shows how far typical programs sit from a 30-day finish, which is exactly why organized campaigns and honest exception tracking matter.)
3. Seamless compliance evidence. As you bring the acquired company into SOC 2, ISO 27001, or other continuous compliance frameworks, the history in InstaSLA becomes primary evidence: ownership, due dates, completion timelines, and executive-approved risk exceptions.
Conclusion
M&A cybersecurity due diligence is only half the battle. Surviving the avalanche of inherited alerts afterward is the real test of post-merger integration. Traditional ticketing and manual triage fail under the volume and velocity of the risk, and a software acquisition security audit tells you what is broken without giving you the machinery to repair it.
Veracode's 2026 State of Software Security report found that 82% of organizations now carry security debt (flaws left unfixed for more than a year), and 60% carry critical security debt. Your acquisition target is very likely one of them. Treat legacy vulnerability management as a workflow problem rather than an individual-bug problem: establish undeniable ownership, enforce shared SLAs, and group chaotic alerts into prioritized Fix Campaigns. In the high-stakes window of post-merger integration, that is the difference between drowning in inherited debt and systematically working it down.
Sources
- Veracode, 2026 State of Software Security: press release, report page, and Help Net Security coverage (243-day fix half-life, 66% third-party share)
- Black Duck, Open Source Risk in M&A and 2026 OSSRA analysis
- SRS Acquiom, 2026 M&A Due Diligence Study
- VulnCheck, State of Exploitation 2026 and 1H-2026; Mandiant M-Trends 2026 (mean time to exploit) via Suzu Labs
- Pixee, What we learned reading 30 security reports (Datadog State of DevSecOps 2026 figure)
- CISA, BOD 26-04; Tenable explainer; Cloud Security Alliance note (KEV remediation rates)
- GitHub, security campaigns GA announcement, About security campaigns, and production context for alerts
- European Commission, CRA reporting obligations
- Herbert Smith Freehills, ICO fine on Marriott; Auth0, M&A deals that imploded over cybersecurity (Verizon/Yahoo)Overcome Dependabot Alert Fatigue: Dev Strategies