ACDS

"Why teams choose Observatory" Attackers don't scan your asset inventory. They scan the internet. So that forgotten subdomain, the dev box someone spun up in a hurry, the leaked cloud key sitting in plain sight, those are the doors. And most teams can't see them. Observatory can. We scan billions of IP and port combinations to map your external attack surface the way an attacker actually sees it. Shadow IT, OT, IoT, the assets you didn't know were yours. Then we cut the noise with CVSS and EPSS scoring so you fix what's genuinely dangerous, not what's merely loud. And with Deep Field, we go beyond surface scanning by mapping vulnerabilities across your software supply chain packages. That's the layer most EASM tools never reach. No agents. No quarterly scan you've already outgrown. Just a live, attacker 's-eye view of everything exposed under your organisation.

Data kept "just in case" is data that can be stolen — and regulators are taking notice. French travel company Voyageurs du Monde is facing a €1.8M CNIL fine after a breach exposed 8,000 customer passports. Three years on, the core issue isn't the attack itself. Read our MD for France's take on what it actually reveals about how organisations manage their attack surface 👇

France's sovereign messaging platform was breached last week. End-to-end encryption held. The attack succeeded anyway. One compromised account. 643,000 messages. The gap wasn't in the cryptography — it was in the blind spot between protocol security and identity management. Our MD for France breaks down what actually happened with Tchap, and the question every security team should be asking about their own perimeter. 👇

Engineering security for speed and clarity. When the Log4Shell vulnerability emerged, organisations around the world faced the same challenge at the same time: work out what was actually affected, and fix it fast. The problem wasn’t a lack of alerts. It was a lack of clarity. Security teams were flooded with notifications, tooling outputs, and conflicting guidance. Many spent critical hours — and days — trying to identify which systems were genuinely exposed, which were false positives, and what needed immediate action. The teams that moved fastest weren’t the ones with the most data. They were the ones who could see clearly. When security tools prioritise volume over precision, response slows. Analysts spend time validating findings, navigating complex dashboards, and debating severity — while real exposure remains open. That’s the cost of security engineered for noise instead of decision-making. Engineering security for speed means engineering for clarity: - Precision over volume - Evidence you can trust - Prioritisation that makes sense - Interfaces built for action, not investigation Speed in security doesn’t come from working harder. It comes from seeing what matters and acting quickly. When the next Log4Shell-scale issue hits, will your tools help your team move faster — or slow them down?

False positives don’t just waste time. They destroy security productivity. Every false alert still has a cost. Someone has to check it. Someone has to validate it. Someone has to decide whether it matters. Multiply that by dozens — or hundreds — of alerts a week, and productivity quietly disappears. I’ve seen teams with strong coverage still struggle because analysts spend more time triaging noise than fixing real issues. When everything looks urgent, prioritisation breaks down. Response slows. And genuine risk waits longer than it should. This is how alert fatigue sets in, not because teams don’t care, but because they’re overwhelmed. Good security tooling shouldn’t reward volume. It should reduce friction. That means: - Fewer false positives - Clear evidence - Obvious prioritisation - Workflows built for action, not investigation Reducing false positives isn’t a nice optimisation. It’s fundamental to helping security teams do their jobs effectively. How much time does your team spend validating alerts that turn out to be nothing?

Security without intrusion. In cyber security, visibility often comes with trade-offs. More access. More integration. More impact on internal systems. But for many organisations, particularly in regulated markets, that approach creates as many concerns as it solves. Security tooling shouldn’t introduce additional risk, operational burden, or compliance complexity just to provide insight. Especially when the goal is to understand what’s already exposed to the outside world. That’s why how security tools gather information matters. Non-intrusive, passive approaches allow organisations to observe their external attack surface from an attacker’s perspective, without deploying agents, touching internal systems, or creating friction with IT, legal, or audit teams. This isn’t about doing less. It’s about being proportionate, safe, and trustworthy by design. Security without intrusion means: - No added load on internal systems - No agents to manage or maintain - No unnecessary compliance concerns - Faster adoption in sensitive environments In highly regulated sectors, security needs to reduce risk, not shift it elsewhere. The real question for security leaders isn’t just what their tools can see. It’s whether they can gain that visibility without increasing risk in the process. How much intrusion does your security tooling really require?

