Secnora INC

🛡️ Most software supply chain risk doesn't come from a zero-day. It comes from what was never inventoried, never verified and never monitored.

The biggest software supply chain risks are often the ones teams cannot see hidden dependencies, neglected packages and weaknesses in the build process. These issues can remain unnoticed until they become a security incident.

Every security team should be able to answer these 5 questions about their software supply chain:
🔍 Do you have a complete inventory of every dependency running in production?
👤 Who maintains your most critical packages?
🔐 Can your build pipeline detect malicious packages before deployment?
⚠️ How do you identify abandoned or high-risk dependencies?
⏱️ If a dependency was compromised today, how quickly would you know?

➡️ Swipe through and see how many your team can answer with confidence.

The organizations that stay ahead are not necessarily the ones with the most tools, they are the ones with the clearest visibility into their software supply chain.

🕵️ 𝗛𝗼𝘄 𝗲𝗕𝗣𝗙 𝗥𝗼𝗼𝘁𝗸𝗶𝘁𝘀 𝗪𝗼𝗿𝗸 𝗮𝗻𝗱 𝗪𝗵𝘆 𝗧𝗵𝗲𝘆’𝗿𝗲 𝗛𝗮𝗿𝗱 𝘁𝗼 𝗗𝗲𝘁𝗲𝗰𝘁

Imagine a malware that doesn't modify a single system file, doesn't load a traditional kernel module and yet operates with kernel-level privileges while remaining remarkably difficult to detect.

This marks the rise of eBPF rootkits, a sophisticated class of malware leveraging legitimate kernel features for stealth.

As organizations increasingly adopt Extended Berkeley Packet Filter (eBPF) for observability, performance monitoring and security telemetry, attackers are exploring how the same technology can be abused for stealthy post-compromise operations.

⚠️ 𝗛𝗼𝘄 𝗲𝗕𝗣𝗙 𝗥𝗼𝗼𝘁𝗸𝗶𝘁𝘀 𝗪𝗼𝗿𝗸
Traditional Linux rootkits often rely on Loadable Kernel Modules (LKMs) to hook system calls or modify kernel behavior, techniques that can leave detectable traces. eBPF takes a different approach, allowing programs to run within the Linux kernel in response to events such as system calls, network activity and tracepoints without modifying kernel code or loading a conventional kernel module.

🎯 𝗣𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹 𝗖𝗮𝗽𝗮𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀 𝗼𝗳 𝗠𝗮𝗹𝗶𝗰𝗶𝗼𝘂𝘀 𝗲𝗕𝗣𝗙 𝗣𝗿𝗼𝗴𝗿𝗮𝗺𝘀
In a compromised environment, malicious eBPF programs may be used to:
• Manipulate Data in Real Time: Filter or modify information before it reaches user-space applications, potentially hiding processes, files or network connections.
• Capture Sensitive Information: Observe data as it moves through system workflows, enabling the collection of credentials or other sensitive information.
• Establish Covert Backdoors: Create hidden network triggers that activate malicious functionality only when specific traffic patterns are received.

🔍 𝗪𝗵𝘆 𝗗𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗜𝘀 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗶𝗻𝗴
• Blends with Legitimate Activity: eBPF is widely used for observability and security, making malicious programs harder to distinguish from normal operations.
• Minimal System Footprint: eBPF-based malware can influence kernel behavior without modifying kernel code or system call tables.
• Visibility Gaps: If kernel-level data is altered before reaching user-space, security tools may receive incomplete or misleading telemetry.

🛡️ 𝗗𝗲𝗳𝗲𝗻𝗱𝗶𝗻𝗴 𝗔𝗴𝗮𝗶𝗻𝘀𝘁 𝗲𝗕𝗣𝗙 𝗔𝗯𝘂𝘀𝗲
• Monitor and audit usage of the bpf() system call.
• Regularly inventory loaded eBPF programs using tools such as bpftool.
• Restrict access to capabilities such as CAP_BPF and CAP_SYS_ADMIN.
• Investigate unexpected eBPF program loads, particularly on systems where eBPF is not routinely used.

🔐 As organizations continue to scale cloud-native environments, visibility into and control over kernel-level activity will remain critical to maintaining a strong security posture.

