On October 20, 2026, the PHP security team issued an advance security advisory regarding two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affecting core PHP source code. Both vulnerabilities carry a critical-severity CVSS v4.0 score of 9.2 and could potentially allow unauthenticated remote code execution (RCE) on affected servers.

The official patched PHP releases are now available. Given the potential impact across web applications, content management systems (CMS), and microservices running PHP, Detectify recommends immediate asset discovery and patching.

What is the risk?

While specific technical implementation details remain under embargo, early advisories indicate:

• Unauthenticated Remote Code Execution (RCE): Both vulnerabilities allow remote attackers to execute arbitrary code on the underlying host operating system without prior authentication.
• Broad impact: Security advisories highlight that these flaws potentially affect all supported release branches and legacy environments (including PHP 5.x through 8.x).
• High attractiveness to attackers: Because PHP powers a vast majority of the public web, including platforms like WordPress, Drupal, Magento, and custom Laravel/Symfony applications, public exploit payloads are expected to follow shortly after official technical details are disclosed.

What are we doing?

The Detectify Security Research team is actively monitoring the situation:

• Detectify has deployed five distinct scanning assessments to detect CVE-2026-109618 and CVE-2026-109619 across customer attack surfaces.
  These security tests combine insights from early public proofs-of-concept (PoCs) alongside internal research using unique detection methods, and they utilize safe, non-destructive detection mechanisms rather than proving full RCE execution chains. Our research team continues to iterate on both general and technology-specific modules to maximize coverage.
• Asset discovery: Detectify’s Surface Monitoring continuously maps internet-facing assets running PHP web applications, helping security teams locate shadow or legacy PHP workloads.

How to mitigate the threat

IMPORTANT NOTICE: The temporary measures and configuration adjustments listed below only reduce exposure surface vectors. Only applying the official PHP patch or upgrading to a secure version will mitigate these vulnerabilities.

To ensure your organization remains protected, we recommend taking the following steps immediately:

1. Upgrade your PHP installation: Upgrade your environment to the latest patched version for your respective branch:

• PHP 8.2: Upgrade to 8.2.35
• PHP 8.3: Upgrade to 8.3.36
• PHP 8.4: Upgrade to 8.4.27
• PHP 8.5: Upgrade to 8.5.12
  

Note on legacy/EOL releases: Given the severity of these vulnerabilities, the PHP security team has provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to assist teams building directly from source or operating without access to an LTS vendor. Otherwise, organizations running End-of-Life (EOL) versions should look for distribution backports (e.g., from OS vendors like Ubuntu or RHEL) or migrate immediately to supported 8.x branches.

2. Temporary Exposure Minimization Measures: If immediate upgrading is delayed, apply the following hardening steps to reduce risk vectors across vulnerable runtimes:

A. Mitigating RCE via OOM Corruption (CVE-2026-109618)

• Set unlimited memory limits: Set memory_limit=-1 via administrative configuration (e.g., php_admin_value in FPM pools or Apache config) so applications cannot override it. Confirm that no downstream pool, directory, or application settings re-impose a finite limit. Note: This prevents user-controllable PHP memory limit failures, though system-level allocation failures can still hit the vulnerable path.
• Restrict request payloads: Lower post_max_size (e.g., 8M for non-upload applications, 32M if uploads are required). Ensure upload_max_filesize remains strictly below post_max_size. Enforce limits at the web server or proxy layer for decoded request sizes, input field counts, multipart part counts, header counts, and nesting depth—including requests lacking a usable Content-Length.
• Enforce availability boundaries: Use container or cgroup limits with policies designed to kill only the affected worker. Avoid relying on RLIMIT_AS or RLIMIT_DATA, as these can directly trigger the vulnerable allocation failure.

B. Mitigating RCE via Stale Global State (CVE-2026-109619)

• Disable Session Upload Progress: Set session.upload_progress.enabled=0 via global php.ini, FPM pool, or server configurations applied prior to request parsing (do not rely on ini_set() or .user.ini). Restart all workers afterwards.
• Disable backtraces (PHP 8.5): If running PHP 8.5, set fatal_error_backtraces=0 and restart workers to disable the confirmed fatal backtrace path.
• Clean up diagnostics & configuration: Remove invalid or deprecated per-request settings that generate diagnostic output before initialization completes. (Hiding outputs using error_reporting, display_errors, or @ does not prevent the vulnerability).
• Address fatal triggers: Resolve reachable fatal errors and execution timeouts, including failure points in callbacks, file uploads, import processing, or cleanup logic.

3. Inventory internet-facing assets: Use Detectify to run an asset discovery scan to identify all exposed HTTP service endpoints and web applications running on PHP.

4. Deploy patches across pipelines: Ensure application owners and infrastructure operators pull updated PHP packages from upstream package managers (Debian, Ubuntu, RHEL, Docker Hub, etc.).

5. Isolate high-risk services: If immediate patching is not possible, temporarily isolate vulnerable application servers behind access-controlled gateways or Web Application Firewalls (WAFs) with strict filtering enabled.

References & official advisories

