It started with a pull request.
Not a reckless one. Not a shortcut taken under pressure or a cowboy deploy pushed at midnight. It was a routine dependency update, reviewed by a competent developer, merged before the long weekend, and forgotten by the time the team logged off on Thursday afternoon. By Sunday morning, attackers had exfiltrated 47,000 customer records. The business didn't know until Monday.
This is not a hypothetical. Variants of this story play out every week across small and mid-sized businesses that do everything "right" by conventional wisdom — and still get breached, because conventional wisdom has a 72-hour blind spot baked into it.
This is the story of that blind spot, and how Continuous Threat Exposure Management closes it.
The Thursday Merge: How One Routine Update Opened the Door
Let's set the scene. A SaaS company — twenty-three employees, a lean engineering team of four, a product used by healthcare practices to manage appointment scheduling — is running a standard sprint. On Thursday at 2:47 PM, a developer opens a pull request to update a third-party authentication library. The library's changelog mentions a performance improvement and a minor bug fix. The developer skims it. Nothing alarming.
A colleague approves the PR within the hour. The CI pipeline runs, tests pass, and the merge lands in the main branch. By 4:30 PM, it's deployed to production. The team wraps up, closes their laptops, and begins their weekends.
What neither developer knew — what nobody at the company knew — is that the updated package had been quietly compromised three days earlier. Not by a flaw in the original codebase, but through a supply chain attack. A malicious actor had gained access to a maintainer's credentials on the package registry and pushed a poisoned version that looked identical to the legitimate one. The version number was incremented correctly. The checksum matched the new build. The code itself was functionally identical — except for forty-seven lines buried in a rarely-executed authentication callback that opened an outbound connection to an attacker-controlled server.
This is the anatomy of a modern supply chain attack. It doesn't announce itself. It doesn't trip obvious alarms. It passes your tests because your tests don't know what "normal" looks like for a package you've never profiled in isolation. And it lands in production on a Thursday afternoon, right before the window of maximum attacker opportunity opens. Supply chain attacks of this type have become increasingly prevalent; the SolarWinds and XZ Utils compromises are well-documented public examples of how trusted update mechanisms can be weaponised.
The 72-Hour Weekend Blind Spot Attackers Rely On
Here's something threat actors know that most SME founders and CTOs don't: the window between Friday evening and Monday morning is the most valuable real estate in the attack calendar.
It's not a matter of luck or coincidence. It's a deliberate operational pattern. Ransomware groups, state-sponsored actors, and opportunistic cybercriminals have all documented — through their own internal communications, later exposed in breach investigations and leaked chats — a clear preference for initiating active exploitation phases over weekends and public holidays. The reasons are straightforward:
Alert fatigue is higher. Security tools that do exist in SME environments often generate alerts that go into an inbox nobody checks until Monday.
Response times are slower. Even if a monitoring tool fires a notification, the human who would act on it is at a barbecue, at a family event, or simply offline.
Dwell time extends. Every hour an attacker operates inside a network undetected is an hour they use to map the environment, escalate privileges, and exfiltrate data. A 72-hour weekend gives them the equivalent of an entire working week of uninterrupted access.
Forensic trails cool. By Monday morning, log retention windows may have rolled over. Real-time anomaly signals are buried under three days of noise. Reconstructing the timeline becomes harder.
For the healthcare SaaS company in our story, the malicious package made its first outbound callback at 9:14 PM on Thursday — less than five hours after deployment. The attacker's infrastructure received the beacon, validated the target, and began a slow, methodical reconnaissance. By Friday morning, they had mapped the database schema. By Saturday afternoon, they had staged the exfiltration. By Sunday at 3:00 AM, they were done.
Nobody noticed. Nobody was watching.
Sunday Morning: A Breach in Slow Motion
Post-breach forensics are a specific kind of horror. You're not watching an attack happen — you're reading a transcript of something that already happened, piecing together a sequence of events from log fragments and network telemetry, trying to understand how far it went and what was taken.
In this case, the forensic timeline looked like this:
Thursday 14:47 — Vulnerable package merged and deployed to production.
Thursday 21:14 — First outbound beacon to attacker-controlled IP. No alert triggered. The connection was brief, low-volume, and used port 443 — indistinguishable from normal HTTPS traffic without deep packet inspection or behavioural baselining.
Friday 06:30 to 11:45 — Attacker conducted passive reconnaissance, querying database structure via authenticated application endpoints. No brute force, no anomalous login attempts. All activity appeared legitimate from the application layer.
Saturday 14:00 to 23:30 — Staged data exfiltration. Records pulled in small batches at irregular intervals — a deliberate pattern designed to avoid volume-based anomaly detection. Total data moved: approximately 2.3 gigabytes.
Sunday 03:00 — Exfiltration complete. Attacker deleted staging artefacts and closed the outbound connection.
Monday 09:15 — Developer notices unusual entries in the application error log and raises it with the team. Incident response begins.
By the time anyone was looking, the breach was sixty-three hours old. The attackers were gone. The data — names, contact details, appointment histories, and in some cases partial health information — was already in the wild.
The company faced regulatory notification obligations under GDPR, potential fines, customer churn, and a reputational wound that took eighteen months to begin healing. The total cost, direct and indirect, exceeded £340,000. Note: This figure is illustrative and drawn from a composite scenario; actual breach costs vary significantly by organisation size and sector. For a twenty-three-person company, that is existential territory.
And the maddening truth is that every step of this attack was detectable. Just not by anyone who was watching.
What Continuous Threat Exposure Management Would Have Caught
Continuous Threat Exposure Management (CTEM) is not a single product. It's a framework — and increasingly a managed capability — built around the principle that security posture is not a quarterly audit or an annual penetration test. It's a continuous, adaptive process of identifying, assessing, prioritising, validating, and remediating exposures before they become incidents.
Applied to our Thursday-to-Sunday timeline, here is where a CTEM approach would have intervened:
At the merge. A CTEM programme includes software composition analysis (SCA) integrated into the CI/CD pipeline, but crucially it also subscribes to real-time threat intelligence feeds that track package registry anomalies and supply chain compromise indicators. The poisoned package had a known malicious signature within hours of its publication — a signature that was flagged by threat intelligence platforms by Thursday morning. A CTEM-enabled pipeline would have matched the incoming dependency against that intelligence and blocked or flagged the merge before it reached production.
At the first beacon. Continuous Threat Exposure Management includes network behaviour analytics and external attack surface monitoring. The outbound connection at 21:14 on Thursday would have been assessed against a behavioural baseline. New outbound destinations contacted by application processes — particularly those resolving to known-bad or newly-registered infrastructure — are high-confidence indicators. An always-on CTEM layer would have generated an alert within minutes and, in an automated response configuration, could have isolated the affected service before the attacker completed reconnaissance.
During reconnaissance. CTEM includes continuous internal exposure assessment — identifying which assets are reachable, which credentials have excessive privileges, and which data stores are accessible from compromised application contexts. Knowing this in advance means either the exposure is remediated before it's exploited, or detection logic is tuned specifically to catch lateral movement through those pathways.
During exfiltration. Data loss prevention controls informed by CTEM's asset inventory and sensitivity classification would have flagged the volume and pattern of database reads as anomalous — not because of total volume alone, but because the access pattern (irregular batches, unusual query sequences, access outside normal application logic flows) deviated from established norms.
At every stage, the attack had a detectable footprint. Continuous Threat Exposure Management provides the always-on instrumentation and expert interpretation to see that footprint, even at 3:00 AM on a Sunday, even when your entire security team is one developer who thought the alert emails could wait until Monday.
Why SMEs Are the Perfect Target — and How to Stop Being One
There is a persistent myth that attackers primarily target large enterprises because that's where the money is. The data tells a different story. According to Verizon's annual Data Breach Investigations Report, small businesses account for a substantial and growing share of confirmed breaches each year, with SMEs consistently representing a significant proportion of victims across multiple report cycles. SMEs are not ignored — they are actively preferred by a broad category of threat actors for a cluster of interconnected reasons.
Valuable data, minimal defences. A healthcare SaaS with 20,000 patient records is extraordinarily valuable on dark web markets. But that company almost certainly doesn't have a SOC, a SIEM, or a dedicated security engineer. The ratio of data value to defence investment is enormously favourable for attackers.
Predictable tooling gaps. SMEs tend to rely on endpoint protection and perhaps a firewall, maybe a vulnerability scanner run occasionally. They almost never have continuous network behaviour analytics, real-time threat intelligence integration, or external attack surface management. Attackers have mapped these gaps and build playbooks around them.
Supply chain pivot points. Regulated sectors — healthcare, legal, financial services, accountancy — are full of SMEs that hold data on behalf of larger organisations or directly on behalf of consumers. Breaching an SME supplier is often easier than breaching the enterprise directly, and the data prize can be equivalent.
Slower incident response. Without an IR retainer, a documented response plan, and practiced runbooks, SMEs take longer to detect, contain, and remediate. That dwell time compounds the damage.
Stopping being the perfect target doesn't require hiring a team of ten security engineers. It requires closing the specific gaps that make SMEs attractive:
- Knowing your external attack surface and keeping it monitored
- Ensuring new code and dependencies are checked against live threat intelligence, not just static CVE databases
- Having continuous visibility into what's happening on your network, not just snapshots
- Operating with a documented, practiced response capability that doesn't depend on one person being awake
These are exactly the capabilities that a well-implemented Continuous Threat Exposure Management programme delivers, even — especially — for organisations without in-house security expertise.
Building an Always-On Security Layer Without an In-House Team
The good news — genuinely — is that the security capabilities that would have prevented the Sunday breach described above are no longer the exclusive domain of enterprises with eight-figure security budgets. Managed CTEM services have emerged specifically to serve the SME market, providing the instrumentation, intelligence, and human expertise that would otherwise require a full internal security team to operate.
Here's what a practical, SME-appropriate Continuous Threat Exposure Management programme looks like in implementation:
External Attack Surface Management (EASM). Continuous discovery and monitoring of your internet-facing assets — domains, subdomains, cloud services, APIs, exposed ports — mapped against known vulnerability and threat intelligence. You can't defend what you can't see, and many SMEs are surprised by what this surfaces.
Software Composition Analysis and Supply Chain Monitoring. Real-time tracking of your dependencies against threat intelligence feeds, not just published CVEs. The poisoned package in our story was in the threat intelligence ecosystem within hours — the company just wasn't subscribed to it. NIST's guidance on software supply chain security outlines the controls that would address exactly this exposure.
Network Behaviour Analytics. Continuous baselining of normal traffic patterns and automated alerting on deviations — new external connections, unusual data flows, anomalous query patterns. This is what catches beacons, reconnaissance, and staged exfiltration, including at 3:00 AM on Sunday.
Managed Detection and Response (MDR) Integration. An always-on human layer — analysts who receive, triage, and escalate alerts around the clock, so that the alert at 21:14 on Thursday doesn't sit unread until Monday morning.
Continuous Compliance Posture Management. For regulated organisations, CTEM also provides continuous visibility into compliance-relevant controls — encryption, access management, data handling — reducing the gap between point-in-time audits and actual day-to-day posture.
Validated Remediation Prioritisation. Not all exposures are equal. A mature CTEM programme doesn't just surface vulnerabilities — it validates which ones are actually exploitable in your specific environment and prioritises them by real-world risk, so your limited engineering time goes where it matters most.
For an SME, the operational model is typically a managed service: a provider like Kordax instruments your environment, monitors it continuously, and delivers actionable intelligence and response support without requiring you to hire, train, and retain a full security team. The cost is a fraction of a single security analyst's salary. The coverage is comprehensive and continuous.
The developer who merged that package on Thursday wasn't negligent. They were operating in an environment where the security tooling stopped at the point of human review — and human review stops at the weekend. Continuous Threat Exposure Management doesn't take weekends. It doesn't have a Friday afternoon close-of-business. It is, by design, the layer of protection that operates precisely when humans cannot.
The question for every SME leader reading this isn't whether their business could face a similar attack. It's whether they'd know about it before Monday morning.
If the answer is uncertain, the weekend gap is open. And someone, somewhere, is already looking for it.