🚨 𝗔𝗿𝗰𝗵 𝗟𝗶𝗻𝘂𝘅 𝗔𝗨𝗥 𝗦𝘂𝗽𝗽𝗹𝘆 𝗖𝗵𝗮𝗶𝗻 𝗖𝗮𝗺𝗽𝗮𝗶𝗴𝗻: ~𝟭𝟱𝟬𝟬 𝗔𝗨𝗥 𝗣𝗮𝗰𝗸𝗮𝗴𝗲𝘀 𝗧𝗮𝗿𝗴𝗲𝘁𝗲𝗱 𝗳𝗼𝗿 𝗖𝗿𝗲𝗱𝗲𝗻𝘁𝗶𝗮𝗹 𝗧𝗵𝗲𝗳𝘁 𝗮𝗻𝗱 𝗲𝗕𝗣𝗙 𝗣𝗲𝗿𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝗲

A sophisticated supply chain campaign targeting the Arch User Repository (AUR) has affected ~1500 packages. The operation leveraged trusted package takeovers to distribute credential-stealing malware and stealthy eBPF persistence mechanisms, demonstrating how trusted community packages can become an attack vector.

🎯 𝗧𝗵𝗲 𝗩𝗲𝗰𝘁𝗼𝗿: 𝗘𝘅𝗽𝗹𝗼𝗶𝘁𝗶𝗻𝗴 𝗨𝗻𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗲𝗱 𝗣𝗮𝗰𝗸𝗮𝗴𝗲𝘀
Threat actors are bypassing traditional typosquatting. Instead, they are systematically identifying and claiming unmaintained community packages through the official AUR stewardship process. By doing so, they inherit the historical legitimacy and established user base of the package, silently evading community suspicion without needing to forge Git history.

🛠️ 𝗧𝗵𝗲 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻: 𝗪𝗲𝗮𝗽𝗼𝗻𝗶𝘇𝗶𝗻𝗴 𝗟𝗼𝗰𝗮𝗹 𝗖𝗼𝗺𝗽𝗶𝗹𝗮𝘁𝗶𝗼𝗻
Because AUR packages are compiled on the user's system, the build process becomes a key attack surface. Threat actors modify PKGBUILD scripts and install hooks to fetch rogue dependencies during compilation using tools such as npm or bun. These dependencies can execute Rust-based infostealers through pre-install scripts before the software build is completed.

💰 𝗧𝗵𝗲 𝗣𝗮𝘆𝗹𝗼𝗮𝗱: 𝗛𝗶𝗴𝗵-𝗣𝗿𝗶𝘃𝗶𝗹𝗲𝗴𝗲 𝗖𝗿𝗲𝗱𝗲𝗻𝘁𝗶𝗮𝗹 𝗛𝗮𝗿𝘃𝗲𝘀𝘁𝗶𝗻𝗴
The Rust-based infostealer is designed to harvest high-value engineering assets including SSH keys, VPN profiles, DevOps tokens, cloud credentials and active session cookies from platforms such as Slack, Teams and Discord, enabling access to infrastructure and potentially bypassing MFA protections.

🕵️ 𝗧𝗵𝗲 𝗘𝘀𝗰𝗮𝗹𝗮𝘁𝗶𝗼𝗻: 𝗞𝗲𝗿𝗻𝗲𝗹-𝗟𝗲𝘃𝗲𝗹 𝗲𝗕𝗣𝗙 𝗦𝘁𝗲𝗮𝗹𝘁𝗵
One of the most concerning aspects of this campaign is its persistence mechanism. When executed with root privileges, the payload can deploy an eBPF rootkit, scales[.]bpf[.]c, that operates within the Linux kernel to hide processes, network activity and files, reducing the visibility of standard user-space security tools.

🛡️ 𝗜𝗺𝗺𝗲𝗱𝗶𝗮𝘁𝗲 𝗗𝗲𝗳𝗲𝗻𝘀𝗶𝘃𝗲 𝗔𝗰𝘁𝗶𝗼𝗻𝘀
• Audit Engineering Nodes: Review Arch-based developer workstations and build servers for recently updated AUR packages and unexpected npm/bun activity during builds.
• Rotate Secrets: If indicators of compromise are detected, immediately rotate SSH keys, cloud credentials and CI/CD secrets.
• Rebuild Affected Hosts: Systems that compiled compromised packages with root privileges should be considered untrusted and rebuilt from a clean baseline.