"Why passive scanning matters in regulated markets" In regulated environments, security isn’t just about visibility. It’s about how that visibility is achieved. Financial services, healthcare, government and critical infrastructure organisations all face the same tension: the need to understand external exposure clearly, without introducing additional risk, operational burden, or compliance concerns. That’s where passive scanning matters. Passive approaches observe what’s already publicly visible, without deploying agents, touching internal systems, or creating additional load on IT environments. This isn’t a limitation. It’s a design choice that aligns with how regulated organisations operate. In real-world environments, active scanning and intrusive tooling can: - Create compliance challenges - Trigger operational concerns - Add friction with risk, legal, and audit teams - Slow adoption and onboarding Passive scanning avoids those issues by design. It allows organisations to see their external attack surface from the same perspective an attacker would, continuously, safely, and without interference. In regulated markets, trust, auditability and proportionality matter as much as technical capability. Security tooling needs to support those realities, not work against them. The question isn’t whether you can scan more aggressively. It’s whether you can gain accurate visibility without increasing risk elsewhere. How much consideration does your security tooling give to how it gathers insight, not just what it finds?

Most organisations don't replace ASM tools because they stop working. They replace them because they stop helping. Legacy platforms do what they promise: scan, detect, alert. But teams end up spending more time interpreting results than reducing risk. What we hear from customers: - Too many false positives  - Findings without clear evidence  - Scans too infrequent to reflect reality  - No visibility into the software components running on exposed assets What teams want now: - Meaningful findings, not volume  - Real-time visibility  - Vulnerabilities mapped through the software supply chain - Clear prioritisation of what to fix Replacing a legacy ASM tool isn't about chasing new features. It's about regaining clarity, speed and trust, from the perimeter down to the components running on it. What drives replacement in your experience: noise, speed, usability, or software supply chain visibility?

"ACDS uncovers what others miss." We hear this most often from teams in highly regulated, complex environments, where visibility gaps aren't just inconvenient, they're risky. In sectors like healthcare, exposure can be brief and fragmented. Assets appear and disappear quickly, third-party services change without notice, and traditional tools surface findings too late or buried in noise. The challenge is no longer just which assets are exposed, but which software components are running inside them. A mapped asset inventory still leaves a gap if you don't know which vulnerable packages are sitting on those assets, often introduced by vendors, updates, or AI-assisted commits that no one consciously reviewed. What makes the difference isn't scanning more. It's seeing the right things, at the right time, with evidence teams can trust. When organisations can identify which exposures actually matter, down to the component level: - Remediation happens faster - Noise drops significantly - Confidence in decisions improves - Risk is reduced sooner That's what uncovering what others miss really means. Not more alerts. Better insight, mapped from your external attack surface down through the software supply chain running on it. Where do you see the biggest visibility gaps today: fleeting assets, vulnerable components, or confidence to act?

🌍 Linux Kernel Under Siege: 4 Flaws in 30 Days and the Threat to SSH Host Keys. The Linux ecosystem is facing an unprecedented wave of volatility. The discovery of a fourth critical kernel vulnerability in less than a month has put security teams on high alert. This flaw targets the memory isolation between User Space and Kernel Space, allowing attackers with local or container access to bypass restrictions and exfiltrate SSH host keys directly from the RAM. At ACDS, we see this as the compounding effect of the "Mythos" era: automated, semantic analysis of low-level code is exposing vulnerabilities that remained hidden for decades. Standard EDRs and perimeter defenses are blind to these memory-level, side-channel exploits. See our MD for France's strategic and technical breakdown below. ⬇️