PHP Security Release Announcement (2026-10-21-5)
PHP Foundation Announcement Archive (2026-10-20-1)
CERT-EU Security Advisory 2026-018

The post Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619) appeared first on Blog Detectify.

If your application security program only tracks known Common Vulnerabilities and Exposures (CVEs), you’re probably missing a large share of your real risk.

Across the Detectify platform, 75% of the vulnerabilities in our test catalog and 99% of those we discover in customers’ assets are non-CVE vulnerabilities.

That makes public disclosures a poor measure of coverage on a modern attack surface. Below, we look at why so many vulnerabilities never get a CVE and how Detectify finds both kinds.

Why do some vulnerabilities have no CVE?

The CVE program is a foundation of the security industry, but it was built to catalog flaws in distributed software. A lot of what goes wrong in cloud-native web applications falls outside that scope, and scanners that lean mostly on CVE databases tend to miss it for a few reasons.

• Custom code and SaaS flaws. Bugs in custom web apps, business logic, path-based cross-site scripting (XSS) or specific software configurations rarely get a public CVE ID, since there’s often no vendor product to file them against.
• Slow disclosure. Getting a CVE assigned involves vendor coordination, triage, and paperwork. By the time it’s published and someone writes a public scanner template, attackers may have been using the flaw for weeks.
• Misconfigurations and subdomain takeovers. SSL/TLS hostname mismatches, expired certificates, and dangling DNS records are serious risks, yet they generally don’t qualify for a CVE.
• Too much weight on CVSS scores. When vulnerability management is sorted by CVSS, engineers end up chasing high-scoring CVEs that may have no working exploit, while exploitable issues without a CVE go unnoticed.

How Detectify sources vulnerabilities

To close that gap, Detectify feeds three research sources into one payload-based scan engine:

• Detectify Crowdsource, our private network of ethical hackers, which supplies most of our novel and non-CVE research.
• Our internal security research team, which digs into complex systems, API frameworks and new threat vectors, and builds specialized fuzzing logic.
• Alfred, our AI security researcher, which turns public CVE disclosures into automated tests.

1. Detectify Crowdsource

Most of our non-CVE detection starts with Detectify Crowdsource, an invite-only community of ethical hackers and security researchers from around the world. Here’s how it works:

• A researcher finds a new attack technique or zero-day in the wild and submits it to Detectify.
• Our team turns the submission into an automated, payload-based scanning module.
• Each time that module finds a vulnerability on a customer asset, the researcher who submitted it gets paid. Researchers earn more when their work protects more systems, which keeps everyone focused on coverage that matters in practice.

2. In-house security research

Our security research team spends its time on emerging web technologies, API frameworks and new kinds of attack surface. They write fuzzing logic and detection modules for the subtle issues that signature-based scanners tend to overlook.

3. Alfred, our AI security researcher

Public disclosures arrive faster than any human team can process them, so Alfred handles the volume. It continuously ranks newly disclosed CVEs by exploit likelihood (EPSS), relevance to customer assets, and threat actor intelligence. This means that CVEs that active groups are exploiting right now will receive coverage first. Alfred AI then analyzes public proofs of concept, turning them into payload-based tests crafted for Detectify. At the end of the procesa human researcher reviews every test before it goes live.

How does payload-based testing reduce false positives?

Finding non-CVE vulnerabilities only helps if your team can act on the results. Many CVE scanners rely on version-string matching, for example, flagging a server because its banner reports an outdated Apache version. That approach produces a lot of false positives.

Detectify uses payload-based testing instead. We only report a vulnerability after a safe payload runs successfully and proves the issue can be exploited. Your team gets high-confidence alerts with clear next steps, whether or not the finding has a CVE identifier.

The fix ships with the test

Every finding comes with a risk level, a description and references so your team can prioritize. For new critical and high-severity vulnerabilities, our researchers write remediation guidance at the same time as the test, so your engineers get a concrete fix instead of a link to a Wikipedia article. For older tests, Alfred is backfilling remediation across the catalog. And if your team needs a hand, our customer success team works as an extension of yours.

Looking past the CVE list

When you stop treating the CVE list as the full picture, you cut down on noisy false positives and start covering the 75% of vulnerabilities that public databases never catalog.

How to detect non-CVE vulnerabilities

To detect non-CVE vulnerabilities, you need to test how your applications actually behave, cover every asset you expose, and use research sources beyond public CVE feeds. These five steps cover the essentials:

1. Test with real payloads instead of software version checks. Send safe payloads that try to exploit the vulnerability, and only treat a finding as confirmed when the payload works. Version matching can only flag issues that already have a CVE.
2. Map your full external attack surface, including forgotten subdomains and root domains. You can’t test assets you don’t know about, and old marketing sites, staging environments and acquired domains are common places for unpatched issues.
3. Monitor DNS for dangling records that allow subdomain takeovers. A DNS record that still points to a deleted cloud resource lets an attacker claim that resource and serve content from your domain.
4. Bring in research from outside CVE feeds, such as ethical hackers and in-house research. New attack techniques are often known to researchers months before a CVE is published, if one is published at all.
5. Prioritize by exploitability, not CVSS score alone. A confirmed, exploitable misconfiguration deserves more attention than a high-scoring CVE with no working exploit.