💡 𝗧𝗵𝗲 𝗛𝗶𝗱𝗱𝗲𝗻 𝗖𝗼𝘀𝘁 𝗼𝗳 𝗗𝗲𝗹𝗮𝘆: 𝗧𝗵𝗲 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻 𝗙𝗲𝗹𝘁 𝗥𝗲𝗮𝘀𝗼𝗻𝗮𝗯𝗹𝗲 𝗨𝗻𝘁𝗶𝗹 𝘁𝗵𝗲 𝗖𝗼𝘀𝘁 𝗕𝗲𝗰𝗮𝗺𝗲 𝗩𝗶𝘀𝗶𝗯𝗹𝗲

Many security decisions that become costly in hindsight were entirely understandable when they were made.

The organisation had competing priorities and finite resources. Security was one of many important considerations and the risk appeared manageable because there was no clear indication that immediate action was required.

🔐 The identity review was deferred.
📋 The vendor assessment moved to next quarter.
🧯 The incident response plan remained untested.

None of these felt like significant concerns at the time. They were practical decisions made in the context of competing business priorities and limited resources.

That is the quiet nature of security risk.

Risk rarely announces itself when decisions are being made. It builds gradually in the background until circumstances change and its impact becomes impossible to ignore. Security leaders are often required to make decisions with incomplete information while balancing business objectives, operational demands and resource constraints.

Security risk is inherently asymmetric. ⚖️

The cost of acting early is visible: budget, time and organisational effort.
The cost of acting later often remains hidden until it becomes much more difficult and expensive to address.

The organisations that navigate this well are not necessarily the ones that avoid every risk, they are the ones that create greater visibility around their decisions.

🔹 Regular independent reviews of the security programme.
🔹 Risk discussions framed in business terms rather than purely technical metrics.
🔹 Leadership teams that understand the potential impact of deferred security initiatives and evaluate them in measurable terms.

The goal is not perfection, it is awareness.

Every decision made today will eventually be viewed through the lens of information that is not yet available. That awareness does not eliminate difficult trade-offs, it helps organisations make them with greater clarity and confidence.

The most expensive security challenges often begin as decisions that seemed entirely reasonable at the time. That is exactly why they deserve attention before their cost becomes visible. 🔐

🚨 𝗧𝗵𝗲 𝗖𝗵𝗮𝗿𝘁𝗲𝗿 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁: 𝗛𝗼𝘄 𝗜𝗱𝗲𝗻𝘁𝗶𝘁𝘆 𝗖𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲 𝗘𝗻𝗮𝗯𝗹𝗲𝗱 𝗦𝗮𝗮𝗦 𝗗𝗮𝘁𝗮 𝗘𝘅𝗽𝗼𝘀𝘂𝗿𝗲

The Charter Communications (Spectrum) incident is a reminder that modern attacks often start with a compromised identity, not a technical exploit. By leveraging social engineering, the attackers gained access to a trusted account and ultimately reached sensitive data stored in cloud applications. As businesses become increasingly SaaS-driven, identity security is no longer just an access control issue. It is a critical component of data protection.

📋 𝗧𝗶𝗺𝗲𝗹𝗶𝗻𝗲 𝗮𝗻𝗱 𝗜𝗺𝗽𝗮𝗰𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁
In May 2026, the threat actor group "ShinyHunters" listed Charter on its leak site after a failed "pay or leak" ransom demand. While the attackers claimed to have stolen more than 42 million records, analysis of the leaked data showed:
• Approximately 4.9 million unique email addresses were exposed
• Customer names, phone numbers, email addresses and physical addresses were included
• Around 85,000 records came from an internal employee directory, exposing employee job titles
• Charter Communications later confirmed the incident and stated that highly sensitive personal information and Customer Proprietary Network Information (CPNI) were not exfiltrated.

🎯 𝗔𝗻𝗮𝘁𝗼𝗺𝘆 𝗼𝗳 𝘁𝗵𝗲 𝗔𝘁𝘁𝗮𝗰𝗸 𝗩𝗲𝗰𝘁𝗼𝗿
This incident did not involve a sophisticated network exploit or a zero-day vulnerability. Instead, it followed a highly practical and increasingly common playbook:
• Social Engineering (Vishing): The attack began with a voice phishing campaign targeting a Charter employee.
• Identity Compromise: The attackers successfully gained access to a Microsoft Entra account through the human element.
• Cloud and SaaS Access: Using a legitimate identity, the attackers bypassed traditional security controls and accessed sensitive data within Salesforce.

🛡️ 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀 𝗳𝗼𝗿 𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆
Attackers are no longer just breaking into networks, they are logging in. To reduce the risk of identity-driven attacks:
• Adopt Phishing-Resistant MFA: Replace SMS and push-based MFA with FIDO2 or WebAuthn to reduce the risk of credential theft and social engineering attacks.
• Strengthen SaaS Data Governance: Identity security must extend beyond login. Implement DLP controls and monitor for unusual data exports or bulk downloads from platforms like Salesforce.
• Harden Help Desk Verification Processes: Use out-of-band verification to secure password resets, MFA updates and account recovery requests.
• Monitor for Identity-to-SaaS Lateral Movement: Track authentication events, privilege changes and unusual SaaS activity to identify compromised accounts.

🚨 𝗧𝗵𝗲 𝗗𝗲𝗻𝘁𝗮𝗤𝘂𝗲𝘀𝘁 𝗕𝗿𝗲𝗮𝗰𝗵: 𝗛𝗼𝘄 𝗧𝗵𝗿𝗲𝗮𝘁 𝗔𝗰𝘁𝗼𝗿𝘀 𝗧𝘂𝗿𝗻 𝗜𝗱𝗲𝗻𝘁𝗶𝘁𝘆 𝗘𝘅𝗽𝗹𝗼𝗶𝘁𝗮𝘁𝗶𝗼𝗻 𝗶𝗻𝘁𝗼 𝗟𝗮𝗿𝗴𝗲-𝗦𝗰𝗮𝗹𝗲 𝗗𝗮𝘁𝗮 𝗘𝘅𝗽𝗼𝘀𝘂𝗿𝗲

With millions of records reportedly affected, the DentaQuest breach has drawn significant attention across the healthcare and cybersecurity sectors. The exposure of sensitive healthcare and personal data highlights the potential consequences of large-scale data breaches and the importance of strong identity and access controls.

🔴 𝗪𝗵𝗮𝘁 𝗛𝗮𝗽𝗽𝗲𝗻𝗲𝗱?
The threat group ShinyHunters claimed responsibility for a breach involving DentaQuest, a Sun Life subsidiary and one of the largest dental benefits administrators in the US. The group subsequently published what it described as a ~234 GB dataset on its leak site following unsuccessful extortion attempts. On June 3, 2026, Have I Been Pwned indexed the breach, reporting approximately 2.6 million unique email addresses and associated records as exposed.

📂 𝗪𝗵𝗮𝘁 𝗪𝗮𝘀 𝗘𝘅𝗽𝗼𝘀𝗲𝗱?
This was a highly structured compromise of Protected Health Information (PHI) and PII, containing:
• Core PII: Full names, dates of birth, phone numbers, unique emails and physical home addresses.
• Medical Identity: Health insurance details and Medicaid IDs.
• Systemic Files: Healthcare enrollment files (ASC X12 transaction sets).

🧠 𝗧𝗵𝗲 𝗙𝗼𝗼𝘁𝗽𝗿𝗶𝗻𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗔𝘁𝘁𝗮𝗰𝗸
While the exact intrusion path remains unknown, the incident reflects trends commonly seen in modern data theft operations:
• Identity-Focused Access: Public reporting has not confirmed the initial access vector. However, large-scale data theft campaigns increasingly rely on compromised credentials, session abuse or other forms of identity compromise rather than disruptive malware.
• Large-Scale Data Exfiltration: ShinyHunters claimed to have obtained hundreds of gigabytes of data from DentaQuest. While the technical details remain undisclosed, the reported volume suggests access to substantial repositories of sensitive information.

✅ 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀
• Credential Theft is the New Malware: Firewalls are useless if the attacker has a valid password. Phishing-resistant MFA like FIDO2 or WebAuthn is no longer an upgrade, it is a baseline survival requirement.
• Audit Your SaaS & Identity Ecosystem: Threat actors actively exploit third-party OAuth grants, stale session tokens and legacy entry points to maintain stealthy persistence.
• Lock Down Structured Data: Know exactly where raw enrollment files, EDI transactions and database backups live. Restrict access rigidly by role, not just by network location.
• Prepare for Data Exposure: In some cases, stolen data may be published following unsuccessful extortion attempts. Response plans should account for potential legal, regulatory and communications requirements.