FAQ

What is a non-CVE vulnerability?

A non-CVE vulnerability is a security flaw that has no entry in the public CVE database. Common examples include business logic bugs in custom applications, misconfigurations, expired certificates and subdomain takeovers caused by dangling DNS records.

Are non-CVE vulnerabilities less dangerous than CVEs?

Not necessarily. Whether a flaw has a CVE says nothing about how severe it is. A subdomain takeover or a logic flaw in a login flow can be just as damaging as a critical CVE, and it may stay exposed longer because fewer tools look for it.

Why don’t standard scanners find them?

Many scanners match software versions against CVE databases. If a flaw has no CVE, or lives in code that only your organization runs, there’s nothing for the scanner to match against.

How does Detectify find vulnerabilities that have no CVE?

Most of our non-CVE coverage comes from Detectify Crowdsource, where ethical hackers submit new techniques that we turn into automated tests. Our internal research team adds detection for new technologies and attack surfaces.

How does Detectify avoid false positives?

We use payload-based testing. A finding is only reported after a safe payload proves the vulnerability can be exploited, which removes most of the guesswork that comes with version matching.

The post How to detect non-CVE vulnerabilities that standard scanners miss appeared first on Blog Detectify.

The Detectify Cyber Hygiene Index Report H2 2026 measures something most reports ignore: not what happened after an attack, but what’s exposed right now, before one occurs. We analyzed anonymized data from a sample of +1290 organizations across the US, UK, and Nordics to understand how effectively they’re finding, monitoring, and closing vulnerabilities across their external attack surfaces.

The findings reveal a pattern: 97% of open critical and high-severity vulnerabilities in the Nordics have remained exposed for over 90 days. In the UK, that’s 92%. Even in the best-performing market, the US, it’s 86%. Our findings point towards stalling remediation rather than failing detection.

Visibility doesn’t fix vulnerabilities

The UK monitors 72% of its verified attack surface (more than double the rate in the US and Nordics). That’s strong visibility. Yet the UK has the lowest vulnerability resolution rate of the three markets. The contrast is revealing: organizations can be excellent at finding exposure and terrible at closing it. These are separate skills, and most teams are unbalanced.

The US has the opposite problem. We measured the largest attack surface in the Index, yet only 29% of it is actively monitored. Worse, that attack surface grew 20% in a single year. Organizations are spinning up infrastructure faster than they can see it, let alone secure it.

Backlogs don’t predict response speed

Consumer brands carry the heaviest vulnerability backlogs of any sector, yet they resolve critical and high-severity findings at 46.2%, the fastest rate in the Index. Public-sector organizations resolve just 8.3%. The lesson: the size of your backlog tells you nothing about how fast you’ll fix your worst problems. One sector is drowning but moving. The other isn’t.

Manufacturing is the only sector to perform well across every market with sufficient data. Tech companies struggle with asset completeness. Financial institutions vary sharply by geography. The index shows that cyber hygiene isn’t a single problem to solve, it’s the ability to connect visibility, prioritization, and remediation across an attack surface that won’t stop changing.

AI exposure is slowing fixes

We’re seeing an emerging threat: publicly exposed self-hosted AI platforms and AI-built applications scattered across production networks. Early signs point that organizations with exposed AI tooling resolve critical and high-severity vulnerabilities at less than half the rate of the broader customer base. It’s not clear whether this is a staffing problem, a prioritization problem, or AI projects just landing in security-blind spots. Either way, it’s a compounding risk as AI adoption accelerates.

What this means

Nine in ten critical and high-severity vulnerabilities currently exposed have been sitting there for more than 90 days, which points to an execution problem, it being ownership, remediation resourcing, or risk tolerance that drifts until unaddressed vulnerabilities become accepted defaults.

Because these specific assessments test real-world exploitability through 100% payload-based methodology, organizations know these backlog vulnerabilities are verified risks. However, a delayed fix does not always signal inaction; a technically critical vulnerability on a low-sensitivity asset or behind compensating controls may reflect a calculated business decision to deprioritize risk based on internal context.

The data suggests that the harder test of cyber hygiene increasingly comes after discovery. Finding exposure is necessary, but closing it is harder.

Read and download the report here to discover sector breakdowns, cross-market findings, and many other insights.

The post Detectify Cyber Hygiene Index Report reveals that most critical vulnerabilities sit unfixed for months appeared first on Blog Detectify.

When modern development teams and AI agents ship code at unprecedented speeds, the runtime security checkpoint becomes an indispensable line of defense. However, far too many AppSec teams find themselves drowning in a sea of false positives, overburdened by legacy tools that infer potential vulnerabilities rather than proving their real-world exploitability.