Zero Trust sounds simple. 🔐

“Never trust, always verify.”

But in real cybersecurity work, it is much more than a slogan.

In the new episode of the Secure by Design Podcast by Secnora, Daniel Kulig hosts cybersecurity expert Adeel Shaikh Muhammad for a practical conversation about the realities, myths, and marketing hype surrounding Zero Trust security. 🎙️

They discussed:

🔹 why Zero Trust matters in modern cybersecurity
🔹 how organizations can implement it effectively
🔹 where the biggest myths and buzzwords show up
🔹 why leadership matters as much as technology
🔹 how AI is changing the Zero Trust journey

One of the strongest takeaways from the episode:

Zero Trust is not just a product you buy. ⚠️

It is a security mindset, operating model, and leadership discipline that needs to be built into the organization over time.

Adeel brings a very practical, no-nonsense perspective to the topic, cutting through the buzzwords and focusing on what actually matters. 💡

Listen to the episode on Spotify here:
👉 https://open.spotify.com/episode/1i79d54ZOKbhrPWVW403tS

Watch, subscribe to Secure by Design, and share it with someone who still thinks Zero Trust is just another vendor buzzword.

Let’s make some commotion around better cybersecurity conversations. 🚀

🛡️ August 2, 2026 is the next major enforcement date under the EU AI Act.

Most teams are tracking it for high-risk systems. Fewer realise the same date triggers Article 50 transparency obligations and those apply to any AI system that interacts with people, generates content or uses biometric data, whether or not it's high-risk.

No disclosure when a user talks to your chatbot? Violation.
Emotion recognition with no transparency notice? Violation.

And these breaches aren't a footnote - they sit in the €15M / 3%-of-turnover penalty tier.

This carousel breaks down what Article 50 actually requires, what your team needs in place before August 2 and how existing frameworks like NIST AI RMF already get you part of the way there.

➡️ Swipe through, then check where your organisation actually stands. The deadline isn't the hard part - not knowing what to do is.

🚨 𝗧𝗵𝗲 𝗖𝗮𝗿𝗻𝗶𝘃𝗮𝗹 𝗗𝗮𝘁𝗮 𝗕𝗿𝗲𝗮𝗰𝗵: 𝗛𝗼𝘄 𝗟𝗲𝗴𝗶𝘁𝗶𝗺𝗮𝘁𝗲 𝗖𝗿𝗲𝗱𝗲𝗻𝘁𝗶𝗮𝗹𝘀 𝗢𝗽𝗲𝗻𝗲𝗱 𝘁𝗵𝗲 𝗗𝗼𝗼𝗿 𝘁𝗼 𝗗𝗮𝘁𝗮 𝗧𝗵𝗲𝗳𝘁

The Carnival Data Breach highlights a common attack pattern involving social engineering, unauthorized account access, and the copying of personal information. The incident reinforces a key security reality, when attackers operate through trusted identities, traditional perimeter defenses offer limited visibility, shifting the focus toward identity protection, behavioral analytics and continuous monitoring.

🔑 𝗜𝗻𝗶𝘁𝗶𝗮𝗹 𝗔𝗰𝗰𝗲𝘀𝘀: 𝗦𝗼𝗰𝗶𝗮𝗹 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗮𝗻𝗱 𝗖𝗿𝗲𝗱𝗲𝗻𝘁𝗶𝗮𝗹 𝗖𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲
The incident began on April 14, 2026, when an unauthorized actor used social engineering to deceive an employee and gain access to a limited portion of Carnival's IT environment. By leveraging a compromised account, the threat actor was able to operate using legitimate credentials, making detection more challenging and reducing the effectiveness of traditional perimeter-based security controls.

📤 𝗕𝗿𝗲𝗮𝗰𝗵 𝗧𝗶𝗺𝗲𝗹𝗶𝗻𝗲 𝗮𝗻𝗱 𝗗𝗮𝘁𝗮 𝗘𝘅𝗳𝗶𝗹𝘁𝗿𝗮𝘁𝗶𝗼𝗻
• April 14, 2026: Carnival's security team detected unauthorized activity associated with the compromised account and blocked access.
• April 22, 2026: Forensic investigators confirmed that a limited portion of company data had been exfiltrated before containment measures took effect
• May 27, 2026: Carnival began notifying affected individuals, offering two years of complimentary TransUnion credit monitoring to eligible U.S. individuals.

🗂️ 𝗗𝗮𝘁𝗮 𝗘𝘅𝗽𝗼𝘀𝘂𝗿𝗲 𝗔𝘀𝘀𝗲𝘀𝘀𝗺𝗲𝗻𝘁
Carnival stated that its analysis of the impacted data is ongoing and that the information affected may vary by individual. Based on findings identified to date, the impacted data is known to include personal information and government-issued identification data including:
• Full names and addresses
• Email addresses and phone numbers
• Dates of birth
• Passport numbers
• Driver's license numbers

🛡️ 𝗗𝗲𝗳𝗲𝗻𝘀𝗶𝘃𝗲 𝗟𝗲𝘀𝘀𝗼𝗻𝘀 𝗳𝗼𝗿 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗧𝗲𝗮𝗺𝘀
While Carnival has not disclosed the full technical details of the intrusion, the incident highlights several defensive priorities:
• Identity-Centric Security: Deploy phishing-resistant MFA such as FIDO2 or WebAuthn to reduce credential theft risks.
• Behavioral Analytics: Use UEBA to detect anomalous logins, access patterns and suspicious account activity.
• Data Loss Prevention: Monitor for mass downloads, unusual file access and unauthorized data transfers.
• Data Discovery & Segmentation: Identify sensitive data repositories and apply stronger access controls and monitoring.
• Assume Identity Compromise: Focus detection on user behavior, privilege misuse and data movement, not just authentication events.

🛡️ 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗶𝗺𝗽𝗿𝗼𝘃𝗲𝗺𝗲𝗻𝘁 𝗶𝘀 𝗼𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗵𝗮𝗿𝗱𝗲𝘀𝘁 𝘁𝗵𝗶𝗻𝗴𝘀 𝘁𝗼 𝗺𝗮𝗸𝗲 𝘃𝗶𝘀𝗶𝗯𝗹𝗲

Not because it is not happening but because the strongest evidence of progress in security is often the absence of something, the incident that never occurred, the access that was stopped before it was abused, the vulnerability that was remediated before someone else found it.

That makes conversations around security progress genuinely difficult.

Leadership teams want to see progress, Security leaders need to demonstrate it. Yet many of the numbers commonly reported in security programmes, such as vulnerabilities identified, patches applied and controls marked compliant, say little about how much harder the organisation is to compromise.

The more important question is "Is the organisation systematically becoming harder to compromise over time?"

In many organisations, the early warning signs are subtle at first.

Remediation backlogs begin growing faster than teams can close them. Incidents are identified externally before internal teams detect them. Access reviews happen once a year or sometimes less. Incident response plans exist on paper but have never been tested under real pressure. Third-party risk assessments are completed during onboarding and quietly forgotten afterward.

Security reporting continues upward but very little of it influences operational decisions on the ground. Over time, programmes that begin gaining traction start to look noticeably different.

📈 Mean time to remediate trends downward across consecutive quarters
🔍 Incidents are detected earlier in the attack chain by internal teams
🔄 Access reviews run on a defined cycle with documented outcomes
🧪 Tabletop exercises expose gaps that are actually addressed afterward
🤝 Third-party risk gets reassessed during renewals and scope changes
📊 Security data starts driving decisions instead of simply satisfying reporting requirements

The shift between those two states is rarely dramatic. It does not come from a single engagement, tool deployment or investment. It comes from consistent, structured improvement and from measuring what matters rather than what is easiest to report.

Over time, the real indicator of progress is not the number of findings reported, it is whether attackers have fewer opportunities, less room to move and a harder time succeeding than they did six months earlier.

That kind of improvement is not always obvious while it is happening but when organisations begin detecting threats earlier, reducing remediation delays and turning security insights into action, the difference becomes visible, not just in reports or audits but in how resilient the environment becomes under real conditions.

🎯 The gap between security effort and visible progress is often smaller than it seems but harder to measure clearly.