This month, we are proud to announce that Detectify has been positioned as a Major Player in the IDC MarketScape: Worldwide Dynamic Application Security Testing (DAST) 2026 Vendor Assessment (Doc #US54119126, September 2026). In our view, this recognition underscores a fundamental shift occurring across the industry: modern security leaders require verified, actionable intelligence that closes the gap between security policy and operational reality.

The market context

In an increasingly AI-driven development ecosystem where code generation moves faster than human oversight can track, dynamic application security testing (DAST) has transitioned from a routine check to a foundational operational requirement. As engineering teams integrate AI coding assistants into their daily workflows, the sheer volume and velocity of code reaching production increases the probability that subtle security flaws bypass earlier static analysis and design-phase reviews. In this fast-evolving landscape, DAST functions as an essential runtime backstop, continuously evaluating live applications to surface genuine, exploitable risks before malicious actors can discover them.

When software moves to production at such relentless speeds, the precision and exploitability of a security finding matter just as much as how quickly that finding is identified.

The problem with inference

Legacy DAST solutions predominantly rely on passive inference, matching version strings, fingerprinting software stacks, and inferring vulnerabilities based on superficial response headers. While an inferred match might alert you to an outdated component, it fails to determine whether that component is actually reachable, exploitable, or dangerous within your specific environment and data architecture.

This reliance on inference creates a crushing operational burden for security analysts, who are forced to manually triage and re-verify every alert before passing it to engineering teams. When developers receive noisy, unconfirmed alerts, accountability breaks down; conversely, when developers receive payload-verified findings, they take immediate ownership of the fix.

To eliminate this friction, Detectify validates findings through active exploitation rather than passive guesswork. By submitting crafted payloads and requiring observable, confirming evidence (such as out-of-band callbacks or query-disclosing database errors) before an alert is ever generated, Detectify ensures that every reported issue represents demonstrated, actionable risk.

When a finding arrives with definitive proof attached, developers can act immediately without re-investigation or time-consuming alignment meetings.

Three capabilities we built for scale

Validated Exploitation Over Inference

By executing active payloads that require undeniable, observable proof prior to reporting, Detectify transforms vulnerability discovery from a speculative exercise into a high-confidence diagnostic tool. For enterprise AppSec teams managing massive environments, this distinction is critical, as it eliminates the investigative overhead that typically stalls remediation and collapses the delay between vulnerability discovery and resolution.

AI Research That Outpaces Emerging Threats

Rather than waiting for public CVE disclosures to be cataloged, we proactively generate detection modules through Alfred, Detectify’s proprietary AI research agent. Alfred continuously analyzes threat intelligence feeds and hacker-submitted proofs of concept, converting novel exploit techniques into production-ready scanning engines long before they hit traditional databases. This intelligence is complemented by an adaptive ML-trained fuzzer that tailors payload selection specifically to each organization’s unique technology stack based on historical environmental data.

Automated Discovery That Scales with Your Attack Surface

As organizations expand, their external attack surface continuously shifts through new subdomains, cloud deployments, corporate acquisitions, and shadow IT. Traditional tools demand constant manual configuration to keep pace with these changes, creating administrative overhead that compounds as the business grows. Detectify solves this through Surface Monitoring, which automatically discovers, deduplicates, and promotes newly exposed assets into scannable targets without requiring human intervention, allowing security coverage to scale effortlessly alongside your expanding digital footprint.

Who this matters for

This capability model is built specifically for organizations operating centralized, AppSec-led security programs that need to oversee broad and constantly shifting attack surfaces. By automating asset discovery and enforcing strict payload validation, Detectify allows enterprise security leaders to maintain complete visibility and continuous testing across their environments without ballooning operational costs or adding friction to developer workflows.

What this means

As application architectures become more complex and development speeds continue to accelerate, static and inference-based security testing models are reaching their natural limits. We believe our recognition as a Major Player in the 2026 IDC MarketScape for DAST reflects this broader market transition toward continuous, payload-verified validation. Modern security programs do not need more alert volume; they need precise intelligence that proves real-world risk, scales automatically with organizational growth, and empowers teams to protect their applications with confidence.

Ready to see Detectify in action? Book a demo with our application security experts to explore a tailored walk-through.
Want to test your attack surface today? Start a free trial and instantly map your external assets with zero friction.

The post Detectify positioned as a Major Player in the IDC MarketScape for Worldwide Dynamic Application Security Testing appeared first on Blog Detectify.

A staging site is meant to last a week, but six months later, it still resolves on a company subdomain, runs an old framework, and has no clear owner. The asset never made it into the central inventory, which means that it also missed the normal cycle of testing, patching, and retirement.

That is how many Shadow IT Security problems develop. The original shortcut may have been reasonable, but the risk grows when temporary infrastructure becomes part of the permanent attack surface without anyone noticing.

Security teams often respond by tightening approval processes or reminding teams about policy, and those controls can reduce the use of unmanaged technology. They cannot, however, keep an inventory perfectly aligned with a business that changes every day, so Shadow IT Security has to account for the gap between what the organization believes it owns and what is actually exposed.

Shadow IT grows where teams hit friction

Most unmanaged technology has a practical origin rather than a dramatic one. A developer needs somewhere to run a short-lived job, a product team wants to test a SaaS service before procurement is finished, or an acquired company still has applications running under domains that never entered the parent company’s security tooling.

Naturally, governance still matters: procurement reviews, identity controls, cloud policies, and approved tooling reduce avoidable risk, but they cannot show everything running today. A useful Shadow IT Security program has to work with that reality rather than assume every asset will pass through the same process before it appears online.

The priority changes once unmanaged infrastructure becomes reachable from the internet, because an overlooked service can create the same exposure as any formally managed production system while receiving far less scrutiny.

Exposure is where the risk becomes real

An unused SaaS account and a forgotten public-facing test server do not deserve the same response, which is why exposure and business context matter. The weaknesses themselves are usually familiar: a test application has no authentication, a storage bucket exposes files, a database accepts public connections, or a legacy API still runs an old framework because nobody owns the upgrade.

Known systems can suffer from the same problems, but they are more likely to be monitored, scanned, patched, and assigned to an owner. Shadow assets often sit outside those routines, which means a relatively ordinary configuration mistake can remain in place for much longer.

For Shadow IT Security, the important window is the time between an asset becoming exposed and somebody taking responsibility for it. Shortening that window gives security a better chance of fixing routine mistakes during normal work instead of investigating them after an incident.

The inventory ages quickly

An inventory records what teams registered and what security knew during the last review, so it remains useful as a management tool, but it should not be treated as a complete picture of the external environment. Test environments stay online, domains survive migrations, partners launch infrastructure under company-owned subdomains, and acquisitions bring services that may never reach the central security team.

Point-in-time audits have the same limitation because they capture a moment while the attack surface continues to change. The findings may be accurate on the day of testing and incomplete a week later, which is why Shadow IT Security benefits from an outside-in view alongside internal records.

Better attack surface visibility helps security teams see domains, services, and infrastructure that never reached the central inventory, while effective shadow IT detection looks for public signals that connect those assets back to the organization. External attack surface monitoring can then surface domains, IP addresses, certificates, DNS records, open ports, services, and exposed technologies that internal records may miss.

That visibility only becomes useful when it changes what the team does next.

Move from discovery to ownership

A discovery feed can become another source of noise when every new asset lands in a backlog without context, so Shadow IT Security needs a process that connects discovery directly to a decision. In practice, that means moving through a small number of steps:

1. Discover the asset: identify new or changed internet-facing infrastructure and determine whether the signal is worth investigating.
2. Confirm ownership and context: establish whether the asset belongs to the organization, whether it is still active, and what role it plays.
3. Assess the exposure: understand what is running, how reachable it is, and whether the asset needs deeper application or API testing.
4. Assign and resolve: route verified issues to the team that can act, then patch, restrict, monitor, or retire the asset and confirm the change.

This gives Shadow IT Security a route from discovery to ownership and remediation instead of simply producing a larger asset list, while also making it easier to distinguish a forgotten but harmless domain from an exposed application that needs immediate attention.

Detectify supports this part of the process by helping teams discover and monitor internet-facing assets, while deeper application and API testing can provide more evidence when surface-level checks are not enough. Within a Shadow IT Security program, that can help connect an unexpected asset with the next security action rather than leaving it as another unexplained item in an inventory.

External monitoring still has limits because it will not uncover every unsanctioned SaaS account, unmanaged endpoint, or isolated cloud resource. Shadow IT Security therefore works best alongside identity data, endpoint controls, cloud governance, procurement records, and cooperation from engineering teams, each of which covers a different part of the problem.

Measure how long the gap stays open

Raw asset counts can be misleading because finding more assets may reflect a growing attack surface, better discovery, or both. Shadow IT Security metrics should instead show how quickly the team turns uncertainty into ownership and action.

Time to discovery, time to confirmed ownership, and time to remediation are more useful than the total number of assets in a dashboard, while exposed systems with no owner and assets that return after retirement can reveal where the underlying process is failing.

The goal is to reduce the gap between what the business exposes and what security understands. Shadow IT will continue to appear as teams ship software, adopt services, and acquire companies, so the value of Shadow IT Security is measured by how quickly those changes become visible and how long unmanaged exposure is allowed to remain unresolved.

Take control of your exposed attack surface

Don’t let forgotten staging sites or unmanaged cloud assets put your enterprise at risk. Detectify gives you the automated visibility and deep application testing required to bridge the gap between discovery and remediation.

Ready to see it in action? Book a demo with our application security experts to explore a tailored walk-through.
Want to test your environment today? Start a free trial and instantly map your external assets with zero friction.

Frequently asked questions 

What is Shadow IT Security?

Shadow IT Security is the practice of finding, assessing, and reducing risk from technology outside normal IT or security oversight, including applications, APIs, cloud infrastructure, domains, and SaaS services.

Can shadow IT be eliminated?

Probably not completely. Organizations can reduce it by removing unnecessary friction, while Shadow IT Security provides a way to find assets that still appear outside approved processes and bring them into normal ownership and remediation workflows.

Is attack surface monitoring enough?

No. It cannot see every SaaS account, endpoint, or isolated cloud resource, so Shadow IT Security works best alongside identity, endpoint, cloud, and procurement controls.

How does Detectify help with Shadow IT Security?

Detectify can discover and monitor internet-facing assets, then support deeper testing of relevant web applications and APIs where more validation is needed.

Which Shadow IT Security metrics matter most?

Time to discovery, ownership, and remediation shows how long unmanaged exposure remains unresolved and whether Shadow IT Security is reducing that window over time.

The post Shadow IT Security and why visibility beats another approval process appeared first on Blog Detectify.

We’ve been listening to dozens of CISOs. In roundtables, peer forums, customer and prospect calls, on the record, off the record, at event floors and dinners. And the same thing keeps coming up: the security program on paper and the one running in production are rarely the same.

There’s a gap between security policy and reality.

We have researched what leading teams are actually doing to close it, and turned it into practical insights for security leaders trying to move from policy to operational reality, packaged into a whitepaper, Operationalizing Secure by Design.

Most organizations already understand Secure by Design practices, grounded in CISA’s principles of taking ownership of customer security outcomes, embracing radical transparency, and building organizational structure to support these goals, and apply them on paper. 

The challenge is that shipping fast, managing legacy infrastructure, keeping decentralized teams aligned, and satisfying compliance requirements are all happening at once. And the attack surface keeps expanding regardless.

The result is a predictable failure mode: teams follow best practices on paper (such as NIST SSDF controls for threat modeling, secure coding, and periodic assessments), but attackers find the vulnerabilities that never got tested, or got deprioritized based on incomplete information.

The visibility problem is bigger than most boards realize

Boards seek assurance from CISOs and security teams. But assurance requires accurate, real-world, continuous visibility, and that’s precisely what most traditional models are failing to deliver.

Cloud adoption, API proliferation, decentralized development teams, and rapid deployment cycles have expanded the external attack surface faster than centralized governance can track. Legacy systems connect to modern infrastructure without adequate documentation, often because the original system owners have long since left the organization. Business units spin up services and tools outside formal approval processes. And annual penetration tests, by the time they’re completed, are already describing an environment that no longer exists.

The result is that most organizations are managing risk based on incomplete information. Attackers, meanwhile, are patient, targeted, and increasingly focused on application-layer weaknesses that point-in-time assessments consistently miss.

What mature programs are doing differently

The whitepaper identifies five operational shifts that distinguish leading programs from those still operating on legacy models.

Meaningful security metrics, not activity reporting. Boards and executive leadership need reporting that reflects actual risk reduction, not scan volumes or finding counts. “Total findings” is a vanity metric. “Average remediation time” is operational reality.

Mature programs track remediation speed, exploitability rates, and coverage across the attack surface,  indicators that support defensible reporting and credible conversations about budget allocation. When KPIs are poorly designed, teams optimize for audits instead of reducing risk.

Continuous validation instead of periodic testing. One of the clearest trends is the growing inadequacy of annual penetration testing. Modern application environments change too quickly for point-in-time assessments to provide meaningful assurance. Replacing them with continuous, payload-based testing changes the assurance model entirely, testing internet-facing applications, APIs, authentication flows, and production attack surfaces as environments evolve.

Critically, continuous testing depends on continuous discovery: organizations cannot continuously test what they cannot continuously see.

Live asset intelligence. You cannot govern what you cannot see. Maintaining an accurate, continuously updated inventory of externally exposed assets, APIs, and services is foundational to everything else: prioritization, remediation, board reporting, and regulatory compliance. Shadow IT, unmanaged SaaS services, exposed development environments, abandoned subdomains, and unmanaged cloud services are consistently among the largest sources of untracked exposure.

This becomes especially critical during mergers and acquisitions, where live asset intelligence enables organizations to rapidly assess newly expanded attack surfaces.

Risk prioritization tied to exploitability and business impact. Risk registers often fail because they become administrative exercises rather than operational tools. A high-CVSS vulnerability in an unused legacy system isn’t the priority. A low-CVSS flaw in a payment API is.

The organizations allocating remediation effort most effectively are connecting technical risk to four factors: external exposure, verified exploitability (through payload-based testing, not signatures), business criticality, and existing compensating controls. This makes investment decisions easier to defend, both internally and to the board.

Accountability embedded across the business. Security programs that depend entirely on a centralized team do not scale. As one CSO put it: “Whenever we try to centralize stuff, we fail. Security is one of those things that traditionally end up being a gatekeeper, someone who has to say no, and then people get annoyed.”

The CISOs making the most progress are embedding accountability into role definitions, performance reviews, and security champion programs, while retaining oversight at the center. Crucially, accountability becomes self-reinforcing when findings are trusted: developers who receive high-noise alerts ignore them; developers who receive verified, exploitable findings own the fix.

Turning principles into practice: realistic timelines

The whitepaper maps these shifts to a two-horizon execution model. In the first 90 days, the focus is on immediate wins: embedding threat modeling into project workflows, establishing baseline metrics and remediation KPIs, mapping the external attack surface to reduce unidentified assets, and integrating continuous validation into release processes.

Over the multi-quarter horizon, the work shifts to organizational alignment: building cultural accountability across product teams, decentralizing governance maturity to allow process variations, aligning risk management with business metrics, and establishing shared cross-functional ownership. These changes frequently take six months or longer in complex enterprises. Failure indicators include rising remediation timelines, persistent organizational friction, and disconnects between security tooling and engineering workflows.

The strategic case for acting now

The whitepaper’s core finding is that Secure by Design is no longer a compliance initiative. It is becoming an operational discipline, and the gap between organizations that have made this shift and those still running periodic assurance models is widening. The organizations that succeed will not necessarily be the ones with the most security tooling or the largest governance frameworks. They will be the ones capable of continuously validating what is exposed, exploitable, and operationally risky across rapidly changing environments.

For CISOs navigating board expectations, budget cycles, and an expanding threat landscape, the question is no longer whether to modernize the operating model. It’s about doing it in a way that delivers measurable results, builds internal buy-in, and keeps the business moving.

The full paper covers the five operational dimensions in depth: strategy, discovery, validation, governance, and metrics, along with an overview of the implementation timelines, governance models for decentralized organizations, and the interventions that enterprise security leaders are putting into practice right now.

Download Operationalizing Secure by Design. 

The post Operationalizing Secure by Design: a CISO’s guide to closing the gap between policy and reality appeared first on Blog Detectify.

Most tools will only test the domains you already know about. We’ve decided that’s not enough.

TLDR: Detectify’s new Apex Discovery automatically identifies root domains likely to belong to your organization (from M&A, subsidiaries, and shadow IT) for complete security coverage. Review and confirm our curated suggestions in a click, and instantly start protecting them with the same continuous discovery and vulnerability assessment as the rest of your attack surface. Detectify does the heavy lifting while your team stays in control.

You might own a domain from a startup you acquired three years ago, a regional variant of a subsidiary registered without telling security, or a marketing microsite someone spun up and forgot. 

Most organizations simply don’t have a complete picture of their attack surface, and every unmonitored domain is a blindspot that can quietly harbor vulnerabilities no one is watching. Your existing tooling can only monitor what you feed it, which means your real attack surface is almost always larger than the one you’re watching. 

We believe knowing your known domains isn’t enough. To truly secure your attack surface, you first have to know how big it actually is, and that starts at the apex.

We have launched Apex Discovery, a core enhancement to attack surface management in Detectify. This isn’t just a WHOIS lookup; it’s a custom-built attribution engine that connects domains to your organization using multiple ownership signals directly into your Detectify workflow. 

Engineering a better attribution engine

A key part of what we do at Detectify is building unique solutions that provide significantly more value to your team than standard tooling. Apex domain attribution is a genuinely hard, under-researched problem, and it’s even harder in the EU, where GDPR limits most of the ownership signals in WHOIS data. That’s exactly the kind of problem we like to solve:

• Automated attribution techniques combined: Rather than relying on a single data point, we combine multiple signals to connect domains back to your organization, casting a wide net.
• High-confidence candidates, not noise: Domain ownership can’t be proven with 100% certainty by a machine, so instead of dumping raw results on you, we filter through various attribution methods to curate candidates with high confidence, surfacing the ones most likely to be yours so you can review and verify ownership. 
• Uncovering the invisible: Domains from M&As, subsidiaries, and shadow IT are most likely to be unmonitored and quietly contain risk. With Apex Discovery, you can find vulnerabilities continuously with the same security as for your other domains.

How does Apex Discovery work?

Because attribution is probabilistic, we built the workflow around review and verification rather than blind automation. From your highly curated list of candidates, you can:

• Confirm the domains that belong to your organization.
• Add confirmed domains as assets to your team in a single step.
• Verify ownership of those assets.
• Dismiss anything that isn’t yours, so your list stays clean, and your next review is always sharper.

This semi-automated approach means you get the reach of automated discovery without giving up control over what actually lands in your inventory.

Automatically identify apex domains belonging to your organization for a complete external security coverage, and review curated domain suggestions.

What’s new in your dashboard?

We’ve integrated Apex Discovery directly into your Surface Monitoring workflow to make it actionable:

• A curated candidates list: A dedicated place to review potential apex domains attributed to your organization.
• One-click confirmation: Confirm a domain and add it as an asset in the same motion, then move straight into ownership verification.
• Full coverage from day one: The moment you confirm and start scanning a domain, it inherits the same continuous discovery and vulnerability assessment you already rely on for your known assets, with the possibility of always adding configuration on the new root. 
• Dismiss and refine: Clear out domains that aren’t yours to keep future suggestions focused and relevant.

Get started

The best way to understand your exposure is to see how much of it you didn’t know about. Head to your Detectify dashboard to review the apex domains we’ve attributed to your organization, confirm what’s yours, and bring it under continuous control.

Book a demo to talk to our experts or start a 2-week free trial to see it in action.

The post Introducing Apex Discovery to secure every domain you actually own appeared first on Blog Detectify.

For years, development and security practitioners have treated dynamic application security testing as a critical final safety check before code goes live. However, the external attack surface is expanding faster than mid-sized security teams can realistically manage. 

In this high-velocity environment, legacy DAST tools are increasingly failing to keep pace. When software volume decouples from security headcount, security engineers find themselves operating with persistent uncertainty about unseen exposure. 

The real challenge today is not just finding any vulnerability, but understanding which exposures are actually exploitable and require immediate attention.

The problem with checklist-driven DAST tools

Traditional DAST tools rely heavily on broad vulnerability signatures and static lists of common vulnerabilities and exposures (CVEs). 

This approach leads to a massive structural cost for the industry: alert fatigue. 

Legacy scanners flood development queues with thousands of unverified findings, turning expensive security engineers into manual triagers who spend hours filtering out noise rather than remediating risks. When your DAST tools create more busy work than actual value, development velocity grinds to a halt.

Relying solely on public CVE lists creates severe security blind spots. Public databases are misaligned with modern tech stacks. Only 20% of critical CVEs actually target application components, while 35% of real-world vulnerabilities never receive an identifier at all. Furthermore, legacy testing methods treat applications as static entities. They require intensive manual configuration for each endpoint, creating immediate blind spots the moment a development team spins up a new subdomain, deploys an unmapped cloud resource, or introduces a third-party integration.

Attackers do not follow a static checklist; they perform continuous reconnaissance to target unusual outliers and forgotten assets in the long tail of your attack surface.

Redefining vulnerability testing with payload-based accuracy

To build an AppSec program you can truly stand behind, your DAST tools must evolve beyond point-in-time signature matching toward real-world attacker methodology.

Some tools, like Detectify, replace outdated signature checks with deterministic, payload-based verification. Instead of guessing if a vulnerability exists based on a software version number, our engines execute safe, simulated exploit payloads against live target assets to confirm real-world exploitability.

This approach drives the false-positive rate down (in the case of Detectify, to an unmatched <0.3%), providing security teams with high-fidelity, actionable data they can immediately trust. When a finding enters your workflow, your developers receive clear remediation guidance and proof of exploitability, eliminating the frictional back-and-forth between security and engineering teams.

Combining attack surface monitoring with DAST tools

An effective dynamic scanning strategy cannot operate in isolation; it requires continuous attack surface intelligence. 

You cannot secure what you do not know you own. Security teams can pair continuous attack surface reconnaissance with deep application crawling and fuzzing to gain both a bird’s-eye overview of their perimeter and the technical depth required to neutralize flaws before exploitation.

Detectify continuously maps and tests your entire external attack surface, discovering all assets, IPs, subdomains, shadow IT, and infrastructure (acquired, for example, through M&As) within minutes of exposure. 

The platform then applies asset classification to prioritize your resources, intelligently recommending exactly where to deploy deep-dive application and API scanning profiles.

Human-engineered, machine-scaled

Security should run smoothly in the background so your team can focus on building features. Fueled by a global crowdsourced network of elite ethical hackers, Detectify converts newly uncovered exploit techniques into live scanner tests in under 15 minutes. This research-driven intelligence is put to machine scale through a next-generation machine learning fuzzing engine capable of generating up to 922 quintillion payload permutations per vulnerability check.

As engineering organizations transition toward autonomous workflows, DAST tools must adapt to support both human developers and autonomous AI agents. Detectify is deconstructing a decade of scanning expertise into modular micro-utilities to become the deterministic trust layer needed for agentic pipelines. 

Turn uncertainty into clarity, and start scanning your full environment with precision. Start a trial or book a demo. 

Frequently Asked Questions (FAQ)

Q: Why do traditional DAST tools fail modern AppSec teams?

A: Traditional DAST tools fail modern teams because they rely on static signature databases and version-matching, resulting in high false-positive rates and severe alert fatigue. Furthermore, legacy DAST tools require manual endpoint configuration, which fails to scale alongside automated deployment pipelines and rapidly expanding external attack surfaces.

Q: What should security teams look for in modern DAST tools?

A: Modern DAST tools should offer continuous, automated asset discovery paired with deterministic, payload-based verification. Instead of guessing if a vulnerability exists, next-generation DAST tools safely execute simulated exploits against live assets to confirm real-world exploitability, driving false positives down to less than 0.3%.

Q: How do payload-based DAST tools reduce alert fatigue for developers?

A: Payload-based DAST tools eliminate the frictional back-and-forth between security and engineering by providing high-fidelity, actionable data. Because the tool actively verifies the vulnerability rather than just matching a software version number, developers receive clear remediation guidance alongside verified proof of exploitability.´

Q: Can DAST tools integrate with autonomous AI workflows and pipelines?

A: Yes, next-generation DAST tools are moving away from dashboard-heavy interfaces built strictly for human review. Advanced platforms are deconstructing scanning expertise into modular micro-utilities, offering agent-native workflows, scriptable APIs, and MCP server support to serve as a deterministic trust layer for autonomous AI agents.

The post Why traditional DAST Tools fail modern AppSec teams (and how to fix it) appeared first on Blog Detectify.